The Django Production Deployment Checklist: What manage.py check --deploy Misses

Why check --deploy misses it

check --deploy does not evaluate database driver socket health or cloud timeout lifecycles.

# settings.py (Django 4.1+)
DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.postgresql",
        # ...
        "CONN_MAX_AGE": 60,          # Reuse connection for up to 60 seconds
        "CONN_HEALTH_CHECKS": True,  # Test socket liveness before query execution
    }
}

Why check --deploy misses it

It cannot know your container replica count, Gunicorn worker/thread geometry, or PostgreSQL max_connections limit.

# settings.py (Django 5.1+ native pooling with psycopg 3)
DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.postgresql",
        # ...
        "OPTIONS": {
            "pool": {
                "min_size": 1,
                "max_size": 4,
                "timeout": 10,
            }
        },
    }
}
# Note: If using PgBouncer in transaction mode, set CONN_MAX_AGE = 0.

To diagnose query volume and growth before pooling issues arise, explore our guide to fixing Django N+1 queries in production.

Why check --deploy misses it

check --deploy may verify CSRF_COOKIE_SECURE, but does not parse CSRF_TRUSTED_ORIGINS schemas or inspect whether the reverse proxy forwards the proto header.

# settings.py
# Only enable if you control the proxy and it strips spoofed client headers:
SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")

# Full URI schemes are mandatory in Django 4.0+:
CSRF_TRUSTED_ORIGINS = [
    "https://example.com",
    "https://www.example.com",
    "https://*.example.com",
]

Why check --deploy misses it

The linter recommends setting SECURE_SSL_REDIRECT = True blindly, without checking whether proxy communication is plain HTTP.

# nginx.conf
location / {
    proxy_pass http://django_upstream;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;  # Essential to prevent redirect loops
}

Why check --deploy misses it

Static manifests are generated only during collectstatic, not during setting checks.

# In Dockerfile: run collectstatic during image build, NOT at container startup
RUN python manage.py collectstatic --noinput

# In settings.py: prevent unhandled 500s if a third-party asset reference is missing
WHITENOISE_MANIFEST_STRICT = False

Why check --deploy misses it

check --deploy inspects Django core settings only and has no visibility into Celery or worker configurations.

# settings.py (with namespace="CELERY", sets task_time_limit)
CELERY_TASK_SOFT_TIME_LIMIT = 120    # Raises SoftTimeLimitExceeded inside task
CELERY_TASK_TIME_LIMIT = 150         # Sends SIGKILL to hung child worker process
CELERY_WORKER_PREFETCH_MULTIPLIER = 1  # Prevents long-running tasks from starving queues

# Always set explicit network timeouts in your tasks:
response = requests.get("https://api.example.com/webhook", timeout=(3.05, 30))

See our step-by-step diagnostic runbook on fixing stuck or hanging Celery tasks.

Why check --deploy misses it

It emits a generic warning (W018) suggesting you review logging, but provides no structured handler or scanner suppression.

# settings.py
LOGGING = {
    "version": 1,
    "disable_existing_loggers": False,
    "formatters": {
        "verbose": {"format": "%(levelname)s %(asctime)s %(module)s %(message)s"},
    },
    "handlers": {
        "console": {"class": "logging.StreamHandler", "formatter": "verbose"},
        "null": {"class": "logging.NullHandler"},
    },
    "root": {"handlers": ["console"], "level": "INFO"},
    "loggers": {
        "django.request": {"handlers": ["console"], "level": "ERROR", "propagate": False},
        "django.security.DisallowedHost": {"handlers": ["null"], "propagate": False},
    },
}

Learn more about capturing and grouping unhandled Django exceptions without scanner noise.

Why check --deploy misses it

Static checks cannot trace request execution paths or detect synchronous network I/O in view functions.

Use django-anymail with transactional HTTP APIs (Postmark, SES, Mailgun) or dispatch email via Celery background tasks so web workers return responses immediately.

# Option A: Transactional HTTP API via django-anymail (recommended)
# pip install django-anymail[postmark]
EMAIL_BACKEND = "anymail.backends.postmark.EmailBackend"
ANYMAIL = {
    "POSTMARK_SERVER_TOKEN": os.environ["POSTMARK_SERVER_TOKEN"],
}

# Option B: Asynchronous background task (Celery)
# send_welcome_email.delay(user_id=user.id)

Why check --deploy misses it

Migration safety depends on database table size, lock timeouts, and multi-phase deployment patterns.

# In PostgreSQL migrations:
from django.contrib.postgres.operations import AddIndexConcurrently
from django.db import migrations, models

class Migration(migrations.Migration):
    atomic = False  # Mandatory for concurrent index creation

    operations = [
        # 1. Fail fast if lock cannot be acquired within 2 seconds
        migrations.RunSQL("SET lock_timeout = '2s';"),
        # 2. Add index concurrently without locking the table
        AddIndexConcurrently(
            model_name="order",
            index=models.Index(fields=["created_at"], name="order_created_idx"),
        ),
    ]

Learn how query growth affects locking in our guide on diagnosing production database queries.

Why check --deploy misses it

Pre-deploy checks are a single point in time. Runtime issues evolve as traffic patterns shift, data grows, and external services degrade.