Plan a Django deployment on Kubernetes with Gunicorn and a proxy

You have a Django web application and want to run it reliably in Kubernetes. Django supplies the application framework. Gunicorn is a production Python application server that runs compatible Django applications and handles their requests. A reverse proxy, such as NGINX, sits in front and can handle tasks such as accepting external connections and forwarding requests.

Kubernetes runs and replaces the application containers. It does not choose secure Django settings, store uploaded files for you or make database upgrades reversible. First draw the request path from the browser through your gateway or proxy to the application, then decide where certificates, static files, uploads and database changes are handled.

Use this guide when moving a Django application into Kubernetes, with the server interface appropriate to that application's features. The original article was not recovered. NGINX as a proxy is distinct from the retired community ingress-nginx Kubernetes controller.

Define the request path

Document where TLS terminates, which component validates hostnames, whether requests are buffered, and which proxies may supply forwarded headers. Gunicorn's deployment guide discusses proxy buffering and trusted headers. Copying a host-based configuration into a Kubernetes pod without checking that trust boundary can change both security and streaming behavior.

Choose the application server interface appropriate to the project and its dependencies. Pin supported Python, Django, server and image versions. Start worker sizing from application memory and CPU measurements rather than a formula copied from an unrelated host.

Separate runtime from release work

1. Build an immutable application image and run Django's deployment checks against the intended settings. Keep production secrets outside the image and source repository.
2. Decide how static assets are built and served, and where uploaded media persists. Container-local files are not a durable user-upload strategy.
3. Plan database migrations as a controlled release step. Avoid running a non-idempotent migration independently in every replica at startup.
4. Choose readiness and liveness checks that distinguish inability to serve from a condition that restarting can fix. Test startup and graceful termination under real request durations.

Test the features users depend on

Exercise login, logout, CSRF protection, secure cookies, absolute URL generation, uploads and background jobs through the actual proxy path. Check unknown hosts and direct access to the application server. Ensure diagnostic logs do not expose credentials or personal request data.

Rollback boundary

Keep the previous image and deployment settings, but separately classify database changes as backward compatible or requiring a recovery procedure. An old image may fail against a new schema. Test restore and release sequencing with representative data before a production migration.

This page is a deployment design checklist, not a verified application chart or a claim that a generic manifest runs every Django project. Use the gateway guide to select the maintained external traffic layer.