Hosting Django i Python, bez stawiania serwera.

1. Django ist ein Framework für Menschen, die ihren Server selbst kontrollieren möchten.

Django ist von Anfang an so konzipiert, dass du die volle Kontrolle über die Datenebene, die Authentifizierung und die Projektstruktur hast. Das spricht besonders Entwickler an, die auch über die Laufzeitumgebung ihrer Anwendung so viel Kontrolle haben möchten wie über den Python-Code.

Auf Saplo lässt sich eine App mit Django 5.x und auswählbarer Python-Version (3.11 oder 3.12, standardmäßig 3.12) einrichten. Der nginx-Virtual-Host und gunicorn als WSGI-Server werden automatisch konfiguriert, ohne dass du eine systemd- oder nginx-Konfigurationsdatei manuell erstellen musst.

Das Manifest weist mindestens 256 MB RAM aus. Das ist zwar eine niedrige Einstiegshürde, Django-Apps mit ORM, Sessions und Middleware laufen jedoch selten komfortabel unter 2 GB RAM, besonders wenn mehrere Nutzer gleichzeitig zugreifen. Box M ist daher praktisch die Mindestwahl für alles, was mehr als ein Prototyp ist.

2. SSH, Migrationen und App-Verwaltung direkt im Terminal

Ab Box M kannst du mit vollständigem SSH-Zugriff und sudo die üblichen Django-Befehle direkt im Terminal ausführen: manage.py migrate, collectstatic und createsuperuser. Ein separates Hosting-Admin-Panel, das Django-Befehle nicht versteht, ist damit nicht nötig.

Git-Deploy aktualisiert den Anwendungscode bei jedem Push in den festgelegten Branch. Datenbankmigrationen und weitere Deployment-Schritte, etwa der Neustart des gunicorn-Prozesses oder das Sammeln statischer Dateien, erfordern weiterhin manuelle Befehle per SSH. Für Entwickler, die Django kennen, ist das ein gewohnter Arbeitsschritt.

Celery und Hintergrundaufgaben wie Erinnerungen, E-Mail-Versand oder die Verarbeitung von Aufgaben in Warteschlangen lassen sich bei passender systemd-Konfiguration als eigener Prozess im selben Container betreiben. Bei Django-Apps mit asynchronen Aufgaben ist das oft ein Standardbestandteil der Architektur. Behalte deshalb den RAM-Verbrauch des Webprozesses und des Celery-Workers getrennt im Blick. Beide konkurrieren um das gemeinsame RAM-Limit, das dem gesamten App-Container auf der jeweiligen Box zugewiesen ist. Das ist besonders wichtig, wenn viele Celery-Aufgaben gleichzeitig im Hintergrund laufen.

3. Datenbank für Django

Django nutzt standardmäßig eine relationale Datenbank. Auf Saplo stehen Postgres und MySQL als separate Datenbankmodule zur Verfügung. Sie werden als Container in deinem eigenen Compose-Setup bereitgestellt und nicht als kostenpflichtiges Add-on separat vom App-Hosting abgerechnet.

Für Projekte, die Redis benötigen, etwa als Celery-Broker oder Session-Cache, steht ein separates Redis-Modul zur Verfügung. Es kann auf derselben Box wie die Django-App laufen. So musst du keinen externen Redis-Dienst außerhalb der Saplo-Infrastruktur verwenden.

4. Django im Vergleich zu fertigen Python-PaaS-Lösungen

Auf Python spezialisierte PaaS-Plattformen rechnen häufig pro Instanz oder stundenweise nach verbrauchten Ressourcen ab. Da die Preise in US-Dollar angegeben werden, wird die Budgetplanung in Zloty bei echtem Produktionsverkehr in Polen kompliziert und durch Wechselkursschwankungen zusätzlich erschwert.

Bei Saplo ist der Preis ein fester Jahrespreis in Zloty, unabhängig davon, wie viele Anfragen pro Sekunde die Anwendung zu einem bestimmten Zeitpunkt verarbeitet. Für Projekte mit unregelmäßigem Traffic, etwa eine interne Firmenanwendung, die nur während der Arbeitszeit genutzt wird, ist das leichter zu kalkulieren als eine stundenweise Abrechnung nach Ressourcenverbrauch.

5. Für wen es sich eignet

Wenn du eine Web-App oder ein internes Firmensystem mit Django entwickelst, steht dir mit Box M und vollständigem SSH-Zugriff sofort eine produktionsbereite Umgebung zur Verfügung. Migrationen und die Konfiguration kannst du direkt ausführen, ohne einen Server von Grund auf einzurichten.

Für ein Team, das eine größere Anwendung mit Celery, Redis und einer separaten Datenbank entwickelt, bietet Box L ausreichend RAM, damit mehrere Prozesse parallel im selben Container oder auf separaten Datenbankmodulen daneben laufen können.

