MEET YOUR AI CLOUDInference & custom models. Now on Qoddi.
Qoddi
QODDI BLOG

PHP build security update: why existing builds may fail

·Qoddi· 4 min read
Productbuildpacks
PHP build security update: why existing builds may fail

Qoddi has tightened its PHP build security policy. PHP builds now require the patched buildpack and the newer builder image. Applications that built successfully with a legacy configuration may fail their next build until their runtime requirements or buildpack combinations are updated.

This change applies even when legacy is selected in the app’s build settings. Selecting legacy no longer restores the previous PHP build environment.

What changed

  • The newer PHP buildpack and builder image are mandatory. PHP always uses the updated environment, and fallback to the legacy PHP buildpack is disabled.
  • PHP versions are checked before the build can proceed. PHP 8.1 and earlier are rejected. Older patch releases of newer PHP branches are also rejected; selecting PHP 8.2 or later alone does not guarantee that a particular patch is accepted.
  • Some buildpack combinations are blocked. PHP combined with Apt, FFmpeg, static, or certain other buildpacks is rejected. These are examples, not a complete compatibility list.
  • PHP with Node also upgrades the Node buildpack. Mixed applications use the newer Node buildpack, which can affect older asset pipelines, dependencies, and build scripts.

Understanding the build log

A PHP build using the updated profile can show:

Default PHP Apache Procfile added.
PHP security policy: patched buildpack required; legacy fallback disabled.
Buildpack profile: updated; buildpacks: heroku/[email protected], heroku/[email protected]

The first line reports that a default Apache Procfile was added. The second confirms that the security policy is active. The third identifies the selected buildpack profile. 1.6.11 and 4.2.4 are buildpack versions, not PHP runtime versions.

These lines describe build setup; they do not identify the precise reason a build failed. Read the failure message in the complete build log to distinguish a rejected PHP version, an unsupported buildpack combination, or an application dependency or build error.

Getting your app building again

  1. Check the PHP version requested by your application. Review require.php in composer.json and any constraints that prevent a supported patch from being selected. Upgrade applications requiring PHP 8.1 or earlier. For newer branches, use a patched release accepted by Qoddi’s current policy and available in the builder. The upstream runtime inventory is not Qoddi’s minimum-patch policy; ask support if the rejection does not identify an accepted version.
  2. Update and test your Composer dependencies. After changing requirements, resolve dependencies locally, review the resulting changes, and commit both composer.json and composer.lock. See Composer’s dependency update guidance.
  3. Review the complete buildpack list. If PHP is combined with Apt, FFmpeg, static, or another rejected buildpack, that configuration must change. Remove an extra buildpack only if the app does not need it. If it supplies required dependencies, contact Qoddi support to review a supported deployment configuration.
  4. Test Node builds in mixed applications. Review your Node runtime requirement, package-manager lockfile, and asset build scripts against the newer buildpack. Follow the Node.js deployment guide and check the Node stage of the build log as well as the PHP stage.
  5. Make your startup configuration explicit. The default Apache Procfile message does not confirm that the document root matches your framework. For an Apache app whose public files are in public/, commit a root-level Procfile containing:
web: heroku-php-apache2 public/

Adapt the document root to your application. See the PHP Procfile guide and Heroku’s document-root configuration.

If the build still fails

Switching to legacy will not bypass these requirements. Keep the complete build log, the selected buildpack list, and the PHP and Node version constraints available when you contact support. Include the actual rejection or error message along with the profile lines above so we can identify the failing stage.

See the PHP security policy notice for the deployment requirements alongside the PHP configuration guide.