Runtime

Runtime identifier declaring what language or platform the app needs. Platforms MAY use this to select a base image or buildpack.

Valid values: node, bun, deno, python, ruby, go, rust, java, php, elixir, csharp, static.

runtime: node

The runtime field is metadata — it describes the app, not the infrastructure. Changing the deployment target (Docker → Kubernetes → bare metal) does not change the runtime value.

Version is not part of runtime

The runtime field does not include a version. Platforms and AI analyzers should discover the version from ecosystem-standard files already in the repo:

Runtime Version source
node .nvmrc, .node-version, .tool-versions, package.json engines.node
bun .bun-version, .tool-versions, package.json engines.bun
python .python-version, .tool-versions, pyproject.toml, Pipfile
ruby .ruby-version, .tool-versions, Gemfile
go go.mod (first go directive)
java .java-version, .tool-versions

This avoids duplicating version information that already has a canonical source. If you need bun 3.1.13 or greater, declare it in .tool-versions or package.json:

# .tool-versions
bun 3.1.13

Relationship to image and build

runtime, image, and build serve different purposes and can coexist:

Combination Meaning
runtime only Platform selects a buildpack or base image
build only Build from source; platform infers runtime from Dockerfile
image only Use pre-built image; no build step
runtime + build Build from source; runtime is metadata
runtime + image Use pre-built image; runtime is metadata
build + image Build from source; image is the name/tag for the resulting artifact
All three Build from source, tag as image, runtime is metadata

Think of it like Docker Compose: build is how you create the image, image is the name/tag of the resulting artifact. When only image is provided, there's nothing to build — the platform pulls it directly.

esc
Type to search the docs