The Django Production Launch Checklist

Launch day problems are rarely exotic. They are a setting left at its development value, a backup
that was never restored, or an email nobody tested. This is the list worth walking before real users
arrive.

Settings

• DEBUG = False. Verify it in production rather than trusting the file — an environment variable
  may be overriding it. Request a broken URL and confirm you get a plain error page, not a traceback.
• ALLOWED_HOSTS lists every hostname you serve, with no wildcard.
• SECRET_KEY comes from the environment, is unique to production, and has never been committed.
• Database credentials, API keys and mail credentials all come from the environment.
• Time zone and language are set deliberately rather than left at their defaults.

Security headers

• HTTPS enforced, with HTTP redirecting once rather than through a chain.
• SECURE_SSL_REDIRECT, SESSION_COOKIE_SECURE and CSRF_COOKIE_SECURE enabled.
• SECURE_HSTS_SECONDS set — start modest, raise once every subdomain is confirmed on HTTPS.
• X_FRAME_OPTIONS set, and a content security policy if you can manage one.
• The admin is not on the default path, or is restricted by network.

The database

• Migrations applied, and showmigrations shows nothing outstanding.
• Indexes on the fields you filter and order by. Check the queries your slowest page makes.
• Connection limits understood: workers times processes must fit inside what the database allows.
• A superuser exists with a password nobody else has ever seen.

Backups

• A backup runs automatically, on a schedule.
• The dump has been restored somewhere at least once, and the application ran against it.
• Media files are included — they are not in the database.
• One copy exists somewhere other than the server, and preferably other than the provider.

If you check only one item on this entire list, make it the restore. An untested backup is a hope.

Static and media

• collectstatic runs as part of deployment.
• Static files return 200 in production, not 404.
• Uploaded media survives a deployment — it lives in a volume or object storage, not inside the
  application directory.

Email

• A real message has been sent from production and arrived.
• Authentication records are published and align with your sending domain.
• The from address is a mailbox somebody reads.
• Errors reach you: an unhandled exception should notify a human.

Outbound mail is blocked by default on many servers. A site that renders perfectly while sending
nothing looks entirely healthy from the outside, which is why this is worth testing explicitly.

Operations

• Logs go somewhere durable and are rotated.
• You know how to see the last hour of errors without guessing.
• Certificate renewal has been dry-run, and expiry is monitored externally.
• Something alerts you when the site is down. Ideally not a customer.

Rollback

• You can put the previous version back, and you know how long it takes because you have done it.
• The database change you are deploying is reversible, or you have accepted that it is not.

The final pass

Open the site in a private window on a phone. Register an account. Receive the confirmation email.
Log in. Perform the main action your product exists for. Log out.

Five minutes, and it catches the things no checklist can: the button that does not fit on a small
screen, the email that arrives without styling, the flow that made sense in your head.

For the infrastructure underneath, see Backups and Disaster Recovery for
Django and Firewall and SSH Hardening for Django
Servers.