Runtime Lifecycle & Support Policy

Celerity maintains container-based runtimes for running handlers in containerised and local development environments. Language runtimes are tied to upstream language versions and follow a formal lifecycle with defined support windows. OS-only runtimes, which run pre-compiled handler binaries against the Celerity core runtime, are tied to their base operating system image and to the IPC protocol version instead, see OS-only Runtimes.

For cloud provider serverless runtimes (AWS Lambda, Google Cloud Functions, Azure Functions), the lifecycle is managed by the respective cloud provider. See Cloud Provider Runtimes for details.

Lifecycle Phases

Every Celerity runtime moves through the following phases:

Active

A runtime in the Active phase is the recommended version for production use. It receives bug fixes, security patches, and runtime updates as they become available upstream.

A runtime remains Active as long as it is the latest supported version of its language in Celerity, even if the upstream version has moved to a maintenance or extended support phase. It transitions to Security-Only when Celerity adds support for a newer version of the same language.

Security-Only

A runtime in the Security-Only phase continues to receive security patches but no new features or non-critical bug fixes. Applications running on a Security-Only runtime will continue to work, but you should plan your migration to the Active runtime for that language.

A runtime enters Security-Only when Celerity adopts a newer version of the same language. It remains in this phase until the upstream version approaches or reaches its end of life for security fixes.

Deprecated

A runtime in the Deprecated phase is scheduled for removal. It receives critical security patches on a best-effort basis only.

A runtime enters the Deprecated phase when the upstream version is in its final 12 months of security support or has already reached end of life. The Deprecated phase lasts a minimum of 6 months to give you time to migrate.

End of Life

A runtime that has reached End of Life is no longer available. Runtime images are no longer published or updated. Existing deployments will continue to run but will receive no further patches.

The Celerity CLI will emit errors (not just warnings) when attempting to build or deploy with an End of Life runtime.

Current Runtime Support

OS-only Runtimes

An OS-only runtime ships the Celerity core runtime on a bare operating system image with no language interpreter or language-specific SDK bindings. Your handler is a pre-compiled binary that the core runtime starts as a separate process and communicates with over the Celerity IPC protocol.

This is how Celerity supports compiled languages. Rather than publishing a runtime per compiled language, the language-specific part lives in the Celerity SDK for that language. The Go SDK, for example, produces a handler executable that speaks the IPC protocol, and that executable runs on any OS-only runtime. One OS-only runtime therefore serves every compiled language Celerity has an SDK for.

Because there is no language version involved, two independent support clocks apply to an OS-only runtime:

Runtime Identifiers

Each supported operating system variation is published as its own runtime identifier in the form os-only.{osVersion}, for example, os-only.debian13. Each variation is listed as a separate runtime in Current Runtime Support, with its own lifecycle phase and its own dates. Variations are never rolled forward in place: adopting a new base OS means adding a new runtime identifier, not changing what an existing one resolves to.

An OS-only runtime enters the Active phase when it is added, and the previous OS-only variation transitions to Security-Only at that point, mirroring the policy for language runtimes.

IPC Protocol Compatibility

The IPC protocol is versioned as MAJOR.MINOR and is negotiated at the handshake, when your handler process connects to the core runtime. Both ends declare the version they speak, and a handler built against a major version the runtime does not serve is refused there rather than failing later on a frame it cannot read. See Version Negotiation. The Celerity SDK you compile your handler against determines the protocol version that binary speaks.

The following guarantees apply:

• Minor versions are additive only. A handler binary built against protocol 1.x runs unmodified on any runtime image that supports protocol major version 1, including later minor versions. New optional capabilities may be added in a minor version; existing messages and their semantics are never changed or removed.
• Major versions get a minimum 12-month dual-support window. When a new major protocol version is released, runtime images continue to accept the previous major version for at least 12 months from the release date of the new major version. During that window the Celerity CLI emits warnings at build time for handlers still using the older protocol, and a migration guide is published.
• The protocol clock is independent of the OS clock. A protocol major version is not tied to any particular OS-only runtime identifier, and its support window is not shortened by an OS-only runtime reaching End of Life. In practice, whichever of the two clocks expires first is the one that forces a rebuild.

