Atomic Runtime versions

Four of the six languages run inside your slice as an interpreter, and these are the versions they run at. They are the same for every slice on the platform, and you do not choose them per function.

Go and Rust are not on that list

They are compiled before they ever reach the slice. The CLI builds your source into a binary, ships the binary, and the slice executes it directly, so there is no Go or Rust installed in the slice to have a version. What matters for those two is the toolchain that did the build, not anything running alongside your function.

That is also why a Go or Rust function starts faster than an interpreted one: there is no interpreter to boot.

You cannot pin a version

There is no per-function or per-slice setting for this. The versions come from the slice image, which is built once and runs every tenant, and they move only when the platform ships a new one.

This is deliberate. One image for every slice is what keeps a free slice at a few tens of megabytes of memory, and a per-tenant interpreter version would mean a per-tenant image.

Checking it yourself

The version your function sees is the version above, and you can confirm it from inside a handler rather than taking our word for it:

// @atomic http=get:runtime auth=none
exports.getRuntime = async () => ({ node: process.version });

The equivalent is sys.version in Python, RUBY_VERSION in Ruby, and PHP_VERSION in PHP.

When these change

A version moves when the slice image is rebuilt, which happens for security patches and for ordinary maintenance. Interpreted languages move within a release line where possible, so a patch bump is the common case and your code keeps working.

A change that would move a major version is the kind of thing worth announcing, because that is where a language can break your handler. Nothing on this page is a guarantee of a specific version forever.