Celerity

Celerity Versions

Overview of Celerity versions and feature evolution

Celerity is an ecosystem of multiple software components that work together to provide a unified backend development experience. The capabilities available depend on which components are implemented and to what degree.

This section provides an overview of the versioning strategy for Celerity spanning multiple software components and resource type specifications. The term "Ecosystem" is used to refer to the entire Celerity project.

Version Strategy

v0 (Current) - Evolving Capabilities

Initial Release: October 30th, 2026 Evolution Period: October 2026 - October 2027

v0 represents the initial release of Celerity with limited but functional capabilities that will continuously evolve until the release of v1.

The current v0 release supports deploying Celerity applications to AWS serverless environments with application handlers running in AWS Lambda, along with containerised deployments to Amazon ECS running the Celerity runtime:

Current v0 Components (October 2026)

  • Celerity CLI: Full set of commands for starting projects along with the development and deployment lifecycle.
  • Celerity Core Runtimes & SDKs: Node.js, Python and Go SDKs only, supporting HTTP APIs, WebSocket APIs, consumers, schedules, SQL databases, NoSQL datastores and caches. Node.js and Python projects are backed by dedicated runtimes and Go projects run on an OS-only runtime.
  • Client SDK for WebSocket APIs: A single TypeScript package for browsers and Node.js to interact with WebSocket APIs adhering to the WebSocket Runtime Protocol, that are also compatible with AWS API Gateway v2 WebSocket APIs.
  • Bluelink Deploy Engine: The engine that powers deployments of Celerity applications, initially supporting only a subset of AWS services that enable serverless deployments along with containerised deployments to Amazon ECS.
  • Bluelink Blueprint Language Server: Diagnostics, validation and auto-complete support for blueprints used to define Celerity applications.

Current v0 Resource Types (October 2026)

  • celerity/api - AWS API Gateway and Amazon ECS deployments along with the Celerity runtime locally - HTTP and WebSocket APIs, full CORS support and authentication.
  • celerity/handler - AWS Lambda functions and handlers hosted in the Celerity runtime for Amazon ECS deployments.
  • celerity/consumer - AWS SQS Lambda triggers, along with the Celerity runtime polling event sources for Amazon ECS deployments.
  • celerity/schedule - AWS EventBridge rules, along with the Celerity runtime polling an EventBridge-fed SQS queue for Amazon ECS deployments.
  • celerity/handlerConfig - Helper type for shared handler configuration translating to AWS Lambda function configuration.
  • celerity/config - AWS SSM Parameter Store and AWS Secrets Manager
  • celerity/datastore - AWS DynamoDB tables with built-in schema management (schema-as-code, type generation, schema contracts, data-shape drift detection, data team exports).
  • celerity/queue - AWS SQS queues
  • celerity/topic - AWS SNS topics
  • celerity/bucket - AWS S3 buckets
  • celerity/vpc - AWS VPCs hosting lambda functions and ECS services (including the load balancers fronting containerised APIs) along with using VPC endpoints to interact with other AWS services.
  • celerity/sqlDatabase - AWS RDS for PostgreSQL with built-in schema management (schema-as-code with generated migrations, drift detection, type generation).
  • celerity/cache - AWS ElastiCache for Redis with an SDK abstraction covering all core Redis data structures (strings, hashes, lists, sets, sorted sets), atomic counters, transactions and a credentials provider for direct Redis client access.

Cloud Provider Support

  • AWS only (initially), across both the AWS Serverless (API Gateway + Lambda) and AWS containerised (Amazon ECS) deployment targets. Amazon EKS is planned for v1.

v1 (Preview) - Full Capabilities

Target Release: October 2027

v1 represents the full vision of Celerity with complete multi-cloud capabilities:

Supported Components

  • Celerity CLI: Full set of commands for starting projects along with the development and deployment lifecycle.
  • Celerity Core Runtimes & SDKs: Node.js, Python, Go and C#/.NET. Languages beyond these are considered case by case on demonstrated demand rather than committed in advance. Ahead-of-time compiled languages without a tailored SDK are usable through the Local Runtime API on an OS-only runtime.
  • Celerity Workflow Runtime: Workflow orchestration with support for every available language runtime
  • Client SDK for WebSocket APIs: Client SDKs for browsers, Node.js and Python to interact with WebSocket APIs adhering to the WebSocket Runtime Protocol, that are also compatible with AWS API Gateway v2 WebSocket APIs. v1 adds a Python WebSocket client SDK.
  • Bluelink Deploy Engine: The engine that powers deployments of Celerity applications, supporting AWS, Azure and Google Cloud.
  • Bluelink Blueprint Language Server: Diagnostics, validation and auto-complete support for blueprints used to define Celerity applications.

