Skip to content

Installing Composer dependencies from a lock file

development

An application’s Composer lock file records the dependency versions selected for its release. Production installation should reproduce that reviewed set rather than choose a new set during deployment.

Check access and requirements

Confirm the application directory, compatible PHP executable and Composer version. Identify any private package credentials and approved Composer plugins or scripts.

01 Install Composer dependencies from a lock file

  1. Commit composer.json and the reviewed composer.lock for the application. Resolve inconsistent metadata in development before deployment.

  2. Install the release in a separate directory with the intended PHP runtime. Use composer install and the production options appropriate to the project, such as omitting development packages.

  3. Allow only the plugins and scripts required by the trusted project. Treat dependency installation as code execution, not as a passive file download.

  4. Check platform requirements against the real target runtime and required extensions. Keep the resulting vendor directory and autoloader with the matching application release.

  5. Build any application caches or assets required after dependency installation and run a representative startup check.

02 Example: reproduce a Composer release in a new directory

Use a new private release directory containing the reviewed application and lock file. Choose the correct PHP runtime first. These commands inspect metadata, install the selected production packages, and compare their requirements with the real target environment.

Code or configuration example
composer validate --strict
composer install --no-dev --prefer-dist --optimize-autoloader --no-interaction
composer check-platform-reqs --no-dev

Stop if the lock and package metadata disagree. Installation can execute the project’s trusted scripts and approved plugins, so review that part of the release too. Omitting development packages is appropriate only after required build tools have produced their artifacts. Do not add an ignore-platform option to conceal a missing extension.

Expected result: The installed versions match the reviewed lock and the startup check succeeds under the intended PHP handler. Keep the generated vendor directory with this release rather than mixing it with files from a different build.

Confirm the expected result

Confirm the install used the expected locked versions and the application can load its dependencies. Review whether the lock file changed unexpectedly during the build.

Resolve setup problems

If a required PHP version or extension is missing, select a compatible runtime or correct the dependency plan. Ignoring platform requirements does not make the resulting code compatible.

A common question

Should I run composer update on the live server?

Make dependency updates as reviewed development changes, test them and commit the new lock. Routine deployment should install that chosen release rather than introduce untested upgrades.

Sources and further reading

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support