Für Agenturen, die B2B-Systeme mit Django für Kunden entwickeln, können auf einer Box mehrere unabhängige Django-Installationen parallel laufen, jede in einem eigenen Container und mit eigener Datenbank.

6. Erste Bereitstellung einer Django-App auf Saplo

Verbinde nach dem Einrichten der Django-App mit der gewählten Python-Version das Git-Repository, damit sich der Code bei jedem Push automatisch aktualisiert. Führe anschließend per SSH manage.py migrate und createsuperuser aus, um Zugang zum Django-Adminbereich zu erhalten.

Umgebungsvariablen wie SECRET_KEY, den Connection String zur Datenbank und Schlüssel externer APIs setzt du im App-Panel oder in einer.env-Datei im Container, entsprechend der gängigen Konfigurationspraxis für Django außerhalb des Code-Repositorys.

Wenn deine App Celery für Hintergrundaufgaben nutzt, richte im Container einen zusätzlichen systemd-Prozess für den Worker ein, optional auch Beat für Zeitpläne. Als Broker dient Redis, das als separates Modul auf derselben Box eingerichtet ist.

Statische Dateien (collectstatic) solltest du so konfigurieren, dass der virtuelle nginx deiner Box sie ausliefert. Das entlastet den gunicorn-Prozess, während der Webserver die Dateien schneller und mit geringerem RAM-Verbrauch ausliefert.

Nach dem ersten Deployment solltest du die gunicorn- und Django-Logs per SSH überwachen, um Konfigurationsfehler wie ein in der Produktion vergessenes DEBUG=True zu erkennen, bevor die App tatsächlich von Nutzern erreicht wird.

7. Django REST Framework und API-Anwendungen auf Saplo

Als API gebaute Django-Anwendungen (mit Django REST Framework) laufen auf derselben Box genauso wie klassische Anwendungen mit Templates. Der Unterschied liegt im Django-Code, nicht in der Art des Hostings bei Saplo.

Bei APIs mit Token-Authentifizierung solltest du Geheimnisse wie JWT-Schlüssel und API-Keys externer Dienste in Umgebungsvariablen des Containers statt im Repository ablegen. Das entspricht bewährter Sicherheitspraxis.

CORS und weitere Sicherheits-Header konfigurierst du auf Ebene der Django-Anwendung selbst (Middleware). Der Reverse Proxy von Saplo leitet diese Header unverändert weiter, sodass die Standardkonfiguration von Django ohne zusätzliche Schritte funktioniert.

Bei einer API, die ein auf einer anderen Domain eingebettetes Frontend ausliefert, etwa eine Next.js-Anwendung in einer separaten Box oder auf externem Hosting, solltest du in den Django-Einstellungen besonders die Konfiguration von ALLOWED_HOSTS und CORS_ALLOWED_ORIGINS prüfen.

8. Django-Konfiguration für die Produktion absichern

Der häufigste Fehler beim Deployment von Django in die Produktion ist, DEBUG=True aktiv zu lassen. Bei einem Anwendungsfehler zeigt die App dann den vollständigen Stacktrace samt Umgebungsvariablen und Codefragmenten. Das ist ein schwerwiegender Informationsleck über die interne Struktur der Anwendung.

Der SECRET_KEY, den Django zum Signieren von Sessions und Tokens verwendet, sollte für jedes Deployment eindeutig sein und nicht ins Code-Repository gelangen. Er sollte ausschließlich als Umgebungsvariable in der Anwendungskonfiguration auf Saplo festgelegt werden, getrennt vom Quellcode.

ALLOWED_HOSTS sollte genau die Domains enthalten, unter denen die Anwendung erreichbar ist, und nicht den Wildcard-Eintrag * für alle Hosts. Das ist ein grundlegender Schutz gegen Host-Header-Injection und besonders wichtig bei Anwendungen, die Nutzerdaten aus dem Internet übernehmen.

Statische Dateien und von Benutzern hochgeladene Medien (Uploads) sollten logisch getrennt werden. Statische Anwendungsdateien lassen sich über nginx ausliefern, während Benutzerdateien über einen gesonderten Mechanismus mit entsprechenden Berechtigungen behandelt werden. So lässt sich verhindern, dass ein Benutzer ein bösartiges Skript auf den Server hochladen und dort ausführen kann.

Aktualisierungen von Django und verwendeten Python-Paketen (requirements.txt) sollten zur Routine gehören. Ähnlich wie im Node.js-Ökosystem sind veraltete Abhängigkeiten ein häufiger Angriffsvektor für bekannte, bereits behobene Sicherheitslücken, die automatisierte Schwachstellen-Scanner ausnutzen.

Bei Anwendungen, die personenbezogene Benutzerdaten speichern, solltest du die Sitzungseinstellungen, etwa Ablaufzeit sowie die Cookie-Flags Secure und HttpOnly, bewusst konfigurieren. Django unterstützt dies nativ, erfordert aber eine ausdrückliche Konfiguration in den Projekteinstellungen, da die Standardwerte nicht in jedem Szenario korrekt funktionieren. Prüfe diese Konfiguration vor dem ersten Produktionseinsatz zusammen mit der vollständigen Liste der Django-Sicherheitseinstellungen, statt eine fehlende Einstellung erst nach einem echten Sicherheitsvorfall zu entdecken.

