Python-App-Hosting: Django, Flask und FastAPI bereitstellen

Python-App-Hosting beginnt mit dem Prozess, den deine Anwendung zum Ausführen braucht. Django und Flask nutzen üblicherweise einen WSGI-Server; FastAPI einen ASGI-Server. Ein Celery-Worker oder ein geplantes Skript hat einen anderen Lebenszyklus. Wähle einen Host, der diese Prozesse, die Datenbank und den Speicher unterstützt, die deine App benötigt.

Lizard veröffentlicht diesen Leitfaden. Wir haben die verlinkte Framework- und Provider-Dokumentation am 9. September 2026 geprüft. Die Beispiele verwenden explizite Modulnamen, die du an dein Projekt anpassen musst.

Laufzeit vor dem Host wählen

Der Entwicklungsserver ist für die Entwicklung. Siehe den offiziellen Django-Bereitstellungsleitfaden, Flask-Produktionsleitfaden und FastAPI-Worker-Leitfaden.

Python-Hosting-Optionen nach Bedarf

Nutze den PaaS-Vergleich für die umfassendere Hosting-Entscheidung. Ein Python-Badge in einer Feature-Tabelle reicht nicht, um Worker- oder Datenbankunterstützung zu bestätigen.

Kostenloses Python-Hosting braucht eine Workload-Grenze

Ein Free-Plan kann ausgehende Requests beschränken, einen inaktiven Web-Prozess schlafen legen, die Task-Ausführung limitieren oder nur ein Test-Guthaben enthalten. Diese Bedingungen können für eine Demo in Ordnung sein und für einen Webhook-Empfänger oder Queue-Worker ungeeignet.

Prüfe Renders Free-Service-Regeln und PythonAnywheres Free-Account-Features. Für Cloud Run beschreibt die Preisseite kostenlose Nutzung neben abrechenbaren Ressourcen. Eine Datenbank, Image-Registry oder Netzwerknutzung kann außerhalb des Allowances bleiben, auf das du schaust.

Teste den ersten Request nach einer Ruhephase und bestätige, ob geplante oder Hintergrundarbeit noch läuft. Beschreibe die kostenlose Option in Bezug auf diese Limits, nicht als unbegrenztes Hosting.

Build- und Start-Befehle

Für ein Projekt, das requirements.txt nutzt, installiere die gepinnten Abhängigkeiten mit:

python -m pip install -r requirements.txt

Nutze den Paketmanager und Lockfile, der bereits in deinem Repository liegt, falls es uv, Poetry oder ein anderes Tool nutzt. Füge den Produktionsserver in die Abhängigkeiten ein. Verlass dich nicht auf ein Paket, das nur auf deinem Laptop installiert ist.

Für Django, wo myproject/wsgi.py die Anwendung definiert:

gunicorn myproject.wsgi:application --bind "0.0.0.0:${PORT:-3000}"

Für Flask, wo app.py app exportiert:

gunicorn app:app --bind "0.0.0.0:${PORT:-3000}"

Für FastAPI, wo main.py app exportiert:

uvicorn main:app --host 0.0.0.0 --port "${PORT:-3000}"

Diese Befehle erwarten eine Shell, die die Port-Variable expandiert. Ein JSON-Array Docker CMD expandiert sie nicht automatisch. Nutze entweder die dokumentierte Variablenunterstützung der Laufzeit, einen Shell-Wrapper oder ein kleines Programm, das die Umgebung liest.

Setze Worker-Anzahlen basierend auf Messungen und verfügbarem Speicher. Mehr Prozesse können mehr Speicher und Datenbankverbindungen nutzen; Worker hinzuzufügen ist kein Ersatz für das Prüfen einer langsamen Query oder blockierenden Task.

Ein minimaler FastAPI-Container

Für eine Anwendung mit main.py und einem gelockten requirements.txt mit FastAPI und Uvicorn startet dieses Dockerfile einen Server-Prozess:

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
RUN useradd --create-home appuser
USER appuser
EXPOSE 3000
CMD ["sh", "-c", "exec uvicorn main:app --host 0.0.0.0 --port ${PORT:-3000}"]

Wähle eine Python-Version, die mit deinem Projekt kompatibel ist. Lege .env, lokale Virtual Environments, Caches und Git-Daten in .dockerignore. Dieses Beispiel installiert keine zusätzlichen OS-Pakete; füge nur jene hinzu, die deine Abhängigkeiten brauchen.

Auf Lizard kannst du ein Dockerfile mitbringen oder den Source-Build-Pfad nutzen. Der Deployment-Leitfaden erklärt die Optionen. Deine App sollte einen kleinen Health-Endpoint exponieren, und du solltest auch einen Endpoint testen, der die echten Abhängigkeiten beansprucht.