Supported Resource Types

  • celerity/api

    • AWS API Gateway for HTTP and WebSocket APIs for the AWS Serverless deployment target.
    • AWS ECS (available in v0) or EKS for HTTP and WebSocket APIs for the AWS deployment target with containers running the Celerity runtime.
    • Azure API Management with Azure Functions for HTTP APIs with the Azure Serverless deployment target.
    • Azure Container Apps or AKS for HTTP and WebSocket APIs with containers running the Celerity runtime for the Azure deployment target.
    • Google Cloud API Gateway for HTTP APIs for the Google Cloud Serverless deployment target.
    • Google Cloud Run or GKE for HTTP and WebSocket APIs with containers running the Celerity runtime for the Google Cloud deployment target.

  • celerity/handler

    • AWS Lambda Functions
    • Azure Functions
    • Google Cloud Functions
    • Handlers bundled with the Celerity runtime for containerised deployments across all cloud providers.

  • celerity/handlerConfig

    • Helper type for shared handler configuration translating to cloud provider specific configuration.

  • celerity/config

    • AWS SSM Parameter Store and AWS Secrets Manager
    • Azure Key Vault
    • Google Cloud Secret Manager

  • celerity/datastore

    • AWS DynamoDB tables
    • Azure Cosmos DB
    • Google Cloud Firestore

  • celerity/queue

    • AWS SQS queues
    • Azure Service Bus queues
    • Google Cloud Pub/Sub topics and Google Cloud Task queues

  • celerity/topic

    • AWS SNS topics
    • Azure Service Bus topics
    • Google Cloud Pub/Sub topics

  • celerity/bucket

    • AWS S3 buckets
    • Azure Blob Storage
    • Google Cloud Storage

  • celerity/vpc

    • AWS VPCs hosting lambda functions, ECS/EKS clusters, databases and caches. VPC endpoints are used to enable interaction with other AWS services. Security groups and NACLs are configured to open up traffic to specific ports to interact with databases, caches and other APIs.
    • Azure VNETs hosting Azure Functions, Azure Container Apps, AKS clusters, Azure SQL Databases and caches. VNET private endpoints are used to enable interaction with other Azure services. VNET security groups and NACLs are configured to open up traffic to specific ports to interact with databases, caches and other APIs.
    • Google Cloud VPCs hosting Google Cloud Functions, Google Cloud Run, GKE clusters, Google Cloud SQL Databases and caches. VPC private service connections are used to enable interaction with other Google Cloud services. VPC security groups and NACLs are configured to open up traffic to specific ports to interact with databases, caches and other APIs.

  • celerity/workflow

    • AWS Step Functions for the AWS Serverless deployment target.
    • AWS ECS or EKS for the AWS deployment target running the Celerity workflow runtime with DynamoDB used for workflow state persistence.
    • Azure Logic Apps for the Azure Serverless deployment target.
    • Azure Container Apps or AKS for the Azure deployment target running the Celerity workflow runtime with Azure Cosmos DB used for workflow state persistence via the NoSQL API for Cosmos DB.
    • Google Cloud Workflows for the Google Cloud Serverless deployment target.
    • Google Cloud Run or GKE for the Google Cloud deployment target running the Celerity workflow runtime with Google Cloud Firestore used for workflow state persistence.

  • celerity/consumer

    • AWS SQS Lambda triggers for the AWS Serverless deployment target. For integration with Celerity topics, an intermediary SQS queue will be provisioned to enable the Celerity runtime to consume messages from the topic.
    • AWS ECS (available in v0) or EKS for the AWS deployment target running the Celerity runtime that will poll the event source for messages, be it an SQS queue, an intermediary SQS queue for a topic, a Kinesis stream or DynamoDB stream.
    • Azure Functions with Azure Service Bus triggers for the Azure Serverless deployment target.
    • Azure Container Apps or AKS for the Azure deployment target running the Celerity runtime which for the former will be triggered as an event-driven job and for the latter will poll the event source for messages.
    • Google Cloud Functions with Google Cloud Pub/Sub triggers for the Google Cloud Serverless deployment target.
    • Google Cloud Run or GKE for the Google Cloud deployment target running the Celerity runtime which for the former will be triggered through a push subscription and for the latter will poll the event source for messages.

  • celerity/schedule

    • AWS EventBridge rules to trigger lambda functions for the AWS Serverless deployment target.
    • AWS ECS (available in v0) or EKS for the AWS deployment target running the Celerity runtime that will poll an SQS queue for messages sent by an EventBridge rule.
    • Azure Functions configured with timer triggers for the Azure Serverless deployment target.
    • Azure Container Apps or AKS for the Azure deployment target running the Celerity runtime. For Container Apps, an event-driven job with a schedule trigger will be used and for AKS, an Azure Logic App scheduled trigger will send a message to a queue that will be polled by the Celerity runtime in the container hosting your application.
    • Google Cloud Functions configured with Cloud Scheduler triggers for the Google Cloud Serverless deployment target.
    • Google Cloud Run or GKE for the Google Cloud deployment target running the Celerity runtime. For Cloud Run, a Cloud Scheduler job will be used to send a message to a pub/sub topic which will push messages to the Celerity runtime via a push subscription. For GKE, a Cloud Scheduler job will be used to send a message to a pub/sub topic which will be polled by the Celerity runtime hosting your application.

  • celerity/sqlDatabase

    • AWS RDS for PostgreSQL for the AWS deployment targets. (Available in v0)
    • v1 adds MySQL support and multi-cloud:
    • AWS RDS for PostgreSQL and MySQL for the AWS deployment targets.
    • Azure SQL Databases for the Azure deployment targets.
    • Google Cloud SQL for PostgreSQL and MySQL for the Google Cloud deployment targets.

  • celerity/cache

    • AWS ElastiCache for Redis for the AWS deployment targets. (Available in v0)
    • v1 adds multi-cloud:
    • AWS ElastiCache for Redis for the AWS deployment targets.
    • Azure Cache for Redis for the Azure deployment targets.
    • Google Cloud Memorystore for Redis for the Google Cloud deployment targets.

