Existing issue
Problem or use case
Generated PHP deployments currently use a fixed PHP 8.4 pair. On main at 4fefe21, packages/core/src/stacks.ts sets php:8.4-cli for builds and dunglas/frankenphp:1-php8.4-bookworm for runtime. In build.service.ts, buildConfigSnapshot accepts the project's buildImage, but resolveRuntimeImage still resolves from the stack.
Changing the build image alone therefore does not select the PHP version used in production. Applications with different PHP requirements need a supported version setting without maintaining a custom Dockerfile.
Proposed solution
Add an explicit project-level PHP version selection for Openship-generated Docker builds, exposed through the existing configuration surfaces.
First-PR scope:
- Resolve a tested build/runtime image pair from the selected PHP major/minor version. Keep the existing FrankenPHP runtime.
- Keep the current PHP 8.4 behavior when no version is selected; existing projects must not silently change versions.
- Reject unsupported versions and incompatible Composer platform requirements before activation. Do not bypass platform checks or silently fall back to another PHP version.
- Define precedence for custom build-image overrides and reject incompatible combinations; leave user-owned Dockerfiles unchanged.
- Save the selected version and resolved image references in the deployment snapshot. Rollback must restore the original built application image, not recalculate from the project's latest PHP setting.
- Preserve Openship Edge routing, TLS and traffic analytics, and existing container resource monitoring.
- Clearly reject an explicit selection on any deployment path that cannot honor it, rather than silently ignoring it.
Acceptance checks: unchanged behavior for existing projects; matching PHP versions in build and runtime for at least two supported selections; useful failure for incompatible Composer requirements; deployment and rollback smoke tests; and existing routing/monitoring still working after a version change.
Out of scope: Server Side Up presets, changing the web server, automatically enabling Octane, worker/scheduler roles, release commands, and unrelated monitoring changes.
Alternatives considered
A custom Dockerfile already provides control, but requires maintaining a deployment recipe for a version-only change. A build-image override alone does not change the generated runtime image.
Additional context
Related: #231 and #935. This is the separate PHP-version contribution I mentioned in #935 (comment); it does not take over the runtime-role implementation.
I can implement this first PR with regression and deployment tests once the scope and configuration approach are agreed.
@Hydralerne, is this scope acceptable, and where would you prefer the version setting to live in the existing project/openship.json configuration model?
Existing issue
Problem or use case
Generated PHP deployments currently use a fixed PHP 8.4 pair. On main at 4fefe21, packages/core/src/stacks.ts sets php:8.4-cli for builds and dunglas/frankenphp:1-php8.4-bookworm for runtime. In build.service.ts, buildConfigSnapshot accepts the project's buildImage, but resolveRuntimeImage still resolves from the stack.
Changing the build image alone therefore does not select the PHP version used in production. Applications with different PHP requirements need a supported version setting without maintaining a custom Dockerfile.
Proposed solution
Add an explicit project-level PHP version selection for Openship-generated Docker builds, exposed through the existing configuration surfaces.
First-PR scope:
Acceptance checks: unchanged behavior for existing projects; matching PHP versions in build and runtime for at least two supported selections; useful failure for incompatible Composer requirements; deployment and rollback smoke tests; and existing routing/monitoring still working after a version change.
Out of scope: Server Side Up presets, changing the web server, automatically enabling Octane, worker/scheduler roles, release commands, and unrelated monitoring changes.
Alternatives considered
A custom Dockerfile already provides control, but requires maintaining a deployment recipe for a version-only change. A build-image override alone does not change the generated runtime image.
Additional context
Related: #231 and #935. This is the separate PHP-version contribution I mentioned in #935 (comment); it does not take over the runtime-role implementation.
I can implement this first PR with regression and deployment tests once the scope and configuration approach are agreed.
@Hydralerne, is this scope acceptable, and where would you prefer the version setting to live in the existing project/openship.json configuration model?