Runtime versions

Primcloud installs the PHP version your project asks for, resolved from the php requirement in your composer.json (and the platform requirements in composer.lock). If you don't ask for anything specific, you get the latest supported major.

Supported versions#

The PHP 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. The supported majors currently run from PHP 8.1 through 8.5, with 8.5 the latest. The table below is an illustrative snapshot, not a fixed contract:

Support tiers and end-of-life dates follow the official PHP release schedule. New patch releases become available as they ship upstream and the Primcloud Runtime is updated.

Pinning a version#

There's one mechanism: the php package requirement in your composer.json.

{
  "require": {
    "php": "^8.4"
  }
}

The version string uses standard Composer version constraints: carets, tildes, ranges, wildcards. Some common shapes:

• "^8.4": the latest 8.4.x patch, up to but not including 9.0.
• "~8.4.10": the latest 8.4.x patch at or above 8.4.10, up to but not including 8.5.
• "8.4.*": the latest 8.4.x patch.
• "8.4.15": exactly 8.4.15. Fails the build if that specific patch isn't in the inventory.

When you run composer update locally, Composer writes the resolved PHP requirement into composer.lock under platform. That's the value Primcloud reads at build time. The constraint in composer.json alone isn't enough if a lockfile exists.

No requirement specified. If neither composer.json nor composer.lock specifies a php requirement, Primcloud installs the latest supported major (currently PHP 8.5). This is fine for a throwaway app but not what you want for production. Pin the major explicitly so the version doesn't move underneath you when Primcloud picks up a new upstream release.

No runtime.txt. Unlike Python, PHP has no separate runtime file. The require."php" value in composer.json is the only place the version is set.

Upgrading#

Bump the constraint and redeploy:

1. Edit the php value in composer.json (say, "^8.3" → "^8.4").
2. Run composer update locally to refresh composer.lock against the new constraint.
3. Commit both files and push.

The next build resolves to the new version, installs it into a fresh layer, and reuses it from the cache on subsequent builds. If the upgrade crosses a major version boundary, expect one longer build while the runtime is downloaded, then normal speed from the next deploy.

Review the PHP migration guide for the target version before jumping majors. Primcloud won't stop you from installing a PHP version that produces deprecation warnings or fatal errors in your code.

When a version drops out of support#

When a major reaches end-of-life on the official PHP release schedule, the Primcloud Runtime eventually stops shipping new patches for it and may remove the version in a later update. Before that happens:

• Builds resolving to the EOL version keep working until the version is dropped from the inventory.
• Once dropped, builds whose composer.lock records the removed version fail with a "no matching PHP version" error. Run composer update locally against a supported version constraint, commit both composer.json and composer.lock, and redeploy.

Bump to a supported major before the EOL date to avoid a forced upgrade under time pressure.