Cloud Provider Support

  • AWS - Full support
  • Azure - Full support
  • Google Cloud - Full support

v1+ (Future) - Post-v1 Features

v1+ represents features that are planned for after the v1 release in October 2027. These are features that have been designed and or considered of but are not part of the v1 roadmap.

Planned Resource Types

  • celerity/channel - An opt-in real-time channel layer on top of WebSocket APIs providing pub/sub messaging, presence tracking, per-channel auth, and rate limiting. Channels are declared as resources in the blueprint and linked from a celerity/api with the WebSocket protocol. The runtime handles subscription management, message fan-out, and cross-node delivery in cluster deployments. A client SDK (@celerity-sdk/channels) provides channel subscription, presence, and automatic re-subscription on reconnect.

Planned Provider Support

  • Self-hosted/on-premise - Support for self-hosted deployments is planned for v1+, the Celerity stack, control plane and your workloads running on a fully open source backing stack. The aim is to support both a single-node Docker Compose deployment and a Kubernetes-based deployment for larger scale needs.

Documentation Versioning Strategy

The Celerity-wide documentation uses a simple versioning approach:

1) Spec Version

  • Format: vYYYY-MM-DD-draft (e.g., v2026-02-27-draft)
  • Purpose: Single evolving specification for each resource type
  • When to update: When a stable resource specification changes
  • Draft Status: Will remain in draft until v1 release (October 2027)
  • Blueprint transform: Matches the spec version

2) Ecosystem Compatibility

  • v0: Current capabilities (continuously evolving)
  • v1: Full planned capabilities (target: October 2027)
  • Purpose: Indicates which ecosystem features are available
  • When to update: As ecosystem components are implemented

Example Resource Documentation Header

# `celerity/api`

**Spec Version:** `v2026-02-27-draft`  
**Ecosystem Compatibility:** v0 (Current) / v1 (Preview)

**blueprint transform:** `celerity-2026-02-27-draft`

Simple Timeline

  1. Current: v2026-02-27-draft (single evolving spec)
  2. v1 Release: v2027-10-30 (stable, no draft suffix)

This approach allows us to:

  • Keep it simple - Single evolving spec per resource type
  • Track current state - Ecosystem compatibility shows what's available
  • Provide roadmap - Users can see both current capabilities and future plans
  • Easy maintenance - Update spec as features are added

Migration Path

Users can start with v0 and gradually adopt new features as they become available. The documentation will be updated to reflect the current state while maintaining visibility into the full vision for v1.

Version Indicators in Documentation

Throughout the documentation, you'll see the following indicators:

  • ✅ Available in v0 - Features currently supported
  • 🔄 Planned for v0 - Features coming in future v0 evolution
  • 🚀 Planned for v1 - Features coming in v1 release
  • 🔮 Planned for v1+ - Features planned for after v1 release

As v0 evolves, features will gradually move from 🔄 to ✅ as they become available, and from 🚀 to 🔄 as they move from v1 plans to v0 plans.

Last updated on

Installing Celerity

How to install Celerity for multiple platforms

Introduction

Introduction to Celerity applications

On this page

Version Strategy
v0 (Current) - Evolving Capabilities
Current v0 Components (October 2026)
Current v0 Resource Types (October 2026)
Cloud Provider Support
v1 (Preview) - Full Capabilities
Supported Components
Supported Resource Types
Cloud Provider Support
v1+ (Future) - Post-v1 Features
Planned Resource Types
Planned Provider Support
Documentation Versioning Strategy
1) Spec Version
2) Ecosystem Compatibility
Example Resource Documentation Header
Simple Timeline
Migration Path
Version Indicators in Documentation