Zero-downtime releases & rollback for Django in production
Releasing without breaking users: zero-downtime switches, canaries, blue-green, maintenance windows, and rollback.
Releasing without downtime depends on two things: code and schema that tolerate each other during the switch, and a way to move traffic back quickly if the new version misbehaves.
The guides cover zero-downtime deploys, blue-green and canary releases, feature flags, maintenance windows, verification, and rollback.
Set it up
Guides that take this from nothing to running in production.
- Set Up a Staging Environment for Django
Build a Django staging environment that catches real release problems: production parity, isolated data and secrets, and safe side effects.
- Atomic Django Releases With Symlinked Release Directories
Deploy Django with timestamped release directories and an atomic current symlink: build each release in isolation, share media and env files, switch with ln -sfn, reload Gunicorn gracefully, and roll back instantly to the previous release.
Run it well
Tuning, reliability, and operations once it works.
- How to Set Up Zero-Downtime Deployments for Django
A standard Django deploy often causes a brief outage because the old app process stops before the new one is fully ready.
- How to Roll Back a Django Release Safely
A failed Django release can break more than page requests. It can also break background workers, scheduled jobs, static asset loading, startup commands, or database compatibility.
- Blue-Green Deployments for Django
Run blue-green deployments for Django with Nginx: two release environments, smoke tests, instant traffic switching, migration rules, and fast rollback.
- Use Feature Flags for Safer Django Releases
Use feature flags in Django to separate deploys from releases: flag types, a simple flag model, django-waffle, gradual rollouts, kill switches, and cleanup.
- Django Maintenance Mode During Deploys
Put a Django site into maintenance mode safely: an Nginx flag file returning 503 with Retry-After, a static maintenance page, staff IP bypass, health checks, and when to avoid maintenance windows.
- Canary Releases for Django
Release Django changes to a small share of traffic first: run stable and canary versions side by side, split traffic in Nginx or a load balancer, compare errors and latency per version, and promote or roll back.
- Graceful Shutdown for Django and Celery (SIGTERM)
Shut down Django web servers and Celery workers without dropping requests or tasks: how Gunicorn, Uvicorn, and Celery handle SIGTERM, graceful timeouts, Docker stop_grace_period, Kubernetes preStop and terminationGracePeriodSeconds, and PID 1 pitfalls.
- Django Migration Strategy for Safe Deployments
A good app deploy can still fail if the database migration step is unsafe. That is the real problem behind many Django migration deployment issues in production.
- How to Write a Django Deployment Bash Script
A manual Django deployment often looks simple at first: SSH into a server, pull code, install dependencies, run migrations, collect static files, restart Gunicorn, and hope the...
- Move a Django Database With Minimal Downtime Using Logical Replication
Migrate a Django PostgreSQL database to a new server, provider, or major version with seconds of downtime: logical replication publications and subscriptions, schema copy, sequence sync, cutover steps, and verification.
- Roll Back a Django Migration in Production
Undo a Django migration safely in production: migrate an app back to a previous migration, understand which operations are reversible, handle data loss from reverting added columns and data migrations, roll back code and schema in the right order, and prefer forward fixes.
- Rename a Django Model Field Without Downtime
Rename a Django model field or column without breaking running code during rolling deploys: use db_column to rename in Python only, or expand and contract with a new column, dual writes, backfill, and removal across several releases.
- Remove a Django Field Without Downtime
Drop a Django model field and its database column safely during rolling deploys: stop using the field in code first, remove it from Django’s state with SeparateDatabaseAndState, drop the column in a later release, and handle NOT NULL columns and dependent indexes.
- Keep Django Available During Kubernetes Node Maintenance With PodDisruptionBudgets
Protect a Django deployment from voluntary disruptions on Kubernetes: add PodDisruptionBudgets for web and Celery, spread replicas across nodes and zones, set graceful termination and preStop delays, and avoid budgets that block node drains forever.
- Zero-Downtime Rolling Updates for Django on Kubernetes
Make Kubernetes rolling updates of Django truly zero-downtime: configure maxSurge and maxUnavailable, readiness probes that reflect real readiness, preStop delays for endpoint propagation, Gunicorn graceful shutdown, backward-compatible migrations, and minReadySeconds.
- Purge the Cloudflare or CDN Cache After a Django Deploy
Decide what to purge from Cloudflare or another CDN after deploying Django: rely on hashed static file names, purge cached HTML by URL or tag, automate purges from CI with an API token, avoid purge-everything, and keep old assets available during rollouts.
Check it
Review lists to run before launch or after a change.
- Django Deployment Checklist for Production
A Django app that works locally is not automatically safe to run in production. Most deployment failures come from a small set of issues: wrong settings, missing secrets, unsafe...
- Django Go-Live Day Runbook
A step-by-step runbook for launching a Django site: pre-launch freeze, DNS and TLS cutover, data migration, smoke tests, monitoring during launch, and rollback.
- Post-Deploy Verification Checklist for Django
Verify a Django release after every deploy: smoke tests, release version checks, migrations, static files, background jobs, and latency monitoring.
- Django SaaS Launch Checklist
A launch checklist for a Django SaaS product: production settings and security, tenant isolation, authentication and 2FA, billing webhooks, email deliverability, backups, monitoring, legal pages and data protection, support, and capacity.
- Django E-commerce Launch Checklist
A launch checklist for Django online stores: payment and webhook reliability, order and inventory integrity, transactional emails, taxes and prices, performance under traffic, backups, monitoring of checkout, legal pages, and a rollback plan for launch day.
- Django Version Upgrade Checklist for Production
Upgrade Django in production safely: plan the target version, read release notes, fix deprecations, upgrade dependencies, test, deploy, and roll back if needed.
- DNS Cutover Checklist for Moving a Django Site
A checklist for switching DNS when moving a Django site to a new server, host, or CDN: lower TTLs in advance, prepare TLS certificates and ALLOWED_HOSTS, sync data and freeze writes, switch records, verify from several locations, and keep the old host as a fallback.
Fix it
Errors and symptoms, each traced to a cause and a fix.
- Fix Django Code Changes Not Showing After Deploy
Fix deploys that seem to do nothing: Gunicorn not reloaded, old processes still running, wrong release directory, cached templates, and stale assets.
- Django Migration Failed During Deploy: Recovery Playbook
A failed Django migration during deploy usually means your release reached production, but the database change step did not finish cleanly.
- Fix Users Logged Out After a Django Deploy
Stop Django deploys from logging everyone out: a changed or per-process SECRET_KEY, cache-backed sessions lost on restart, changed cookie settings, and rotating keys safely with SECRET_KEY_FALLBACKS.
- Fix Celery Tasks Running Old Code After a Deploy
Fix Celery workers that keep executing old task code after a Django deploy: restart every worker gracefully, check which release each worker runs, and keep task signatures compatible across versions.
- Fix Django Cache Errors After Deploy: "Can’t Get Attribute" When Unpickling
Fix Django errors after a deploy such as AttributeError Can’t get attribute on module, ModuleNotFoundError, or TypeError when reading cached objects: version cache keys per release, avoid pickling model instances, and clear or namespace the cache safely.
Learning paths through this topic
- Your first production deployment on a VPSFrom a fresh Ubuntu server to a Django site on HTTPS, with the settings and checks that keep it safe.
- Releases without downtimeScript the release, make migrations backward compatible, and switch, verify, or roll back without users noticing.
- Django on KubernetesRun Django on a cluster with config, ingress, probes, jobs, graceful shutdown, and autoscaling, then package it with Helm and GitOps.