9. Das Python-Ökosystem und Pakete für Django-Anwendungen

Python und Django bieten ein reichhaltiges Paket-Ökosystem (PyPI) für typische Anforderungen von Webanwendungen: Authentifizierung, Integrationen mit externen APIs, PDF-Berichte und Zahlungsabwicklung. So kannst du Funktionen auf Basis bewährter, geprüfter Lösungen entwickeln, statt alles von Grund auf zu programmieren.

Mit vollständigem SSH-Zugriff und sudo ab Box M kannst du auf Saplo über den Standard-Installer pip beliebige Python-Pakete installieren, ohne dass die Hosting-Plattform Einschränkungen auferlegt. Das unterscheidet Saplo von manchen geschlossenen PaaS-Umgebungen, die nur eine begrenzte Auswahl unterstützter Bibliotheken bieten.

Die Wahl zwischen gängigen Django-Erweiterungen wie Django REST Framework für APIs, Django Channels für WebSockets und Django CMS für die Inhaltsverwaltung liegt vollständig bei den Entwicklern der Anwendung. Vom Hosting werden nicht vorab architektonische Einschränkungen vorgegeben.

Die Aktualisierung der Python-Version von 3.11 auf 3.12 ist als Konfigurationsoption der Anwendung verfügbar. So kannst du neue Sprachfunktionen und Performance-Verbesserungen nutzen, ohne aus diesem Grund zu einem anderen Anbieter wechseln zu müssen.

Für Teams, die komplexere Django-Anwendungen mit Celery, Redis und zahlreichen externen Integrationen entwickeln, bietet die volle Kontrolle über die Umgebung per SSH in Verbindung mit den fertigen Basiskomponenten von Saplo eine Flexibilität wie bei einem klassischen VPS, verkürzt aber die Zeit für die Bereitstellung der Basisumgebung.

10. Datenbankmigrationen vor dem Produktivdeployment testen

Django-Migrationen, die die Datenbankstruktur verändern, etwa durch das Hinzufügen einer Spalte oder die Änderung eines Feldtyps, solltest du zuerst an einer Kopie der Datenbank testen und nicht direkt auf der Produktionsdatenbank ausführen. Ein Fehler in der Migration kann Datenverlust verursachen oder die Anwendung während der Migration unerreichbar machen.

Ein Box-Backup ab Box L vor einer größeren Migration ist ein zusätzlicher Schutz, mit dem du bei Problemen zum Stand vor der Migration zurückkehren kannst. Zwar ist es auch gute Praxis, unmittelbar vor der Migration eine separate manuelle Kopie der Datenbank zu erstellen.

Nicht umkehrbare Migrationen, etwa das Entfernen einer Spalte mit Daten, erfordern besondere Vorsicht. Bei einem Fehler lassen sich die gelöschten Daten nur aus einem Backup aus der Zeit vor der Migration wiederherstellen, nicht durch das Zurückrollen der Migration in Django.

Für Teams, die mit derselben Datenbank arbeiten, solltest du einen klaren Ablauf für Migrationen in der Produktion festlegen: Wer führt sie aus, wann und nach welchem Test? So vermeidest du, dass zwei Personen gleichzeitig widersprüchliche Migrationen auf derselben Datenbank ausführen.

Der vollständige SSH-Zugriff mit sudo auf Saplo (ab Box M) bietet alle Werkzeuge für eine sichere Ausführung von Migrationen. Für die Prozessdisziplin mit Test, Backup und erst dann der Migration in der Produktion bleibt jedoch das Entwicklerteam des Projekts voll verantwortlich.

11. Fazit: Django auf Saplo für Entwickler, die Kontrolle wollen

Vollständiger SSH-Zugriff mit sudo, die Wahl der Python-Version und eine fertige gunicorn- und nginx-Konfiguration vereinen für Django-Entwickler genau die Kontrolle und Bequemlichkeit, die sie beim Deployment einer Produktionsanwendung suchen: Standardbefehle wie manage.py funktionieren wie erwartet, und die gesamte Serverebene ist bereits eingerichtet. Bei jedem neuen Django-Projekt musst du sie also nicht mehr von Grund auf aufbauen. Für Teams mit mehreren parallelen Django-Projekten bedeutet diese wiederholbare Konfiguration außerdem, dass das nächste Projekt genauso schnell startet wie das erste, ohne dieselben längst bekannten Konfigurationsschritte erneut durchzugehen. In der Praxis bleibt damit auch weniger Raum für kleine, schwer erkennbare Konfigurationsunterschiede zwischen Projekten, die bei selbst aufgesetzten Servern häufig eine nicht offensichtliche Quelle von Produktionsfehlern sind.