PHP and MySQL
Composer install for a production PHP deployment
Build repeatable PHP dependencies from a committed lockfile without development packages or changes on the live server.
By AppLaunch Editorial · Reviewed 2026-08-25
Direct answer
Commit composer.lock for applications and install those exact dependency versions during a build or release step. Exclude development packages, prepare autoloading for production where appropriate, and never run an unrestricted composer update on the live server.
What this means in plain English
composer.lock records the exact package versions chosen for a PHP application. composer install follows that file; composer update chooses new versions. Production deployment should reproduce a reviewed lockfile rather than make new dependency decisions on the live server.
Build dependencies in a clean environment, exclude development-only tools where appropriate, run tests and deploy the resulting release together. Check required PHP extensions as well as package versions.
What should production install from?
| Input | Reviewed composer.json and committed lockfile |
|---|---|
| Command intent | install repeats known versions; update chooses new versions |
| Result | Tested vendor folder tied to the release |
A simple example
The developer reviews and commits a dependency update in composer.lock. CI runs composer install, tests the app and packages the release. Production receives that tested package instead of running composer update and discovering a new incompatible library during deployment.
What to do, step by step
1. Validate Composer files in automated checks.
Start here before buying anything or changing several settings at once. It gives you a clear starting point based on input: reviewed composer.json and committed lockfile. Write the result down so you can compare it later.
2. Install with production flags in a clean environment.
Use the same files, versions and settings that the real project will use. A quick test with an empty or different setup can look successful while completely missing the problem you are trying to solve.
3. Run tests and a vulnerability review.
Try the busiest realistic situation, not the easiest one. Include the people, data, traffic or background work you genuinely expect, then watch for slowdowns and errors rather than relying on a single headline number.
4. Deploy the tested release without changing its files.
Finish by checking the result against result: tested vendor folder tied to the release. Keep the old setting or release available until you know the change works and can be reversed safely.
One more useful tip
Keep credentials for private package sources out of composer files and build logs. Supply them through the protected build environment.
Common mistakes and how to avoid them
Running composer update during deploy.
This gives a misleading or unsafe result because it leaves out input. A better approach is to validate composer files in automated checks, then check the result before making the change permanent.
Sharing a vendor folder that different releases can change.
This gives a misleading or unsafe result because it leaves out command intent. A better approach is to install with production flags in a clean environment, then check the result before making the change permanent.
Ignoring required PHP extensions.
This gives a misleading or unsafe result because it leaves out result. A better approach is to run tests and a vulnerability review, then check the result before making the change permanent.
Words explained
- PHP
- The programming language that runs the server-side part of many websites and applications.
Quick checklist
- Validate Composer files in automated checks.
- Install with production flags in a clean environment.
- Run tests and a vulnerability review.
- Deploy the tested release without changing its files.
Common questions
What is the simple answer?
Commit composer.lock for applications and install those exact dependency versions during a build or release step. Exclude development packages, prepare autoloading for production where appropriate, and never run an unrestricted composer update on the live server.
What should I check first?
Start with input: reviewed composer.json and committed lockfile. That is usually more useful than choosing from a marketing label or copying somebody else’s setting.
How can I make the change safely?
Validate Composer files in automated checks. Then change one thing at a time, keep a backup or old version, and use the same real-world test after each change.
What is the easiest mistake to avoid?
Running composer update during deploy. Avoiding that one mistake makes the rest of the comparison much more trustworthy.