Ein auf Lizard geprüftes FastAPI-Deployment

Unser öffentliches FastAPI-Beispiel hat einen datierten Deployment-Datensatz vom 9. September 2026. Der Test nutzte Commit df522c1, gebaut aus GitHub in eu-west-lim-a, mit Port 8000 und einem Uvicorn-Startbefehl im Procfile. Es nutzte Python 3.13 mit FastAPI 0.141.1 und Uvicorn 0.52.4. Kein manueller Build- oder Start-Override war gesetzt.

Der veröffentlichte Prüfdatensatz meldet sechs bestandene Prüfungen über die öffentliche HTTPS-URL:

Öffne den live Health-Endpoint, probiere das API-Interface aus oder folge dem FastAPI-Deployment-Leitfaden.

Diese Ergebnisse decken Deployment und HTTP-Verhalten für eine kleine App ohne Datenbank ab. Sie messen keine Uptime, Lastkapazität oder End-to-End-Deployment-Zeit. Derselbe Datensatz gibt eine CLI-Ablesung um 11:48 UTC von ca. 0,034 GB Speicher und ca. $0,00051/Stunde an Ressourcenkosten. Das ist eine Momentaufnahme, keine Monatsrechnung; die genannte Ablesung nutzte die zum Zeitpunkt geltenden Raten. Aktuelles Lizard-Hosting nutzt pay as you go ohne monatliches Abo; Speicher, Traffic und Zahlungsgebühren können zum Gesamtbetrag hinzukommen. Der obige Dockerfile ist ein separates Beispiel und reproduziert nicht die exakte Konfiguration jenes Bereitstellungen.

Django, Postgres und Celery brauchen separate Prüfungen

Verbinde Managed Postgres über die Variable, die deine Django-Settings lesen. Führe Migrationen als kontrollierten Release-Schritt aus, nicht unabhängig in jedem Web-Worker. Konfiguriere den Umgang mit statischen Dateien und gib hochgeladenen Dateien dauerhaften Speicher.

Führe Celery als separaten Service mit demselben relevanten Anwendungscode und eigenem Startbefehl aus. Konfiguriere den Broker explizit, beispielsweise mit Managed Redis, falls deine App Redis nutzt. Prüfe Retries, Duplicate-Task-Handling und Shutdown, bevor du Produktionsarbeit annimmst.

Für einen selbst betriebenen Server nutze den Django-VPS-Walkthrough. Für einen verwalteten Worker sieh die Worker-Deployment-Referenz.

Die gesamte Python-Anwendung abschätzen

Web-Prozesse, Worker, Datenbank, gespeicherte Dateien, Backups, Transfer und der Plan, den dein Team braucht, einbeziehen. Railway misst Verbrauch und rechnet seinen bezahlten Plan auf die Nutzung an. Render veröffentlicht Instanzpläne. PythonAnywhere listet aktuell Developer bei $10/Monat; prüfe die inkludierten Features gegen deine App. Quellen: Railway, Render, PythonAnywhere.

Lizard hat kein monatliches Abo und keine pro-Service-Plan-Gebühr. Für eine kleine App mit durchschnittlich 0,01 vCPU und 0,1 GB Speicher über 720 Stunden, mit 10 GB Egress, betragen die Ressourcenkosten ca. $1,53 vor Zahlungsgebühren und Steuer. Füge die Datenbank, Worker und den Speicher hinzu, den deine Python-App braucht. Sieh das ausgearbeitete Beispiel und aktuelle Raten. Gekauftes Guthaben laufen nicht ab, sodass ein ruhiger Monat keinen neuen Plan-Kauf erfordert.

FAQ

Kann ich FastAPI auf denselben Services hosten wie Django? Oft ja, aber FastAPI braucht einen ASGI-Server. Bestätige, dass der Host deinen Startbefehl und alle langlebigen Verbindungen oder Worker unterstützt, die die App nutzt.

Sollte ich runserver in Produktion nutzen? Nein. Nutze einen produktiven WSGI- oder ASGI-Server und prüfe den Deployment-Leitfaden des Frameworks.

Warum sagt der Host, meine App sei ungesund? Prüfe die Build-Logs, den Prozess-Exit-Status, den Importpfad, das gebundene Interface und den erwarteten Port. Dann prüfe fehlende Variablen und Dependency-Verbindungen.

Brauche ich ein Dockerfile? Nicht auf jedem Host. Ein Source-Builder kann das Image erstellen, aber du brauchst trotzdem korrekte Abhängigkeiten und einen produktiven Startbefehl.

Was ist der beste Host für einen Python-Worker? Einer, der den Lebenszyklus und die Abhängigkeiten des Workers unterstützt. Teste Queue-Konsum, Retries und Restart-Verhalten; ein reines HTTP-Deployment reicht nicht.