Run Django's deployment checks before a release

Django's deployment checks can catch a release that still uses development-oriented settings. Run them with the same settings module and environment that the deployed process will read. A clean local development check says little about a different production configuration.

Check the intended settings

The command below names an illustrative settings module. Replace it with the project's real module and supply configuration through its normal environment mechanism. Do not paste secrets into command history to make the check pass.

python manage.py check --deploy --settings=config.production

Run this before releasing the application, then save the warning identifiers and the settings source used. Django's deployment checklist explicitly says to target production settings. The command is a configuration review aid; it does not exercise a browser login, a reverse proxy or a running mail service.

Static deployment findings are reviewed before request-level staging checks; neither step alone certifies a deployment.

Resolve a warning in context

Suppose a disposable settings file leaves DEBUG=True and does not require secure session cookies. Treat the resulting findings independently. Turn debugging off in the deployment environment and inspect an error response to confirm that stack traces are absent. For secure cookies, test through the intended HTTPS origin and verify that the browser receives the expected cookie attributes.

The example command was not run against an invented config.production module during authoring. That module is a placeholder, not a claim that a particular deployment passed. A project can put the check in its release script after configuration loading, provided failures remain visible and do not print environment values.

Verify what static checks cannot see

A reverse proxy can terminate TLS while the application sees an internal HTTP connection. Review how the framework identifies secure requests, and trust forwarded headers only from the expected proxy path. Then exercise the live request behavior in an authorized staging environment. A setting with the right name can still describe the wrong network boundary.

Keep a small release record with the application revision, Python and Django versions, and remaining findings. If a warning is deliberately accepted, explain the actual compensating behavior and who owns it. Avoid suppressing a warning only to make a build green.

After the configuration check, test representative public pages, an authenticated mutation and a rejected unauthorized mutation. Check static and media responses separately from application pages. These observations complement the command without converting its output into a security certification.

Reference: Django 5.2 deployment checklist. The engineering blog includes related deployment examples.