Composer Platform Constraints for Real Servers

Composer resolves packages for the PHP version it believes you have. If developers run PHP 8.3 locally while production FPM is 7.4, an unconstrained resolve can lock packages that never install on the server. Platform configuration exists to make that mismatch visible and intentional.

# Resolves for the developer's newer PHP; production install fails later
composer update
composer install --ignore-platform-reqs

{
  "require": {
    "php": "^8.1",
    "ext-json": "*",
    "ext-pdo": "*",
    "ext-mbstring": "*"
  },
  "config": {
    "platform": {
      "php": "8.1.32"
    }
  }
}

require.php vs config.platform

require.php is the application’s stated supported runtime range. config.platform.php forces Composer to resolve as if that exact PHP version is present—useful so CI and laptops mimic production. Raise both when you deliberately move the runtime ladder; do not leave platform pinned to 7.4 after production is on 8.2.

Extensions are platform too

Legacy apps often need ext-gd, ext-intl, or ext-soap. Declare them so missing modules fail at install time instead of at the first request. Compare environments with PHP Environment Compare and check resolves with Composer Platform Requirement Checker.

Constraint syntax help: Version Constraint Explainer. Official docs: Composer platform config.