Deployment is the transition from reviewed source to the runtime that serves users. A PHP application needs more than copied .php files: compatible extensions, installed locked dependencies, protected secrets, web routing, database schema, logs, and writable storage must agree. This reference explains a production release workflow and its failure points. It does not deploy anything. You will prepare a reviewable release plan, separate migration privileges from runtime permissions, and verify the effective web environment. A successful file transfer is only one step; the release is usable when the application starts correctly and its required behavior works under production configuration.
Build a reproducible release artifact
Start from a known source revision and committed application lockfile. Install production dependencies under the project's policy, commonly excluding development tools and generating appropriate autoload metadata. Avoid resolving a new dependency set during deployment. The artifact should contain code, templates, static assets, and required generated files, while excluding secrets, local databases, and temporary diagnostics. Verify PHP syntax and relevant behavior checks before packaging. Record the revision and dependency selection so a failure can be traced. Use the same artifact across staging and production where practical, injecting environment-specific configuration separately. An artifact that changes between testing and release weakens the evidence from staging.
Verify runtime compatibility before traffic
Check the actual web runtime's PHP version and required extensions, not only the CLI used by a deployment script. Compare resource limits, timezone policy, session storage, and database drivers with the application's requirements. A host can use a different php.ini for the serving process. Use protected readiness checks that confirm useful dependencies without exposing phpinfo or credentials. A compatible PHP version does not guarantee the correct web root or routing. Configure the public document root so private source, vendor details where inappropriate, .env, backups, and upload storage cannot be downloaded. Test direct access to sensitive paths under the deployment's real routing rules.
Inject secrets and restrict permissions
Provide database and service secrets through the hosting secret mechanism or another protected runtime source. Keep them out of the release archive, source history, logs, and browser code. The runtime account should have only necessary database privileges; migration tooling uses a separate controlled role. Writable directories need access for the service account, while source code should not be writable by ordinary requests unless the product deliberately requires it. A blanket 0777 permission change is not a deployment policy. Uploaded files and sessions need private storage appropriate to the host's persistence model. Container-local files may disappear when an instance is replaced, so select persistent storage deliberately.
Coordinate schema and code changes
A release can fail when new code expects a column that does not exist, or old code cannot handle a new schema during rollout. Use compatible staged migrations when multiple versions may run briefly together. Add fields and support them before removing old ones. Backfill data through a bounded, observable process and verify results. MySQL DDL can commit implicitly and may lock or rebuild large tables, so assess the operational effect rather than assuming a PHP transaction makes it reversible. Record migration versions and run each controlled change against the intended environment. A destructive migration needs a tested recovery plan, and code rollback may not automatically reverse the schema safely.
Set production response and logging behavior
Disable public display of diagnostic details at startup and enable a protected logging path or platform collector. Validate a simulated failure in staging so you know operators can find it while users receive a safe message. Configure HTTPS-related cookie and session behavior under the application's authentication model. Choose timeouts and body limits across proxy, web server, and PHP layers so requests fail predictably. Keep cache headers appropriate for private and public responses. OPcache invalidation or runtime restart must match the release method, especially when timestamp validation is disabled. Long-running queue workers may need replacement so they load new code and configuration.
Verify and preserve a rollback path
After activating the artifact, check a small set of meaningful operations: read a public page, authenticate under a test account, perform a controlled write where permitted, and confirm logs and background processing. Do not use production users' data casually for smoke tests. Monitor errors, latency, and dependency failures during rollout. Keep the previous artifact and a documented way to reactivate it, including runtime cache refresh. Understand which schema changes remain compatible with rollback. A rollback is not simply copying old code if data formats or migrations changed. Record the final deployment revision and state so the next operator knows what is actually running. This closes the gap between 'uploaded' and 'verified available'.
Practice task and worked solution
Prepare a release plan for a PHP shop adding a category field. The solution identifies the reviewed source revision, locked production dependencies, required extensions, private configuration, and a staged compatible schema change. Specify how migrations run with a separate role and how workers and OPcache refresh. Define readiness checks and a small staging smoke test using controlled data. Keep the prior artifact and state which schema changes remain compatible with code rollback. Verify production logs hide secrets and public diagnostics are disabled. Do not perform actual deployment or destructive schema work as part of this exercise; make the plan concrete enough that an operator can review it.
Continue learning
Review Composer, security, and exceptions.
The PHP configuration guide describes runtime settings, while Composer's install documentation explains lockfile-based installation.
Deployment and Production Configuration Examples
Each example shows the code, the output it produces and what each part does.
A release readiness description
This PHP CLI example checks a few runtime prerequisites without contacting services, reading secrets, or deploying. Add project-specific checks through controlled tooling.
The PHP version and missing-extension list depend on the CLI installation. This does not prove the serving web runtime has the same modules or that external services are reachable.
<?php
$required = ['pdo', 'pdo_mysql', 'fileinfo'];
$missing = array_values(array_filter(
$required,
fn(string $extension): bool => !extension_loaded($extension)
));
echo 'PHP: ' . PHP_VERSION . PHP_EOL;
echo $missing === [] ? 'Required extensions available' : 'Missing: ' . implode(', ', $missing);
echo PHP_EOL;
echo 'Deployment action: none';Environment-dependent PHP version and extension report
Deployment action: noneDeployment and Production Configuration FAQ
Is copying PHP files enough?
No. Dependencies, runtime configuration, storage, and schema must also agree: the server needs the same Composer packages, the right PHP version and extensions, writable storage folders, environment settings and any database migrations the new code expects.
Should production run composer update?
No. Install the reviewed lockfile under the project policy, usually composer install --no-dev --optimize-autoloader. Updating on the server could install versions nobody has tested.
Does code rollback undo migrations?
Not automatically. Deploying the previous code leaves the database in its new shape. Write migrations that the old code can live with where possible, such as adding columns before removing old ones, and keep a tested down-migration or backup plan for risky changes.
Does a CLI check prove web readiness?
No. The command line can use a different PHP version, configuration and user than PHP-FPM, so the serving runtime must be verified separately, for example with a health-check URL that tests the database connection and required extensions.
Deployment and Production Configuration Exercises
Answer each one and check it instantly. If you get stuck, open the hint before the answer.
CLI has pdo_mysql but the website fails with a missing driver. What must be checked?
Deployment and Production Configuration Quiz
2 questions to check what you learned.
What should remain separate from a release archive?
- Reviewed application code
- Required static assets
- Environment-specific secrets
- Version information
What makes a rollback plan reliable?
- Assuming every DDL change rolls back
- Deleting all logs
- Only a screenshot
- A retained artifact and understood schema compatibility