The Production Readiness Checklist Every PHP Project Should Have

A deployment can be technically successful and operationally
incomplete.

The ZIP extracted. The database migration returned without error. The
home page loads.

Then someone discovers that debug mode is enabled, scheduled work is
not running, outbound mail still points at a sandbox, or the backup
created before deployment is unreadable.

A production checklist exists to make these assumptions explicit
before users discover them for you.

1. Runtime

Record the actual production runtime, not what the development
machine uses.

Check:

• PHP version;
• required extensions;
• memory limit;
• timezone;
• error reporting/display behavior;
• OPcache state where relevant;
• upload/post limits if the application accepts uploads.

A useful report distinguishes required, recommended and informational
values.

Do not call a newer PHP version “healthy” if the application has not
declared support for it.

2. Debug and error exposure

Production should not reveal internal errors to visitors.

Check framework/application debug flags and PHP display settings.

Logs should still capture actionable failures, but they should be
bounded and protected from public download.

Questions:

• Is debug mode off?
• Is display_errors appropriate for production?
• Are log files outside public access or denied by the web
  server?
• Can logs grow without bound?

3. Filesystem

Verify the exact paths the application expects to write.

Examples:

• upload directory;
• cache directory;
• generated data;
• temporary directory;
• backup destination.

Check existence, ownership, writability and free space.

Avoid broad chmod 777 fixes. Correct ownership and
least-required permissions are safer.

4. Database

Confirm:

• production database is the intended database;
• migrations/upgrades completed;
• expected core tables exist;
• engine/charset are appropriate;
• no obvious schema drift remains;
• storage headroom is reasonable;
• backup was taken before risky migration.

A read-only schema report is useful immediately after deployment
because it records what production actually received.

5. Scheduled work

Background tasks are easy to forget during migration.

Check:

• scheduler enabled state;
• external system cron if required;
• expected recurring entries;
• overdue work;
• queue backlog;
• callback/worker availability.

If a scheduler is deliberately disabled because another mechanism
replaces it, document the replacement.

6. Email

Configuration is not enough. Send a deliberate test.

Record:

• transport type;
• sender domain/address;
• authentication outcome where observable;
• whether the transport accepted the test;
• whether the intended mailbox received it.

Do not expose SMTP passwords in diagnostics or support exports.

7. DNS and TLS

Verify the production hostname from outside the server’s local
assumptions.

Check:

• DNS resolves to expected infrastructure;
• HTTPS certificate is valid for the hostname;
• canonical HTTP -> HTTPS behavior;
• www/non-www policy;
• redirect hop count;
• no unexpected downgrade to HTTP.

If a CDN is present, test both cached and dynamic paths.

8. Authentication and admin
access

Confirm administrators can sign in after the deployment, but avoid
leaving temporary accounts behind.

Review:

• emergency admin account policy;
• default credentials removed;
• MFA requirements if used;
• password reset email path;
• admin route protections.

Do not lock down access before verifying the recovery path.

9. Secrets and environment
separation

A staging-to-production copy can bring the wrong credentials.

Review:

• API keys;
• payment mode;
• webhook endpoints;
• SMTP destination;
• analytics IDs;
• object storage buckets;
• database credentials;
• error-reporting project/environment.

The dangerous state is often not a missing key. It is a valid staging
key in production.

10. Search visibility and
robots policy

For public sites, verify that production is intended to be
indexable.

For private/internal systems, verify the opposite.

Do not rely only on robots.txt for access control.
Search directives are not authentication.

WordPress migrations commonly carry a “discourage search engines”
setting from staging. That should be an explicit launch check.

11. Redirects and canonical
URLs

Trace representative routes:

http -> https
www -> canonical host
old important URL -> new URL
login/admin route

Remove accidental chains and loops.

Check application base URL configuration so generated links match the
public host.

12. Backups and rollback

“Backup completed” is not enough.

Verify:

• expected file exists;
• compression/container is readable;
• size is plausible compared with recent backups;
• database dump contains expected structure;
• restore procedure is documented;
• deployment rollback artifact is available.

For important releases, record exactly which database state
corresponds to which application version.

13. Release integrity

Keep a fingerprint of the artifact you shipped.

For example:

sha256sum release-v1.4.0.zip

Publish or retain that digest.

If deployment behavior differs between servers, verify they started
from the same package before debugging application logic.

For applications with file manifests, compare installed files against
expected hashes.

14. Observability

Before launch, decide how failure will be noticed.

At minimum:

• HTTP availability;
• server/application errors;
• scheduled-task health;
• disk/storage alerts;
• backup age;
• queue backlog where relevant.

Monitoring only the home page leaves too much invisible.

15. Performance
sanity, not benchmark theater

You do not need a synthetic score of 100.

You do need to catch obvious regressions.

Record a few real production observations:

• uncached dynamic response time;
• cached response time;
• database slow-query indicators;
• largest core assets;
• page weight on a representative route.

Compare future releases against the same baseline.

16. Security headers and
public files

Check whether the application exposes files that should remain
private:

• debug logs;
• backups;
• environment files;
• source maps if sensitive;
• installation leftovers.

Review appropriate security headers for the application rather than
copying a random maximal header set that may break required
functionality.

17. Application-specific
workflows

Finally, test the actual reason the site exists.

For WordPress:

• publish/update content;
• upload media;
• send password reset;
• run scheduled tasks.

For XenForo:

• log in;
• create/read a thread in the intended test area;
• verify mail/cron paths;
• check add-on health.

For commerce:

• verify payment mode and a safe end-to-end transaction path.

Turn the checklist into
evidence

A checklist is stronger when each item produces an observable
result.

Instead of:

[ ] Database okay

prefer:

[✓] DB connection successful
[✓] expected core tables present
[✓] charset matches policy
[!] largest log table 18 GB — reviewed

This makes future comparisons possible.

Production readiness is
not one score

A single percentage can be attractive, but it compresses very
different risks into one number.

A disabled debug flag and a missing backup are not interchangeable
“10 point deductions.”

Use categories, evidence and explicit blockers.

The goal is not to make a dashboard green.

The goal is to know what assumptions you have actually verified
before the release starts carrying real traffic.