Runtime versions

Primcloud installs the Python version your project asks for, resolved from a .python-version file at the root of your repo. If you don't ask for anything, you get the latest patch of Python 3.14.

Supported versions#

The Python versions you can install are part of the Primcloud Runtime and move as the Runtime is updated. The build log for each deployment, in the Deployments tab, shows the version that build installed. Treat the table below as an illustrative snapshot rather than a fixed contract:

Each major installs its latest available patch, which lands as CPython ships it. Only CPython runs on Primcloud; PyPy, Jython, and the other alternative implementations do not.

Support windows track Python's own support policy. When a major reaches upstream end-of-life, the Runtime keeps building against it through a short deprecation window, then drops it. Your build log names the exact removal date for anything you've pinned.

Pinning a version#

Drop a .python-version file at the repo root with the major version you want:

3.14

Primcloud resolves that to the latest patch it ships in that major. Pin the major and let the patch float. That's the shape we recommend, because every rebuild then picks up upstream security patches on its own.

You can pin an exact patch when you need to:

3.13.14

We don't recommend it: an exact pin freezes your app on that patch until you bump the file by hand, so security fixes wait on you.

Format rules. One version per file. No quotes, no python- prefix, no wildcards. Comment lines are fine as long as they start with #.

uv requires .python-version. For uv projects the file is mandatory. Leave it out and the build fails with a "no Python version was specified" error. Run uv python pin 3.14 locally to create it, then commit the result.

runtime.txt no longer works. Primcloud reads the Python version from .python-version, not the older runtime.txt. If your repo still carries a runtime.txt, the build fails with a "runtime.txt file isn't supported" error. Delete it and add .python-version with the same major version.

Upgrading#

Bump the pin and redeploy:

• Edit .python-version (3.13 → 3.14, say).
• Commit and push.

The next build downloads the newer Python, caches it, and rebuilds the venv against it. Every dependency layer invalidates when the Python version changes, so the first build after a major jump runs longer, then speed returns on the next deploy.

Read Python's What's New before jumping majors. Primcloud won't stop you from installing a version that then fails to import your code.

When a version drops out of support#

When a major reaches end-of-life on Python's schedule, Primcloud walks it through two stages:

• Deprecation warning. Builds still succeed, and the build log shows a warning naming the removal date.
• Removal. After the deprecation window, the version is gone. A build pinned to it fails with "the requested Python version has reached end-of-life."

To avoid a forced upgrade under time pressure:

• Watch your build log for the deprecation warning and its removal date.
• Bump .python-version to a supported major before that date.
• Run your test suite against the new major locally before you deploy.

Python 3.10 is in that deprecation window now. Check your build log for the date it drops.