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. Pinning to an exact patch image isn't supported —
agenthost builds from these images and tracks their updates.