Produktiv Server für eine Django App
Warum ich den Django-Entwicklungsserver gegen Nginx Unit getauscht habe – und was das gebracht hat.
Der eingebaute Django-Entwicklungsserver taugt nicht für Produktion. Nginx Unit ist eine schlanke Alternative zu Gunicorn und uWSGI – mit REST-API-Konfiguration und ohne Service-Neustarts.
Warum nicht einfach Gunicorn?
Wenn man eine Django-App in Produktion bringen will, greift man reflexhaft zu Gunicorn oder uWSGI – beide sind seit Jahren der Standard-Stack hinter jedem Django-Deployment. Ich auch, lange Zeit.
Aber nach dem dritten Projekt, bei dem ich für jede Konfigurationsänderung den Service neu starten musste, und dem ewigen Nginx-als-Reverse-Proxy-vor-Gunicorn-Setup, bin ich auf Nginx Unit gestoßen. Der Reiz: eine Komponente statt zwei, live-konfigurierbar per REST-API, und ohne den typischen Reload-Downtime.
Nginx Unit ist ein Application Server von den Nginx-Machern, der Python (WSGI/ASGI), Go, PHP, Ruby, Java und mehr in einem Prozess bedient. Die gesamte Konfiguration läuft über eine REST-API – kein Config-File editieren, kein Service-Restart. Änderungen werden atomar angewendet, ohne eine einzige Anfrage zu droppen.
Installation
Auf Debian/Ubuntu ist Unit in den offiziellen Repos. Python-Modul nicht vergessen:
sudo apt update
sudo apt install unit unit-dev unit-python3Nach der Installation läuft der Unit-Daemon automatisch. Die API ist über einen Unix-Socket erreichbar – kein offener Port, kein Auth-Problem.
Die JSON-Konfiguration
Statt klassischer Config-Dateien arbeitet Unit mit einem JSON-Payload. Hier die minimale Konfiguration für ein Django-Projekt:
{
"listeners": {
"*:8000": {
"pass": "applications/django"
}
},
"applications": {
"django": {
"type": "python 3",
"path": "/var/www/myproject/",
"module": "myproject.wsgi",
"environment": {
"DJANGO_SETTINGS_MODULE": "myproject.settings"
}
}
}
}Die Struktur ist selbsterklärend: Ein Listener auf Port 8000 leitet alles an die Django-App weiter. path zeigt auf das Projektverzeichnis, module auf das WSGI-Modul. Mehr braucht es nicht für den Start.
Konfiguration anwenden – ohne Neustart
Die Konfiguration wird per curl an den Unit-Socket geschickt. Das ist der Moment, in dem Unit seinen größten Vorteil ausspielt – die Änderung wird sofort wirksam, ohne den laufenden Dienst zu unterbrechen:
sudo curl -X PUT --data-binary @config.json \
--unix-socket /var/run/control.unit.sock \
http://localhost/config/Du kannst Worker-Prozesse, Listener-Ports oder sogar die Python-Version im laufenden Betrieb ändern – einfach das JSON anpassen und erneut PUT-en. Unit wendet die Änderungen atomar an. Kein systemctl reload, kein Risiko für abgebrochene Requests.
Nach dem PUT ist die Django-App sofort unter Port 8000 erreichbar. Für einen produktiven Einsatz stellt man in der Regel noch einen Reverse Proxy wie Nginx oder Traefik davor – aber Unit selbst kann auch statische Dateien direkt ausliefern.
Was ich weggelassen habe
Dieser Artikel zeigt das Minimal-Setup. Folgendes ist bewusst nicht behandelt:
- Docker-Deployment. Unit hat ein offizielles Docker-Image – das wäre ein eigener Artikel.
- Static-File-Serving direkt über Unit. Geht, ist aber bei großen Projekten mit Whitenoise oder CDN meist besser gelöst.
- ASGI statt WSGI. Unit kann auch ASGI (für Channels, async Views) – benötigt ein leicht anderes JSON-Config.
- systemd-Hardening. In Produktion sollte der Unit-Prozess per systemd abgesichert werden (
ProtectSystem,NoNewPrivilegesetc.).
Fazit & Ausblick
Nginx Unit ist für mich der sauberste Weg, eine Django-App in Produktion zu bringen, wenn man Gunicorn-plus-Nginx-Doppelpack-Müdigkeit hat. Eine Komponente, JSON-Config über REST, Live-Rekonfiguration ohne Downtime. Für kleine bis mittlere Projekte ist das Setup in 15 Minuten erledigt.
Wer bereits einen Reverse Proxy wie Traefik oder Nginx Proxy Manager im Homelab betreibt, stellt Unit einfach dahinter und hat ein vollständiges Production-Setup.