A production deployment involves much more than uploading files. Here is a practical checklist for configuration, security, queues, storage, caching and monitoring.
A successful deploy is more than copying code to a server. The application needs the right runtime, safe configuration, durable data and a way to notice and recover from failure. This checklist is a conversation with the team before the first production release.
Prepare the environment
Confirm the supported PHP version and extensions, web server, database, TLS certificate and DNS. Keep secrets outside the repository and verify environment-specific values such as APP_URL, mail transport, storage and external API credentials. Disable debug output in production and give the runtime only the permissions it needs.
Deploy code and data deliberately
Build frontend assets and install locked dependencies as part of a repeatable release process. Run database migrations with awareness of table size and backwards compatibility. A migration that blocks writes on a busy table needs its own plan. Preserve uploaded files across releases and create the public storage link when required.
- Take a tested backup before risky schema changes.
- Know how to roll back code and how data changes will behave.
- Warm or rebuild configuration and route caches after environment changes.
- Verify file ownership and writable directories without broad permissions.
Run the work outside web requests
Queue workers need a supervisor, correct connection, restart on deployment and visibility into failures. The scheduler needs one reliable trigger and protection against unintended overlap where jobs require it. Without those processes, the site may load while emails, invoices or synchronisation silently stop.
Verify a real user journey
After release, check the health endpoint or landing page, authentication, a critical write, a queued task, storage, email and the main integration in a safe way. Monitor logs, error rates, latency and free disk space. Set an alert path someone will actually respond to.
Document the release steps and test them on staging. A calm deployment depends on repeatability and a recovery plan, not on remembering a long sequence of manual commands.
Plan a release that can coexist with the previous one
A production deploy is rarely instantaneous. Requests may still run on old code while new code starts, and workers may process jobs created before release. Database and message changes should tolerate this short overlap. For a risky feature, use a staged rollout or feature flag and confirm the rollback path before traffic reaches the new behaviour.
Backups need more than a successful job notification. Restore a copy in a safe environment and check that files, database records and application secrets required for recovery are available. A backup that cannot be restored is only a comforting log entry.
Security and observability are release work
Review HTTPS redirects, secure cookies, trusted proxies, rate limits for sensitive endpoints and access to administrative routes. Keep dependency versions and operating-system updates on a maintenance schedule. None of these replaces application-level authorisation, but each closes a different operational gap.
Decide what a useful alert looks like before an incident: failed payment callbacks, queue age, repeated 500 responses or disk space nearing its limit. Tie alerts to a person and a response procedure. Too many low-value alerts train the team to ignore the one that matters.
The last step is a short post-deploy review. Compare expected behaviour with live metrics and user reports, record any manual intervention and improve the checklist. A good process becomes more predictable after every release.
My deployment, performance and scaling service covers this production readiness work.