Choosing a version
Append a version to the runtime as "<language>:<version>", or leave it off for a supported default.
Append a version to the runtime — "<language>:<version>". Leave it off and a supported default is
used. static takes no version.
| Runtime | Supported versions | Default |
|---|---|---|
node | 20, 22, 24 | 22 |
python | 3.11, 3.12, 3.13 | 3.12 |
php | 8.2, 8.3, 8.4 | 8.3 |
Examples: "node:24", "python:3.13", "php:8.4". An unsupported version is rejected with the list
of supported ones.
Asking for one
deploy it on Python 3.13
Most of the time you don't need to. The defaults are current, and a project that runs locally on a nearby version almost always runs on the default.
Pin explicitly when a dependency requires it — a package with no wheels for 3.13 yet, a syntax feature that needs Node 22+, a framework that hasn't caught up.
Changing it later
The version is part of the runtime, and the runtime can change on a deploy:
redeploy that on node 24
The address, access list and environment variables all survive it. If the new version breaks the build, deploy again on the old one — nothing else about the app has changed.
What a version actually pins
The base image your app is built on: node:22-slim, python:3.12-slim, php:8.3-apache. Patch
releases within a version move as those images are rebuilt, so you get security updates without
pinning yourself to a broken point release. If you need an exact image, bring your own
Dockerfile.
PHP
Served from your project root with index.php as the front controller; composer.json is optional.
Environment variables
Settings and secrets your app reads at run time. You set them yourself in a browser at /secrets-manager, so a secret never passes through your agent — which can only ever see their names.