PHP and MySQL
Which PHP version should you use in production?
Choose a supported PHP branch from application compatibility and security support, then test migration before switching production.
By AppLaunch Editorial · Reviewed 2026-08-25
Direct answer
Use a currently supported PHP branch that your framework, CMS and extensions explicitly support. Newer releases may improve language and runtime behaviour, but production migration should pass the application test suite and deprecation review before the old runtime is removed.
What this means in plain English
Use a PHP version that still receives security fixes and is supported by your application. “The page opens” is not enough: the framework, installed packages and PHP extensions must all support that version.
A newer version can bring improvements, but test it away from the live site first. Include command-line jobs and background workers as well as normal web pages, because they may use a different PHP installation.
Newest PHP or safest compatible PHP?
| Support | Branch still receives security fixes |
|---|---|
| Compatibility | Framework, packages and extensions support it |
| Proof | Tests and representative traffic on the new runtime |
A simple example
A site runs PHP 8.2 and its framework supports 8.4. The team tests 8.4 on staging, updates one incompatible package and checks forms, uploads, scheduled jobs and payments. Only then do they switch production while keeping an 8.2 rollback path.
What to do, step by step
1. Check the current PHP support table.
Start here before buying anything or changing several settings at once. It gives you a clear starting point based on support: branch still receives security fixes. Write the result down so you can compare it later.
2. Audit Composer platform requirements and native extensions.
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 with deprecations visible.
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. Switch with a rollback window.
Finish by checking the result against proof: tests and representative traffic on the new runtime. Keep the old setting or release available until you know the change works and can be reversed safely.
One more useful tip
Check the official PHP supported-versions page regularly. A version can continue running after support ends, but newly discovered security problems may no longer receive fixes.
Common mistakes and how to avoid them
Staying on end-of-life PHP because the site loads.
This gives a misleading or unsafe result because it leaves out support. A better approach is to check the current php support table, then check the result before making the change permanent.
Ignoring CLI and worker runtimes.
This gives a misleading or unsafe result because it leaves out compatibility. A better approach is to audit composer platform requirements and native extensions, then check the result before making the change permanent.
Changing PHP and application dependencies together.
This gives a misleading or unsafe result because it leaves out proof. A better approach is to run tests with deprecations visible, 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.
- worker
- A running process that handles one job or request at a time. More workers allow more work at once but also use more memory.
- migration
- A planned change to database structure or stored data when a new application version is released.
Quick checklist
- Check the current PHP support table.
- Audit Composer platform requirements and native extensions.
- Run tests with deprecations visible.
- Switch with a rollback window.
Common questions
What is the simple answer?
Use a currently supported PHP branch that your framework, CMS and extensions explicitly support. Newer releases may improve language and runtime behaviour, but production migration should pass the application test suite and deprecation review before the old runtime is removed.
What should I check first?
Start with support: branch still receives security fixes. That is usually more useful than choosing from a marketing label or copying somebody else’s setting.
How can I make the change safely?
Check the current PHP support table. 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?
Staying on end-of-life PHP because the site loads. Avoiding that one mistake makes the rest of the comparison much more trustworthy.