Handler Binary Compatibility

The "OS" column for an OS-only runtime describes the image that Celerity publishes for local development and containerised targets. It does not describe every environment your handler binary may end up running in, the deploy engine maps OS-only runtime identifiers onto each target platform's own custom-runtime mechanism, which may be based on a different operating system.

Adoption Policy for New Runtimes

New versions of supported languages

Celerity aims to add support for new LTS or stable versions of already-supported languages (Node.js, Python) within 3 months of the upstream version entering its Active LTS or Full Support phase.

When a new version is added:

• The new runtime enters the Active phase.
• The previous version transitions to Security-Only.
• This page and the handler runtime table are updated with revised lifecycle dates.
• An announcement is made in release notes.

New languages

v1 (target: November 2027) adds C#. It enters the Active phase upon its initial Celerity release and follows the same lifecycle policy defined on this page.

Languages beyond it are considered case by case on demonstrated demand rather than committed in advance. A language runtime is a standing commitment rather than a one-off piece of work: everything on this page applies to it from the day it ships, including a published runtime image, security patching, adoption of new upstream versions within 3 months, and the Security-Only, Deprecated and End of Life windows.

This applies only to languages that need an interpreter or virtual machine in the runtime image. A compiled language such as Go is supported through its Celerity SDK, which produces a handler executable that runs on an existing OS-only runtime; adding a compiled-language SDK does not add a runtime to this page, and the OS-only lifecycle and IPC protocol guarantees are what apply to those handlers.

New OS-only runtime variations

Celerity aims to add an OS-only runtime for a new base operating system version within 3 months of that version's stable release. Each variation is added as a new os-only.{osVersion} identifier rather than by changing an existing one, so handler binaries pinned to an existing identifier are unaffected.

When a new OS-only variation is added:

• The new runtime enters the Active phase.
• The previous OS-only variation transitions to Security-Only.
• The IPC protocol version supported by the new image is unchanged unless separately announced; adopting a new base OS is not, by itself, a protocol change.

See the Celerity versions page for the full roadmap.

Deprecation Protocol

When a runtime approaches end of life, the following steps are carried out:

1. Announcement (6+ months before EOL): The runtime is moved to the Deprecated phase. An announcement is published in release notes and this page is updated with the EOL date.
2. CLI warnings: The Celerity CLI displays deprecation warnings when building or deploying applications that use the Deprecated runtime. Warnings include the EOL date and the recommended migration target.
3. Migration guide: A migration guide is published detailing the steps to move handlers to the replacement runtime version.
4. End of Life: After the EOL date, the runtime images are no longer published or updated. The Celerity CLI emits errors when attempting to build with an EOL runtime.

Deprecation Triggers

For OS-only runtimes, the base operating system image replaces the upstream language version as the trigger, and the IPC protocol carries its own separate trigger:

Cloud Provider Runtimes

When deploying handlers to cloud provider serverless platforms, the runtime lifecycle is governed by the respective cloud provider. Celerity does not control these runtimes and cannot extend their support beyond what the provider offers.

You always specify a Celerity runtime identifier in the blueprint, the Celerity deploy engine maps it to the concrete provider runtime at deploy time. Celerity tracks cloud provider runtime deprecations and will update the mapping, documentation and CLI warnings when a provider deprecates a runtime version.

AWS Lambda

The Celerity deploy engine maps each Celerity runtime identifier to a supported AWS Lambda runtime. When AWS deprecates a Lambda runtime that a mapping targets, Celerity will update the mapping to the next supported version and emit CLI warnings for applications affected by the change.

Google Cloud Functions

The Celerity deploy engine maps each Celerity runtime identifier to a supported Google Cloud Functions runtime. When Google deprecates a Cloud Functions runtime that a mapping targets, Celerity will update the mapping and emit CLI warnings for affected applications.

Azure Functions

The Celerity deploy engine maps each Celerity runtime identifier to a supported Azure Functions runtime. When Azure deprecates a Functions runtime that a mapping targets, Celerity will update the mapping and emit CLI warnings for affected applications.

Future Runtime Roadmap

Lifecycle dates for planned runtimes will be published when the runtimes are released. Each will follow the same lifecycle policy defined on this page.