Celerity Handler
Celerity Handler resource type
celerity/handler
Spec Version: v2026-02-27-draft
Ecosystem Compatibility: v0 (Current) / v1 (Preview)
blueprint transform: celerity-2026-02-27-draft
Ecosystem Compatibility
- v0 (Current): AWS only, supporting AWS Lambda functions.
- v1 (Preview): Multi-cloud with support for FaaS and containerised environments running the Celerity runtime.
Read more about Celerity versions here.
The celerity/handler resource type is used to define a handler that can carry out a step in a workflow, process HTTP requests, WebSocket messages, or events from queues/message brokers, scheduled events, or cloud services.
Handlers can be deployed to different target environments such as FaaS1, containerised environments, or custom servers. For containerised and custom server environments, the Celerity runtime is responsible for setting up the appropriate server or polling mechanism to handle incoming requests or messages and route them to the appropriate handler.
Specification
The specification is the structure of the resource definition that comes under the spec field of the resource in a blueprint.
Feature Availability
- ✅ Available in v0 - Features currently supported
- 🔄 Planned for v0 - Features coming in future v0 evolution
- 🚀 Planned for v1 - Features coming in v1 release
Configuration Inheritance
Most handler spec fields can be inherited from a linked celerity/handlerConfig resource or from metadata.sharedHandlerConfig in the blueprint. When a field is set at multiple levels, the handler spec takes highest priority, followed by the linked handlerConfig, then the shared config, then defaults. Only handler is always required on every handler resource; all other fields can be inherited.
handlerName
The name to identify the handler that will be loaded by the runtime. In FaaS1 target environments this will be the name of the function resource in the cloud provider.
type
string
examples
Orders-SaveOrder-v1
codeLocation
The location of the handler code that will be loaded by the runtime, this can be a directory or a file path without the file extension. In an OS-only runtime, this is expected to be a directory containing the handler binary.
This field can be inherited from a linked celerity/handlerConfig or metadata.sharedHandlerConfig and must be provided at some level.
✅ Available in v0
type
string
examples
./handlers
handler (required)
The name of the handler function that will be loaded by the runtime. In an OS-only runtime, this is expected to be the name of the handler binary.
✅ Available in v0
type
string
examples
save_order
runtime
The Celerity runtime identifier for this handler (e.g. nodejs24.x, python3.13.x). This is a portable identifier: the CLI maps it to a local runtime image for development, and the Celerity deploy engine maps it to the target platform's concrete runtime (AWS Lambda, Azure Functions, Google Cloud Functions). See Runtimes for the full list of supported Celerity runtime identifiers and how they map to each target.
This field can be inherited from a linked celerity/handlerConfig or metadata.sharedHandlerConfig.
Using multiple runtimes in an application
When deploying your application to containerised or custom server environments, it is not possible to use different runtimes for different handlers in the same application.
✅ Available in v0
type
string
examples
python3.13.x
memory
The amount of memory available to the handler at runtime. The default value is 512MB. This value is used to configure the amount of memory available to the handler in a FaaS1 target environment. In containerised or custom server environments, the highest value across all handlers will be used as a guide to configure the memory available to the runtime.
The minimum and maximum values available depend on the target environment.
✅ Available in v0
type
integer
default value
512
examples
1024
timeout
The maximum amount of time in seconds that the handler can run for before being terminated. This defaults to 30 seconds.
The minimum and maximum values available depend on the target environment.
✅ Available in v0
type
integer
default value
30
tracingEnabled
Whether or not to enable tracing for the handler. The tracing behaviour will vary depending on the target environment. Tracing is not enabled by default.
✅ Available in v0
type
boolean
default value
false
environmentVariables
A mapping of environment variables that will be available to the handler at runtime. When a Celerity application is deployed to containerised or custom server environments, environment variables shared between functions will be merged and made available to the runtime.
Warning
If you define an environment variable with the same key in multiple handlers, the value of the environment variable will be taken from the last handler that is loaded by the runtime.
✅ Available in v0
type
mapping[string, string]
examples
Blueprint Language
environmentVariables = {
DB_HOST = variables.dbHost,
DB_PORT = variables.dbPort
}YAML
environmentVariables:
DB_HOST: "${variables.dbHost}"
DB_PORT: "${variables.dbPort}"Annotations
Annotations define additional metadata that can determine the behaviour of the resource in relation to other resources in the blueprint or to add behaviour to a resource that is not in its spec.
celerity/api 🔗 celerity/handler
The following are a set of annotations that activate a link that can be used to configure a handler to respond to HTTP requests or WebSocket messages for a Celerity API.
celerity.handler.http
Enables the handler to respond to HTTP requests for a Celerity API.
✅ Available in v0
type
boolean
celerity.handler.http.method
The HTTP method that the handler will respond to.
✅ Available in v0
type
string
allowed values
GET | POST | PUT | PATCH | DELETE | OPTIONS | HEAD | CONNECT | TRACE
default value
GET
celerity.handler.http.path
The HTTP path that the handler will respond to, this can include path parameters.
Path parameters are defined using curly braces {}.
For example, when defining a path parameter for an order ID, the path could be /orders/{order_id}.
Wildcard paths are supported to capture multiple path segments after a prefix such as /{proxy+} or /api/v1/{proxy+}.
✅ Available in v0
type
string
examples
/orders
/orders/{order_id}
/{proxy+}
/api/v1/{proxy+}
default value
/
celerity.handler.websocket
Enables the handler to respond to WebSocket messages for a Celerity API.
✅ Available in v0
type
boolean
celerity.handler.websocket.route
The route that the handler will respond to for WebSocket messages.
This is the value of the configured routeKey of a WebSocket API.
A WebSocket API comes with predefined connection life cycle route keys and a default route key to fall back to $connect, $disconnect, and $default.
✅ Available in v0
type
string
default value
$default
examples
$connect
$disconnect
myAction
celerity.handler.guard.protectedBy
Enables the handler to use a specified guard (or comma-separated ordered list of guards) for incoming requests.
The guard(s) must be defined in the linked celerity/api resource.
This is only supported for HTTP handlers, WebSockets are authenticated at the connection level.
When multiple guards are specified, they execute in order and all must pass.
Claims from all passing guards are accumulated and namespaced by guard name in request.auth.
✅ Available in v0
type
string
examples
"jwt" | "jwt,rbac"
celerity.handler.public
Marks the handler as public, opting it out of authentication even when a default guard is configured for the linked celerity/api resource.
This is only supported for HTTP handlers, WebSockets are authenticated at the connection level.
✅ Available in v0
type
boolean
celerity.handler.guard.custom
The name of the custom auth guard that should use this handler to validate incoming requests or messages.
The guard must be defined in the linked celerity/api resource.
✅ Available in v0
type
string
celerity/schedule 🔗 celerity/handler
celerity.handler.schedule
Marks the handler to be used with a schedule for handling scheduled events. This is only required when there is ambiguity where a handler is linked from multiple resources in a blueprint (e.g. a consumer, API and schedule). If the handler is only linked to a schedule, this annotation is not required and the default behaviour is to use the handler with the schedule.
You should avoid using the same linkSelector for multiple schedules to avoid associating the wrong handler with a schedule, instead, it is best to be specific
in selecting the handler to associate with a schedule.
✅ Available in v0
type
boolean
celerity/consumer 🔗 celerity/handler
celerity.handler.consumer
Marks the handler to be used with a consumer for incoming messages from a queue or message broker. This is only required when there is ambiguity where a handler is linked to any combination of consumers, apis or schedules. If the handler is only linked to consumers, this annotation is not required and the default behaviour is to use the handler with the consumer.
✅ Available in v0
type
boolean
celerity.handler.consumer.route
Specifies a route or event type that the handler will respond to when processing messages from a consumer. Consumer routing requires mesages to be valid JSON objects containing the configured routing key, which is event by default.
If you want to set a default handler to fall back to when there is no specific route match, you must include this annotation for the default handler and set its value to $default.
✅ Available in v0
type
string
celerity/workflow 🔗 celerity/handler
celerity.handler.workflow
Marks the handler to be used as a step in a workflow; a step in this context is a state of type executeStep in a workflow.
This is only required when there is ambiguity where a handler is linked from multiple resources in a blueprint (e.g. a consumer, API and workflow). If the handler is only linked to a workflow, this annotation is not required and the default behaviour is to use the handler with the workflow.
✅ Available in v0
type
boolean
celerity.handler.workflow.state
The unique name of the state that the handler will be used to execute in the workflow.
The state in the workflow must be of the executeStep type.
🚀 Planned for v1 - This annotation is applicable for workflow applications deployed to AWS serverless (Step Functions) and local development environments.
type
string
celerity/channel 🔗 celerity/handler
The following are a set of annotations that configure a handler to process messages received on a channel and hook into channel events when linked from a celerity/channel resource.
celerity.handler.channel
Indicates that this handler is a channel handler that processes messages or hooks into channel events.
🔮 Planned for v1+
type
boolean
default value
false
celerity.handler.channel.event
The channel event that this handler responds to.
🔮 Planned for v1+
type
string
allowed values
"subscribe" | "unsubscribe" | "message"
| Event | When | Handler can... |
|---|---|---|
subscribe | Client requests subscription (after auth guard passes) | Accept/reject with custom authz logic, run side effects |
unsubscribe | Client unsubscribes or disconnects | Run cleanup, analytics |
message | Message published to the channel | Transform, filter, persist, or enrich before broadcast |
The subscribe handler's return value determines whether the subscription is accepted. This is the authz hook — the auth guard on the channel resource handles authn, and the subscribe handler adds application-specific authorisation (e.g. checking org membership in a database).
If no handler is linked, the channel works with just the auth guard — subscriptions are auto-accepted after authn.
default value
$default
celerity/vpc 🔗 celerity/handler
celerity.handler.vpc.subnetType
The type of subnet that the handler will be deployed to in a VPC. This is only considered for some serverless target environments where functions can be placed in specific subnets of a VPC (such as AWS Lambda); it has no effect on other targets. See how subnet types for handlers work in serverless environments for the per-target behaviour and the reasoning behind the default.
✅ Available in v0
type
string
allowed values
public | private
default value
private
Outputs
id
The unique identifier of the handler resource.
For serverless environments, this will a unique ID for a function such as an AWS Lambda function ARN.
For containerised or custom server environments where handlers are loaded into the runtime in a single process, this will be the same value as the spec.handlerName field.
type
string
examples
arn:aws:lambda:us-east-2:123456789012:function:example-handler-v1 (AWS Serverless)
projects/123456789/locations/us-east1/functions/example-handler-v1 (Google Cloud Serverless)
example-handler-v1 (Custom Server or Containerised Environment)
Linked From
celerity/api
When a handler is linked from an API, it will be used to respond to incoming HTTP requests or WebSocket messages. The configuration defined in the handler annotations determines the behaviour of the handler in respect to the API.
✅ Available in v0
celerity/schedule
When a handler is linked from a schedule, it will be invoked by the scheduled trigger. The configuration defined in the handler annotations determines the behaviour of the handler in respect to the schedule.
✅ Available in v0
Read more about Celerity schedules
celerity/consumer
When a handler is linked to a consumer, it will be used to process messages received from the external queue, message broker or other event source connected to or defined in the consumer. The configuration defined in the handler annotations determines the behaviour of the handler in respect to the consumer.
✅ Available in v0
Read more about Celerity consumers
celerity/channel
When a handler is linked from a channel, it processes messages received on the channel or hooks into channel events. The handler annotations celerity.handler.channel and celerity.handler.channel.event determine which event the handler responds to (subscribe, unsubscribe, or message).
The subscribe handler acts as an authz hook — the auth guard on the channel resource handles authn, and the subscribe handler adds application-specific authorisation. If no handler is linked, the channel works with just the auth guard.
🔮 Planned for v1+
Read more about Celerity channels
celerity/workflow
When a handler is linked to a workflow, it will be used to execute a step in the workflow. The configuration defined in the handler annotations determines the behaviour of the handler in respect to the workflow.
🚀 Planned for v1 - This link is applicable for workflow applications deployed to AWS serverless (Step Functions) and local development environments.
Read more about Celerity workflows
celerity/vpc
When deploying handlers as serverless functions, individual handlers may be deployed to specific VPCs for private access. When handlers are a part of a containerised or custom server application, the VPC associated with the application will be used and any links from VPCs to handlers will be ignored.
✅ Available in v0
Links To
celerity/queue
When a handler links out to a queue, it will be configured with permissions and environment variables to interact with the queue. If a secret store is associated with the handler or the application that it is a part of, the queue configuration will be added to the secret store instead of environment variables. You can use guides and templates to get an intuition for how to use the handlers SDK to interact with the queue.
Opting out of the handlers SDK for queues
You don't have to use the handlers SDK abstraction for queues, you can also grab the populated configuration directly and interact directly with the SDK for the queue service for the chosen target environment. Doing so will require application code changes if you decide to switch target environments.
✅ Available in v0
Read more about Celerity queues
celerity/topic
When a handler links out to a topic, it will be configured with permissions and environment variables that enable the handler to publish messages to the topic. If a secret store is associated with the handler or the application that it is a part of, the topic configuration will be added to the secret store instead of environment variables. You can use guides and templates to get an intuition for how to use the handlers SDK to publish messages to a topic.
Opting out of the handlers SDK for topics
You don't have to use the handlers SDK abstraction for topics, you can also grab the populated configuration directly and interact directly with the SDK for the pub/sub or messaging service for the chosen target environment. Doing so will require application code changes if you decide to switch target environments.
✅ Available in v0
Read more about Celerity topics
celerity/datastore
When a handler links out to a NoSQL data store, it will be configured with permissions and environment variables that enable the handler to interact with the data store. If a secret store is associated with the handler or the application that it is a part of, the data store configuration will be added to the secret store instead of environment variables. You can use guides and templates to get an intuition for how to source the configuration and interact with data store services using SDKs or libraries for the NoSQL data store service for the chosen target environment.
✅ Available in v0
Read more about Celerity datastores
celerity/sqlDatabase
When a handler links out to an SQL database, it will be configured with permissions and environment variables that enable the handler to interact with the data store. If a secret store is associated with the handler or the application that it is a part of, the SQL database configuration will be added to the secret store instead of environment variables. You can use guides and templates to get an intuition for how to source the configuration and interact with SQL databases using SDKs or libraries for the SQL database service for the chosen target environment.
✅ Available in v0
The Celerity SDK provides a credentials provider (getSqlDatabaseConnectionConfig) for use with any SQL library and an optional knex.js connection factory (createKnexClient) with managed connection pooling. For AWS serverless deployments, RDS Proxy is automatically provisioned to handle connection pooling for Lambda functions.
When the SQL database has authMode: "iam", the handler's execution identity (Lambda role, service account, or managed identity) is automatically granted the IAM permissions required for token-based database authentication on the target cloud provider.
Read more about Celerity SQL databases
celerity/bucket
When a handler links out to a bucket, it will be configured with permissions and environment variables that enable the handler to interact with the bucket. If a secret store is associated with the handler or the application that it is a part of, the bucket configuration will be added to the secret store instead of environment variables. You can use guides and templates to get an intuition for how to source the configuration and interact with object storage services using the handlers SDK.
Opting out of the handlers SDK for buckets
You don't have to use the handlers SDK abstraction for buckets, you can also grab the populated configuration directly and interact directly with the SDK for the object storage service for the chosen target environment. Doing so will require application code changes if you decide to switch target environments.
✅ Available in v0
Read more about Celerity buckets
celerity/cache
When a handler links out to a cache, it will be configured with permissions and environment variables that enable the handler to interact with the cache. If a secret store is associated with the handler or the application that it is a part of, the cache configuration will be added to the secret store instead of environment variables. You can use guides and templates to get an intuition for how to source the configuration and interact with cache services using libraries that are compatible with the Redis 7.2.4 API, as all cache services supported by Celerity are compatible with the Redis 7.2.4 API.
Note
Redis 7.2.4 was the last open-source version of Redis before the Redis Labs license change. Celerity supports cache services that are compatible with the Redis 7.2.4 API.
✅ Available in v0
The Celerity SDK provides a cache abstraction (createCacheClient) covering all core Redis data structures (strings, hashes, lists, sets, sorted sets), atomic counters, transactions and a credentials provider for direct Redis client access.
Read more about Celerity caches
celerity/workflow
When a handler links out to a workflow, it will be configured with permissions and environment variables that enable the handler to trigger the workflow. If a secret store is associated with the handler or the application that it is a part of, the workflow configuration will be added to the secret store instead of environment variables. You can use guides and templates to get an intuition for how to source the configuration and trigger the workflow using the handlers SDK.
Opting out of the handlers SDK for workflows
You don't have to use the handlers SDK abstraction for workflows, you can also grab the populated configuration directly and interact directly with the SDK for the workflow service for the chosen target environment. Doing so will require application code changes if you decide to switch target environments. For example, you can use the AWS Step Functions SDK to trigger a workflow in AWS Step Functions but this will not translate to Google Cloud Workflows, Azure Logic Apps or the Celerity Workflow runtime.
🚀 Planned for v1 - This link is applicable for workflow applications deployed to AWS serverless (Step Functions) and local development environments.
Read more about Celerity workflows
celerity/config
When a handler links out to a secret and configuration store, it will be configured with permissions and environment variables that will enable the handler to fetch secrets and configuration. These values will be fetched and passed into your handlers when they are created with the handlers SDK.
✅ Available in v0
Read more about Celerity config
celerity/handlerConfig
When a handler links out to a handler config resource, it inherit the shared configuration defined in the handler config resource. This is useful for sharing common values such as runtime, memory, timeout and environment variables.
✅ Available in v0
Read more about Celerity handler config
Sharing Handler Configuration
There are often times when you want to share common configuration across multiple handlers. Examples of shared configuration include environment variables, runtime, memory, and timeout values.
There are multiple approaches to sharing handler configuration in a Celerity application blueprint:
- Use a
celerity/handlerConfigresource type to define shared handler configuration and link it to specific handlers. This approach is useful when you want different groups of handlers to share different configurations. - Use a
metadatafield in the blueprint to define shared handler configuration that is applied to all handlers in the blueprint. This approach is useful when you want all handlers in the blueprint to share the same configuration.
For approach 1, see the celerity/handlerConfig resource type documentation.
For approach 2, you would define a metadata section in the blueprint like this:
Blueprint Language
version "2025-11-02"
transform "celerity-2026-02-27-draft"
# resources ...
metadata {
sharedHandlerConfig = {
runtime = "python3.13.x",
memory = 256,
timeout = 60,
environmentVariables = {
DB_HOST = variables.dbHost,
DB_PORT = variables.dbPort
}
}
}YAML
version: 2025-11-02
transform: celerity-2026-02-27-draft
resources:
# ...
metadata:
sharedHandlerConfig:
runtime: python3.13.x
memory: 256
timeout: 60
environmentVariables:
DB_HOST: "${variables.dbHost}"
DB_PORT: "${variables.dbPort}"In the above example, all handlers in the blueprint will share the same runtime, memory, timeout, and environment variables unless they are overridden in the handler definition.
The shared handler config has the same structure as the spec field of the celerity/handlerConfig resource type. You can find the available fields by taking a look at the specification section of the celerity/handlerConfig documentation.
Examples
The following set of examples include different configurations for the celerity/handler resource type
along with resource types that can be linked to the handler resource type to add more context.
Handlers for a HTTP API
Blueprint Language
version "2025-11-02"
transform "celerity-2026-02-27-draft"
# variable definitions ...
resource ordersApi: celerity/api {
metadata {
displayName = "Orders API"
}
select by label {
application = "orders"
}
spec {
# API spec configuration ...
}
}
resource saveOrderHandler: celerity/handler {
metadata {
displayName = "Save Order Handler"
annotations = {
"celerity.handler.http" = true,
"celerity.handler.http.method" = "POST",
"celerity.handler.http.path" = "/orders",
"celerity.handler.guard.protectedBy" = "authGuard"
}
labels = {
application = "orders"
}
}
spec {
handlerName = "SaveOrderHandler-v1"
codeLocation = "handlers/orders"
handler = "save_order"
runtime = "python3.13.x"
memory = 512
timeout = 30
tracingEnabled = false
environmentVariables = {
DB_HOST = variables.dbHost,
DB_PORT = variables.dbPort
}
}
}
resource authoriseHandler: celerity/handler {
metadata {
displayName = "Authorise Handler"
annotations = {
"celerity.handler.guard.custom" = "authGuard"
}
labels = {
application = "orders"
}
}
spec {
handlerName = "AuthoriseHandler-v1"
codeLocation = "handlers/auth"
handler = "authorise"
runtime = "python3.13.x"
memory = 512
timeout = 30
tracingEnabled = false
}
}YAML
version: 2025-11-02
transform: celerity-2026-02-27-draft
variables:
# Variable definitions ...
resources:
ordersApi:
type: "celerity/api"
metadata:
displayName: Orders API
linkSelector:
byLabel:
application: "orders"
spec:
# API spec configuration ...
saveOrderHandler:
type: "celerity/handler"
metadata:
displayName: Save Order Handler
annotations:
celerity.handler.http: true
celerity.handler.http.method: "POST"
celerity.handler.http.path: "/orders"
celerity.handler.guard.protectedBy: "authGuard"
labels:
application: "orders"
spec:
handlerName: "SaveOrderHandler-v1"
codeLocation: "handlers/orders"
handler: "save_order"
runtime: "python3.13.x"
memory: 512
timeout: 30
tracingEnabled: false
environmentVariables:
DB_HOST: "${variables.dbHost}"
DB_PORT: "${variables.dbPort}"
authoriseHandler:
type: "celerity/handler"
metadata:
displayName: Authorise Handler
annotations:
celerity.handler.guard.custom: "authGuard"
labels:
application: "orders"
spec:
handlerName: "AuthoriseHandler-v1"
codeLocation: "handlers/auth"
handler: "authorise"
runtime: "python3.13.x"
memory: 512
timeout: 30
tracingEnabled: falseHandlers for a WebSocket API
Blueprint Language
version "2025-11-02"
transform "celerity-2026-02-27-draft"
# variable definitions ...
resource ordersApi: celerity/api {
metadata {
displayName = "Order Stream API"
}
select by label {
application = "orderStream"
}
spec {
# API spec configuration ...
}
}
resource streamOrderHandler: celerity/handler {
metadata {
displayName = "Order Stream Handler"
annotations = {
"celerity.handler.websocket" = true,
"celerity.handler.websocket.route" = "orderStream"
}
labels = {
application = "orders"
}
}
spec {
handlerName = "StreamOrdersHandler-v1"
codeLocation = "handlers/orders"
handler = "stream_orders"
runtime = "python3.13.x"
memory = 512
timeout = 30
tracingEnabled = false
environmentVariables = {
DB_HOST = variables.dbHost,
DB_PORT = variables.dbPort
}
}
}
resource authoriseHandler: celerity/handler {
metadata {
displayName = "Authorise Handler"
annotations = {
"celerity.handler.guard.custom" = "authGuard"
}
labels = {
application = "orders"
}
}
spec {
handlerName = "AuthoriseHandler-v1"
codeLocation = "handlers/auth"
handler = "authorise"
runtime = "python3.13.x"
memory = 512
timeout = 30
tracingEnabled = false
}
}YAML
version: 2025-11-02
transform: celerity-2026-02-27-draft
variables:
# Variable definitions ...
resources:
ordersApi:
type: "celerity/api"
metadata:
displayName: Order Stream API
linkSelector:
byLabel:
application: "orderStream"
spec:
# API spec configuration ...
streamOrderHandler:
type: "celerity/handler"
metadata:
displayName: Order Stream Handler
annotations:
celerity.handler.websocket: true
celerity.handler.websocket.route: "orderStream"
labels:
application: "orders"
spec:
handlerName: "StreamOrdersHandler-v1"
codeLocation: "handlers/orders"
handler: "stream_orders"
runtime: "python3.13.x"
memory: 512
timeout: 30
tracingEnabled: false
environmentVariables:
DB_HOST: "${variables.dbHost}"
DB_PORT: "${variables.dbPort}"
authoriseHandler:
type: "celerity/handler"
metadata:
displayName: Authorise Handler
annotations:
celerity.handler.guard.custom: "authGuard"
labels:
application: "orders"
spec:
handlerName: "AuthoriseHandler-v1"
codeLocation: "handlers/auth"
handler: "authorise"
runtime: "python3.13.x"
memory: 512
timeout: 30
tracingEnabled: falseHandlers for a Message Queue
Blueprint Language
version "2025-11-02"
transform "celerity-2026-02-27-draft"
# variable definitions ...
resource ordersQueue: celerity/queue {
metadata {
displayName = "Orders Queue"
}
select by label {
application = "ordersProcessing"
}
spec {
# Queue configuration ...
}
}
resource orderConsumer: celerity/consumer {
metadata {
displayName = "Order Consumer"
labels = {
application = "ordersProcessing"
}
}
select by label {
application = "ordersProcessing"
}
spec {
batchSize = 10
visibilityTimeout = 30
waitTimeSeconds = 10
partialFailures = true
}
}
resource processOrders: celerity/handler {
metadata {
displayName = "Process Orders Handler"
labels = {
application = "ordersProcessing"
}
}
spec {
handlerName = "ProcessOrders-v1"
codeLocation = "handlers/orders"
handler = "process_orders"
runtime = "python3.13.x"
memory = 512
timeout = 30
tracingEnabled = false
environmentVariables = {
DB_HOST = variables.dbHost,
DB_PORT = variables.dbPort
}
}
}YAML
version: 2025-11-02
transform: celerity-2026-02-27-draft
variables:
# Variable definitions ...
resources:
ordersQueue:
type: "celerity/queue"
metadata:
displayName: Orders Queue
linkSelector:
byLabel:
application: "ordersProcessing"
spec:
# Queue configuration ...
orderConsumer:
type: "celerity/consumer"
metadata:
displayName: Order Consumer
labels:
application: "ordersProcessing"
linkSelector:
byLabel:
application: "ordersProcessing"
spec:
batchSize: 10
visibilityTimeout: 30
waitTimeSeconds: 10
partialFailures: true
processOrders:
type: "celerity/handler"
metadata:
displayName: Process Orders Handler
labels:
application: "ordersProcessing"
spec:
handlerName: "ProcessOrders-v1"
codeLocation: "handlers/orders"
handler: "process_orders"
runtime: "python3.13.x"
memory: 512
timeout: 30
tracingEnabled: false
environmentVariables:
DB_HOST: "${variables.dbHost}"
DB_PORT: "${variables.dbPort}"Handlers for a Pub/Sub System
Blueprint Language
version "2025-11-02"
transform "celerity-2026-02-27-draft"
# The order updates topic ID would be defined in a separate blueprint
# following a standard practice in decoupling topics from applications
# when a topic can be subscribed to by multiple applications.
variable orderUpdatesTopicId: string {
description = "The ID of the Celerity topic for order updates."
}
resource orderUpdatesConsumer: celerity/consumer {
metadata {
displayName = "Order Updates Consumer"
}
select by label {
application = "orderUpdates"
}
spec {
sourceId = variables.orderUpdatesTopicId
}
}
resource orderUpdateHandler: celerity/handler {
metadata {
displayName = "Order Update Handler"
labels = {
application = "orderUpdates"
}
}
spec {
handlerName = "OrderUpdateHandler-v1"
codeLocation = "handlers/orders"
handler = "order_update_processor"
runtime = "python3.13.x"
memory = 512
timeout = 30
tracingEnabled = false
environmentVariables = {
DB_HOST = variables.dbHost,
DB_PORT = variables.dbPort
}
}
}YAML
version: 2025-11-02
transform: celerity-2026-02-27-draft
variables:
# The order updates topic ID would be defined in a separate blueprint
# following a standard practice in decoupling topics from applications
# when a topic can be subscribed to by multiple applications.
orderUpdatesTopicId:
type: string
description: The ID of the Celerity topic for order updates.
resources:
orderUpdatesConsumer:
type: "celerity/consumer"
metadata:
displayName: Order Updates Consumer
linkSelector:
byLabel:
application: "orderUpdates"
spec:
sourceId: "${variables.orderUpdatesTopicId}"
orderUpdateHandler:
type: "celerity/handler"
metadata:
displayName: Order Update Handler
labels:
application: "orderUpdates"
spec:
handlerName: "OrderUpdateHandler-v1"
codeLocation: "handlers/orders"
handler: "order_update_processor"
runtime: "python3.13.x"
memory: 512
timeout: 30
tracingEnabled: false
environmentVariables:
DB_HOST: "${variables.dbHost}"
DB_PORT: "${variables.dbPort}"Handlers for a Pub/Sub System with Routing
Blueprint Language
version "2025-11-02"
transform "celerity-2026-02-27-draft"
# The order events topic ID would be defined in a separate blueprint
# following a standard practice in decoupling topics from applications
# when a topic can be subscribed to by multiple applications.
variable orderEventsTopicId: string {
description = "The ID of the Celerity topic for order events."
}
resource orderEventsConsumer: celerity/consumer {
metadata {
displayName = "Order Events Consumer"
}
select by label {
application = "orderEvents"
}
spec {
sourceId = variables.orderEventsTopicId
routingKey = "eventType"
}
}
resource orderRemovalHandler: celerity/handler {
metadata {
displayName = "Remove Order Handler"
labels = {
application = "orderEvents"
}
annotations = {
"celerity.handler.consumer.route" = "orderRemoved"
}
}
spec {
handlerName = "RemoveOrderHandler-v1"
codeLocation = "handlers/orders"
handler = "remove_order"
runtime = "python3.13.x"
memory = 512
timeout = 30
tracingEnabled = false
environmentVariables = {
DB_HOST = variables.dbHost,
DB_PORT = variables.dbPort
}
}
}
resource orderChangeHandler: celerity/handler {
metadata {
displayName = "Order Change Handler"
labels = {
application = "orderEvents"
}
annotations = {
"celerity.handler.consumer.route" = "orderChanged"
}
}
spec {
handlerName = "OrderChangeHandler-v1"
codeLocation = "handlers/orders"
handler = "order_change_processor"
runtime = "python3.13.x"
memory = 512
timeout = 30
tracingEnabled = false
environmentVariables = {
DB_HOST = variables.dbHost,
DB_PORT = variables.dbPort
}
}
}YAML
version: 2025-11-02
transform: celerity-2026-02-27-draft
variables:
# The order events topic ID would be defined in a separate blueprint
# following a standard practice in decoupling topics from applications
# when a topic can be subscribed to by multiple applications.
orderEventsTopicId:
type: string
description: The ID of the Celerity topic for order events.
resources:
orderEventsConsumer:
type: "celerity/consumer"
metadata:
displayName: Order Events Consumer
linkSelector:
byLabel:
application: "orderEvents"
spec:
sourceId: "${variables.orderEventsTopicId}"
routingKey: "eventType"
orderRemovalHandler:
type: "celerity/handler"
metadata:
displayName: Remove Order Handler
labels:
application: "orderEvents"
annotations:
celerity.handler.consumer.route: "orderRemoved"
spec:
handlerName: "RemoveOrderHandler-v1"
codeLocation: "handlers/orders"
handler: "remove_order"
runtime: "python3.13.x"
memory: 512
timeout: 30
tracingEnabled: false
environmentVariables:
DB_HOST: "${variables.dbHost}"
DB_PORT: "${variables.dbPort}"
orderChangeHandler:
type: "celerity/handler"
metadata:
displayName: Order Change Handler
labels:
application: "orderEvents"
annotations:
celerity.handler.consumer.route: "orderChanged"
spec:
handlerName: "OrderChangeHandler-v1"
codeLocation: "handlers/orders"
handler: "order_change_processor"
runtime: "python3.13.x"
memory: 512
timeout: 30
tracingEnabled: false
environmentVariables:
DB_HOST: "${variables.dbHost}"
DB_PORT: "${variables.dbPort}"Handlers for a Data Store Stream
Blueprint Language
version "2025-11-02"
transform "celerity-2026-02-27-draft"
# variable definitions ...
resource ordersTable: celerity/datastore {
metadata {
displayName = "Orders Table"
}
select by label {
application = "orders"
}
spec {
# Data store configuration ...
}
}
resource orderEventsConsumer: celerity/consumer {
metadata {
displayName = "Order Updates Consumer"
labels = {
application = "orders"
}
}
select by label {
application = "orders"
}
spec {
batchSize = 10
partialFailures = true
startFromBeginning = true
}
}
resource processOrderEvents: celerity/handler {
metadata {
displayName = "Process Order Events Handler"
labels = {
application = "orders"
}
}
spec {
handlerName = "ProcessOrderEvents-v1"
codeLocation = "handlers/orders"
handler = "process_order_events"
runtime = "python3.13.x"
memory = 512
timeout = 30
tracingEnabled = false
}
}YAML
version: 2025-11-02
transform: celerity-2026-02-27-draft
variables:
# Variable definitions ...
resources:
ordersTable:
type: "celerity/datastore"
metadata:
displayName: Orders Table
linkSelector:
byLabel:
application: "orders"
spec:
# Data store configuration ...
orderEventsConsumer:
type: "celerity/consumer"
metadata:
displayName: Order Updates Consumer
labels:
application: "orders"
linkSelector:
byLabel:
application: "orders"
spec:
batchSize: 10
partialFailures: true
startFromBeginning: true
processOrderEvents:
type: "celerity/handler"
metadata:
displayName: Process Order Events Handler
labels:
application: "orders"
spec:
handlerName: "ProcessOrderEvents-v1"
codeLocation: "handlers/orders"
handler: "process_order_events"
runtime: "python3.13.x"
memory: 512
timeout: 30
tracingEnabled: falseHandlers for a Hybrid Application (Pub/Sub, HTTP, WebSocket)
Blueprint Language
version "2025-11-02"
transform "celerity-2026-02-27-draft"
# variable definitions ...
resource ordersApi: celerity/api {
metadata {
displayName = "Orders API"
annotations = {
# Celerity app annotation to group API and consumer
# resources to be deployed as a single application.
"celerity.app" = "orderService"
}
}
select by label {
application = "orders"
}
spec {
# API spec configuration ...
}
}
resource orderUpdatesConsumer: celerity/consumer {
metadata {
displayName = "Order Updates Consumer"
annotations = {
"celerity.app" = "orderService"
}
}
select by label {
application = "orders"
}
spec {
# Consumer configuration ...
}
}
resource streamOrderHandler: celerity/handler {
metadata {
displayName = "Order Stream Handler"
annotations = {
"celerity.handler.websocket" = true,
"celerity.handler.websocket.route" = "orderStream"
}
labels = {
application = "orders"
}
}
spec {
handlerName = "StreamOrdersHandler-v1"
codeLocation = "handlers/orders"
handler = "stream_orders"
runtime = "python3.13.x"
memory = 512
timeout = 30
tracingEnabled = false
environmentVariables = {
DB_HOST = variables.dbHost,
DB_PORT = variables.dbPort
}
}
}
resource saveOrderHandler: celerity/handler {
metadata {
displayName = "Save Order Handler"
annotations = {
"celerity.handler.http" = true,
"celerity.handler.http.method" = "POST",
"celerity.handler.http.path" = "/orders",
"celerity.handler.guard.protectedBy" = "authGuard"
}
labels = {
application = "orders"
}
}
spec {
handlerName = "SaveOrderHandler-v1"
codeLocation = "handlers/orders"
handler = "save_order"
runtime = "python3.13.x"
memory = 512
timeout = 30
tracingEnabled = false
environmentVariables = {
DB_HOST = variables.dbHost,
DB_PORT = variables.dbPort
}
}
}
resource authoriseHandler: celerity/handler {
metadata {
displayName = "Authorise Handler"
annotations = {
"celerity.handler.guard.custom" = "authGuard"
}
labels = {
application = "orders"
}
}
spec {
handlerName = "AuthoriseHandler-v1"
codeLocation = "handlers/auth"
handler = "authorise"
runtime = "python3.13.x"
memory = 512
timeout = 30
tracingEnabled = false
}
}
resource orderUpdateHandler: celerity/handler {
metadata {
displayName = "Order Update Handler"
annotations = {
"celerity.handler.consumer" = true
}
labels = {
application = "orders"
}
}
spec {
handlerName = "OrderUpdateHandler-v1"
codeLocation = "handlers/orders"
handler = "order_update_processor"
runtime = "python3.13.x"
memory = 512
timeout = 30
tracingEnabled = false
environmentVariables = {
DB_HOST = variables.dbHost,
DB_PORT = variables.dbPort
}
}
}YAML
version: 2025-11-02
transform: celerity-2026-02-27-draft
variables:
# Variable definitions ...
resources:
ordersApi:
type: "celerity/api"
metadata:
displayName: Orders API
annotations:
# Celerity app annotation to group API and consumer
# resources to be deployed as a single application.
celerity.app: "orderService"
linkSelector:
byLabel:
application: "orders"
spec:
# API spec configuration ...
orderUpdatesConsumer:
type: "celerity/consumer"
metadata:
displayName: Order Updates Consumer
annotations:
celerity.app: "orderService"
linkSelector:
byLabel:
application: "orders"
spec:
# Consumer configuration ...
streamOrderHandler:
type: "celerity/handler"
metadata:
displayName: Order Stream Handler
annotations:
celerity.handler.websocket: true
celerity.handler.websocket.route: "orderStream"
labels:
application: "orders"
spec:
handlerName: "StreamOrdersHandler-v1"
codeLocation: "handlers/orders"
handler: "stream_orders"
runtime: "python3.13.x"
memory: 512
timeout: 30
tracingEnabled: false
environmentVariables:
DB_HOST: "${variables.dbHost}"
DB_PORT: "${variables.dbPort}"
saveOrderHandler:
type: "celerity/handler"
metadata:
displayName: Save Order Handler
annotations:
celerity.handler.http: true
celerity.handler.http.method: "POST"
celerity.handler.http.path: "/orders"
celerity.handler.guard.protectedBy: "authGuard"
labels:
application: "orders"
spec:
handlerName: "SaveOrderHandler-v1"
codeLocation: "handlers/orders"
handler: "save_order"
runtime: "python3.13.x"
memory: 512
timeout: 30
tracingEnabled: false
environmentVariables:
DB_HOST: "${variables.dbHost}"
DB_PORT: "${variables.dbPort}"
authoriseHandler:
type: "celerity/handler"
metadata:
displayName: Authorise Handler
annotations:
celerity.handler.guard.custom: "authGuard"
labels:
application: "orders"
spec:
handlerName: "AuthoriseHandler-v1"
codeLocation: "handlers/auth"
handler: "authorise"
runtime: "python3.13.x"
memory: 512
timeout: 30
tracingEnabled: false
orderUpdateHandler:
type: "celerity/handler"
metadata:
displayName: Order Update Handler
annotations:
celerity.handler.consumer: true
labels:
application: "orders"
spec:
handlerName: "OrderUpdateHandler-v1"
codeLocation: "handlers/orders"
handler: "order_update_processor"
runtime: "python3.13.x"
memory: 512
timeout: 30
tracingEnabled: false
environmentVariables:
DB_HOST: "${variables.dbHost}"
DB_PORT: "${variables.dbPort}"Handlers for Scheduled Events
Blueprint Language
version "2025-11-02"
transform "celerity-2026-02-27-draft"
resource syncOrdersSchedule: celerity/schedule {
metadata {
displayName = "Sync Orders Schedule"
}
select by label {
application = "syncOrders"
}
spec {
schedule = "rate(1 hour)"
}
}
resource syncOrdersHandler: celerity/handler {
metadata {
displayName = "Sync Orders Handler"
labels = {
application = "syncOrders"
}
}
spec {
handlerName = "SyncOrders-Handler-v1"
codeLocation = "handlers/orders"
handler = "sync"
runtime = "python3.13.x"
memory = 512
timeout = 30
tracingEnabled = false
environmentVariables = {
DB_HOST = variables.dbHost,
DB_PORT = variables.dbPort
}
}
}YAML
version: 2025-11-02
transform: celerity-2026-02-27-draft
resources:
syncOrdersSchedule:
type: "celerity/schedule"
metadata:
displayName: Sync Orders Schedule
linkSelector:
byLabel:
application: "syncOrders"
spec:
schedule: "rate(1 hour)"
syncOrdersHandler:
type: "celerity/handler"
metadata:
displayName: Sync Orders Handler
labels:
application: "syncOrders"
spec:
handlerName: "SyncOrders-Handler-v1"
codeLocation: "handlers/orders"
handler: "sync"
runtime: "python3.13.x"
memory: 512
timeout: 30
tracingEnabled: false
environmentVariables:
DB_HOST: "${variables.dbHost}"
DB_PORT: "${variables.dbPort}"Handlers for Cloud Object Storage Events (External)
Blueprint Language
version "2025-11-02"
transform "celerity-2026-02-27-draft"
# variable definitions ...
resource orderEventsConsumer: celerity/consumer {
metadata {
displayName = "Order Events Consumer"
}
select by label {
application = "invoices"
}
spec {
externalEvents = {
sourceType = "objectStorage",
sourceConfiguration = {
events = ["created", "deleted"],
bucket = "order-events-bucket"
}
}
}
}
resource invoiceHandler: celerity/handler {
metadata {
displayName = "Invoice Handler"
labels = {
application = "invoices"
}
}
spec {
handlerName = "Invoice-Handler-v1"
codeLocation = "handlers/invoices"
handler = "invoice_handler"
runtime = "python3.13.x"
memory = 512
timeout = 30
tracingEnabled = false
environmentVariables = {
DB_HOST = variables.dbHost,
DB_PORT = variables.dbPort
}
}
}YAML
version: 2025-11-02
transform: celerity-2026-02-27-draft
variables:
# Variable definitions ...
resources:
orderEventsConsumer:
type: "celerity/consumer"
metadata:
displayName: Order Events Consumer
linkSelector:
byLabel:
application: "invoices"
spec:
externalEvents:
sourceType: "objectStorage"
sourceConfiguration:
events: ["created", "deleted"]
bucket: "order-events-bucket"
invoiceHandler:
type: "celerity/handler"
metadata:
displayName: Invoice Handler
labels:
application: "invoices"
spec:
handlerName: "Invoice-Handler-v1"
codeLocation: "handlers/invoices"
handler: "invoice_handler"
runtime: "python3.13.x"
memory: 512
timeout: 30
tracingEnabled: false
environmentVariables:
DB_HOST: "${variables.dbHost}"
DB_PORT: "${variables.dbPort}"Handlers for Data Streams (External)
Blueprint Language
version "2025-11-02"
transform "celerity-2026-02-27-draft"
# variable definitions ...
resource orderEventsConsumer: celerity/consumer {
metadata {
displayName = "Order Events Consumer"
}
select by label {
application = "invoices"
}
spec {
externalEvents = {
sourceType = "dataStream",
sourceConfiguration = {
batchSize = 100,
# Hard-coding the ID of the data stream like this would couple your application
# to an AWS target environment, it would be better to parameterise
# the stream ID by passing it in as a variable.
dataStreamId = "arn:aws:kinesis:us-east-1:123456789012:stream/MyStream",
partialFailures = true,
startFromBeginning = true
}
}
}
}
resource orderEventHandler: celerity/handler {
metadata {
displayName = "Order Event Handler"
labels = {
application = "invoices"
}
}
spec {
handlerName = "OrderEvent-Handler-v1"
codeLocation = "handlers/orders"
handler = "event_handler"
runtime = "python3.13.x"
memory = 512
timeout = 30
tracingEnabled = false
environmentVariables = {
DB_HOST = variables.dbHost,
DB_PORT = variables.dbPort
}
}
}YAML
version: 2025-11-02
transform: celerity-2026-02-27-draft
variables:
# Variable definitions ...
resources:
orderEventsConsumer:
type: "celerity/consumer"
metadata:
displayName: Order Events Consumer
linkSelector:
byLabel:
application: "invoices"
spec:
externalEvents:
sourceType: "dataStream"
sourceConfiguration:
batchSize: 100
# Hard-coding the ID of the data stream like this would couple your application
# to an AWS target environment, it would be better to parameterise
# the stream ID by passing it in as a variable.
dataStreamId: "arn:aws:kinesis:us-east-1:123456789012:stream/MyStream"
partialFailures: true
startFromBeginning: true
orderEventHandler:
type: "celerity/handler"
metadata:
displayName: Order Event Handler
labels:
application: "invoices"
spec:
handlerName: "OrderEvent-Handler-v1"
codeLocation: "handlers/orders"
handler: "event_handler"
runtime: "python3.13.x"
memory: 512
timeout: 30
tracingEnabled: false
environmentVariables:
DB_HOST: "${variables.dbHost}"
DB_PORT: "${variables.dbPort}"Runtimes
The runtime field on a handler spec accepts a Celerity runtime identifier. This is a portable string that both the CLI and the Celerity deploy engine understand: you set it once in the blueprint and Celerity maps it to the correct concrete runtime in each environment.
Supported Runtimes
| Runtime | Runtime ID | Operating System | Lifecycle Phase |
|---|---|---|---|
| Node.js 24 | nodejs24.x | Debian 13 (trixie) | Active |
| Python 3.13 | python3.13.x | Debian 13 (trixie) | Active |
Support for additional runtimes will come in the lead up to the v1 release in 2027.
For full details on runtime support timelines, deprecation policy and lifecycle phases, see the Runtime Lifecycle & Support Policy.
Runtime Mapping
The Celerity runtime identifier is resolved to a concrete runtime in each environment. The CLI handles local development, and the Celerity deploy engine handles each deployment target.
| Environment | Resolved by | Example for python3.13.x |
|---|---|---|
| Local development | Celerity CLI (celerity dev run) | Celerity runtime container image (ghcr.io/newstack-cloud/celerity-runtime-python-3-13) |
| AWS Lambda | Celerity deploy engine | Lambda runtime python3.13 |
| AWS containerised (ECS/EKS) | Celerity deploy engine | Celerity runtime container image |
| Google Cloud Functions | Celerity deploy engine | python313 (🚀 Planned for v1) |
| Google Cloud containerised (Cloud Run/GKE) | Celerity deploy engine | Celerity runtime container image (🚀 Planned for v1) |
| Azure Functions | Celerity deploy engine | Python 3.13 worker or custom handler (🚀 Planned for v1) |
| Azure containerised (Container Apps/AKS) | Celerity deploy engine | Celerity runtime container image (🚀 Planned for v1) |
The Celerity deploy engine chooses the closest available runtime on each target platform. If a target doesn't support the exact version, it falls back to the nearest supported version and surfaces a warning during celerity deploy.
Google Cloud Functions and OS-only runtimes
Google Cloud Functions do not support OS-only runtimes where pre-compiled binaries are used for handlers. The only language supported in Google Cloud Functions that is compiled in other environments is Go.
Azure Functions and OS-only runtimes
Azure Functions do not support OS-only runtimes in the same way as the Celerity runtime and AWS Lambda. Azure Functions do support custom handlers that are compiled light-weight HTTP servers that run in the Azure Functions runtime environment. Celerity will map OS-only runtime identifiers (os.*) to custom handlers in Azure Functions.
Overriding the mapped runtime
🚀 Planned for v1 — For edge cases where you need a specific target-platform runtime version that differs from the default mapping, you will be able to override it in the app deploy configuration via a target-specific key (e.g. aws.lambda.<handlerName>.runtime). This override is planned and not yet available in v0.
Target Environments
Local Development
✅ Available in v0
In the local development environment, handlers are loaded into the Celerity runtime in a single process.
Depending on links and configuration, the handler will be wired up to the appropriate HTTP route, WebSocket route, event source, stream or scheduled trigger.
In the local development environment, event sources and datastore streams will flow through Valkey, either as a message sent directly to a stream consumed by the Celerity runtime or to a pub/sub channel in Valkey that the Celerity runtime will be subscribed to indirectly through a stream. Events to trigger handlers are configured through the celerity/consumer resource type.
AWS
🚀 Planned for v1 - This target environment will be available in a future v0 evolution.
In the AWS environment, handlers are loaded into the Celerity runtime in a single process. Depending on links and configuration, the handler will be wired up to the appropriate HTTP route, WebSocket route, event source, stream or scheduled trigger. Services such as Kinesis and SQS will be wired up directly to the application in the runtime that will forward messages to the handler, other event sources will have some glue components such as an SQS Queue that the application will poll for events. The Celerity runtime works in tandem with the Bluelink deploy engine to make sure that handlers are wired up correctly to the event sources even when there is no direct connection between the application running in the Celerity runtime and the event source.
AWS Serverless
✅ Available in v0
In the AWS Serverless environment, handlers are deployed as AWS Lambda functions. Depending on links and configuration, the handler will be wired up to the appropriate HTTP route, WebSocket route, event source, stream or scheduled trigger. HTTP and WebSocket handlers will be wired up to API Gateway, event sources such as DynamoDB Streams and S3 will be wired up to the Lambda function directly. For scheduled triggers, Amazon EventBridge rules will be configured to trigger the Lambda function at the specified schedule. For queues, SQS queues will be configured as triggers for the Lambda function. For workflows, AWS Step Functions will be configured to trigger the Lambda function as a step in the workflow.
Google Cloud
🚀 Planned for v1 - This target environment will be available in a future v0 evolution.
In the Google Cloud environment, handlers are loaded into the Celerity runtime in a single process. Depending on links and configuration, the handler will be wired up to the appropriate HTTP route, WebSocket route, event source, stream or scheduled trigger. Google Cloud Pub/Sub will be wired up directly to the application in the runtime that will forward messages to the handler, other event sources will have some glue components such as a Pub/Sub topic that the application will poll for events. The Celerity runtime works in tandem with the Bluelink deploy engine to make sure that handlers are wired up correctly to the event sources even when there is no direct connection between the application running in the Celerity runtime and the event source.
Google Cloud Serverless
🚀 Planned for v1 - This target environment will be available in a future v0 evolution.
In the Google Cloud Serverless environment, handlers are deployed as Google Cloud Functions. Depending on the links and configuration, the handler will be wired up to the appropriate HTTP route, event source, stream or scheduled trigger. HTTP handlers will be wired up to Google Cloud API Gateway, event sources such as Google Cloud Pub/Sub, Google Cloud Storage and Google Cloud Firestore will be wired up to the Cloud Function directly. For scheduled triggers, Cloud Scheduler and Pub/Sub will be combined to trigger the function. For queues, Google Cloud Pub/Sub topics will be configured as triggers for the Cloud Function. For workflows, Google Cloud Workflows will be configured to trigger the Cloud Function as a step in the workflow.
Warning
Google Cloud Serverless does not support WebSocket APIs, meaning handlers linked from WebSocket APIs can not be deployed to Google Cloud Functions.
Azure
🚀 Planned for v1 - This target environment will be available in a future v0 evolution.
In the Azure environment, handlers are loaded into the Celerity runtime in a single process. Depending on links and configuration, the handler will be wired up to the appropriate HTTP route, WebSocket route, event source, stream or scheduled trigger. Azure Queue Storage queues will be wired up directly to the application in the runtime that will forward messages to the handler, other event sources will have some glue components such as a Queue Storage queue that the application will poll for events. The Celerity runtime works in tandem with the Bluelink deploy engine to make sure that handlers are wired up correctly to the event sources even when there is no direct connection between the application running in the Celerity runtime and the event source.
Azure Serverless
🚀 Planned for v1 - This target environment will be available in a future v0 evolution.
In the Azure Serverless environment, handlers are deployed as Azure Functions. Depending on links and configuration, the handler will be wired up to the appropriate HTTP route, WebSocket route, event source, stream or scheduled trigger. HTTP handlers will be wired up to Azure API Management, event sources such as Azure Event Hubs, Azure Blob Storage and Azure Queue Storage will be wired up to the Azure Function directly. For scheduled triggers, a timer trigger is configured for the function. For queues, Azure Queue Storage queues will be configured as triggers for the Azure Function. For workflows, Azure Logic Apps will be configured to trigger the Azure Function as a step in the workflow.
Timeouts and long-running tasks
In a Serverless environment, the maximum execution time for a handler is limited. Often, there are tasks that require more time to complete than the maximum timeout allowed by FaaS providers. In such cases, you can choose to deploy your application to the containerised alternative for your chosen cloud provider.
In the case that your application is a celerity/workflow, you could consider breaking down the long-running task into smaller tasks, if that isn't possible, you can switch to the containerised environment where the Celerity workflow runtime will be used to orchestrate your workflows instead of the cloud service equivalent.
Note
When using the Celerity workflow runtime, you can still define timeouts for individual tasks, the limits are a lot higher than those of FaaS providers.
Warning
Using the Celerity workflow runtime as an alternative to cloud provider workflow orchestration services requires persistence of workflow state to a database, this is managed by Celerity but will use the resources in your cloud provider account. See the celerity/workflow documentation for more information.
| Celerity Runtime Maximum Timeout | AWS Lambda Maximum Timeout | Google Cloud Functions Maximum Timeout | Azure Functions Maximum Timeout |
|---|---|---|---|
| Unlimited when backed by self-managed VMs; otherwise, the timeout limit of a "serverless" container service (e.g. AWS Fargate or Google Cloud Run). | 900 seconds (15 minutes) | 3600 seconds (60 minutes) | 230 seconds for HTTP triggered functions, no maximum execution time-out is defined for functions that are triggered by other means. |
Footnotes
Last updated on