Django Production Deployment Checklist (Gunicorn + nginx + PostgreSQL)

Running Django in production means a long-running Python process behind a web server, not the runserver command you use while developing. The usual stack on your own server is Gunicorn for the app, nginx in front, PostgreSQL for data and systemd to keep it all running. This checklist walks through that setup on a Linux VPS, the settings to harden before launch, and the mistakes that most often take Django sites down.

1. Choose where Django runs

Django doesn't need a VPS in every case. Pick by what the project needs:

For the shared hosting route, follow how to deploy a Python app on shared hosting. The rest of this guide is for a VPS or server where you have root.

2. Prepare the server

Use a current long-term-support release such as Ubuntu 24.04 LTS, Debian 12 or AlmaLinux 9, with Python 3.12 or later. On Ubuntu or Debian:

sudo apt update
sudo apt install python3 python3-venv python3-pip \
                 postgresql nginx git \
                 certbot python3-certbot-nginx

On AlmaLinux use dnf with the equivalent packages. Then create an unprivileged user for the app. Never run Django as root:

sudo adduser --system --group --home /home/django --shell /bin/bash django

3. Create the database

sudo -u postgres psql <<'EOF'
CREATE USER myapp WITH PASSWORD 'use-a-long-random-password';
CREATE DATABASE myapp_production OWNER myapp;
EOF

Making the app user the database owner gives it the rights it needs on PostgreSQL 15 and later, where ordinary users can no longer create tables in the public schema by default. Keep PostgreSQL listening on localhost only.

4. Code, virtual environment and requirements

As the django user, clone your project and create a virtual environment:

sudo -iu django
git clone https://github.com/you/myapp.git
cd myapp
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

A minimal requirements.txt for production:

Django>=5.2,<5.3
gunicorn
psycopg[binary]
whitenoise
python-decouple

Django 5.2 is the current long-term-support release, with security fixes until April 2028. Django 4.2 LTS reached end of support in April 2026, so upgrade any project still on it.

5. Harden settings.py

The default settings.py is for development. Read secrets from the environment (here with python-decouple, which reads a .env file) and never commit them.

from decouple import config, Csv

DEBUG = config("DEBUG", default=False, cast=bool)
SECRET_KEY = config("SECRET_KEY")
ALLOWED_HOSTS = config("ALLOWED_HOSTS", cast=Csv())
CSRF_TRUSTED_ORIGINS = ["https://yourdomain.com", "https://www.yourdomain.com"]

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.postgresql",
        "NAME": config("DB_NAME"),
        "USER": config("DB_USER"),
        "PASSWORD": config("DB_PASSWORD"),
        "HOST": config("DB_HOST", default="localhost"),
        "PORT": config("DB_PORT", default="5432"),
        "CONN_MAX_AGE": 60,
        "CONN_HEALTH_CHECKS": True,
    }
}

SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")
SECURE_SSL_REDIRECT = True
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True
SECURE_HSTS_SECONDS = 3600  # raise to 31536000 once HTTPS is proven
SECURE_CONTENT_TYPE_NOSNIFF = True
X_FRAME_OPTIONS = "DENY"

STATIC_URL = "/static/"
STATIC_ROOT = BASE_DIR / "staticfiles"
STORAGES = {
    "default": {"BACKEND": "django.core.files.storage.FileSystemStorage"},
    "staticfiles": {"BACKEND": "whitenoise.storage.CompressedManifestStaticFilesStorage"},
}

Generate a fresh secret key for production and put it, with the other values, in /home/django/myapp/.env, readable only by the django user:

python -c "from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())"

If you use WhiteNoise, add whitenoise.middleware.WhiteNoiseMiddleware directly after SecurityMiddleware in MIDDLEWARE. The old STATICFILES_STORAGE setting was removed in Django 5.1; use STORAGES as above.

6. Migrate, collect static files and run the deploy check

With the virtual environment active:

python manage.py check --deploy
python manage.py migrate
python manage.py collectstatic --noinput
python manage.py createsuperuser

check --deploy is Django's own pre-launch audit. Fix every warning it prints before you continue.

7. Run Gunicorn under systemd

Test Gunicorn by hand first: gunicorn myapp.wsgi --bind 127.0.0.1:8000. Then create /home/django/myapp/gunicorn.conf.py:

import multiprocessing

bind = "127.0.0.1:8000"
workers = multiprocessing.cpu_count() * 2 + 1
timeout = 60
max_requests = 1000
max_requests_jitter = 50
accesslog = "-"
errorlog = "-"

Size workers to your memory as well as your CPU: each worker holds a full copy of your app. Then create /etc/systemd/system/myapp.service as root:

[Unit]
Description=Gunicorn for myapp
After=network.target postgresql.service

[Service]
User=django
Group=django
WorkingDirectory=/home/django/myapp
EnvironmentFile=/home/django/myapp/.env
ExecStart=/home/django/myapp/venv/bin/gunicorn --config gunicorn.conf.py myapp.wsgi:application
ExecReload=/bin/kill -s HUP $MAINPID
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now myapp
sudo systemctl status myapp
journalctl -u myapp -f

8. nginx in front, then HTTPS

Create an nginx site for your domain (/etc/nginx/sites-available/myapp.conf on Ubuntu and Debian, /etc/nginx/conf.d/myapp.conf on AlmaLinux):

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;
    client_max_body_size 20m;

    location /static/ {
        alias /home/django/myapp/staticfiles/;
        expires 30d;
    }

    location /media/ {
        alias /home/django/myapp/media/;
    }

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 60s;
    }
}

nginx must be able to read the static folder: give it execute permission on /home/django or move static files under /var/www. Test and reload with sudo nginx -t && sudo systemctl reload nginx, then get a certificate:

sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com
sudo certbot renew --dry-run

Point the domain's A record at the VPS before running Certbot. See how to change your domain's DNS settings.

9. Deploy updates

A simple deploy, run as the django user:

cd ~/myapp
git pull
source venv/bin/activate
pip install -r requirements.txt
python manage.py migrate
python manage.py collectstatic --noinput
sudo systemctl reload myapp

The last line needs a sudo rule that lets the django user reload only this service. To automate the same steps from GitHub, adapt deploying with GitHub Actions to SSH into the VPS and reload systemd.

10. Pre-launch checklist

11. Common mistakes

12. Running Django on Domain India

VPS. Our VPS plans are self-managed with full root access, so everything in this guide applies. You install and patch the software and look after backups yourself.

App Platform. If you would rather not run a server, the App Platform runs Django from your own Dockerfile (only Node.js is detected automatically), deploys from GitHub or with a deploy token, and includes a PostgreSQL database. It does not support WebSockets, so Django Channels needs a VPS. See getting started with the App Platform.

Shared hosting. Our cPanel and DirectAdmin servers can run a small Django site as a WSGI app through the panel's Python app tool, with a MySQL-compatible database. Jailed SSH access is available on every shared hosting plan (cPanel, DirectAdmin, Webuzo). It is off by default; ask support to enable it for your account.

Ready to deploy? Compare VPS plans, try the App Platform, or read the Django, FastAPI and Flask comparison if you are still choosing a framework. Schedule jobs with the cron expression guide.