Node.js- und Python-Hosting: Anforderungen und Optionen

Node.js- und Python-Anwendungen brauchen ein Hosting, das einen dauerhaft laufenden Prozess erlaubt. Anders als bei PHP, wo der Webserver für jede Anfrage ein Skript ausführt, startet Ihre Anwendung einmal, hört auf einem Port und beantwortet Anfragen selbst. Daraus ergeben sich die Kernanforderungen: wählbare Laufzeitversion, Paketinstallation, ein Prozessmanager, ein Reverse Proxy davor und ein sauberer Weg für Deployments. Welche Servervarianten es grundsätzlich gibt, erklärt der Ratgeber Server-Hosting.

Warum PHP-Webspace nicht automatisch passt

Klassischer Webspace ist auf das PHP-Modell zugeschnitten: Der Webserver ruft bei jeder Anfrage ein Skript auf, das Ergebnis geht an den Browser, danach endet die Ausführung. Node.js und Python funktionieren im Webbetrieb anders:

Merkmal	PHP auf Webspace	Node.js und Python
Ausführung	pro Anfrage	dauerhafter Prozess
Start	automatisch durch den Webserver	durch Prozessmanager oder Plattform
Abhängigkeiten	meist vom Hoster vorinstalliert	pro Projekt über npm oder pip
Konfiguration	Dateien im Webspace	oft über Umgebungsvariablen
Langlebige Verbindungen	eher unüblich	WebSockets, Server-Sent Events üblich
Neustart nach Änderungen	nicht nötig	nötig, sonst läuft der alte Code weiter

Ein Tarif, der nur PHP und eine Datenbank anbietet, reicht deshalb nicht, auch wenn er technisch Node.js als Kommandozeilenwerkzeug installiert hat.

Die Anforderungen im Detail

Laufzeitversion

Sie sollten die Version von Node.js oder Python pro Anwendung festlegen können. Bei Node.js sind die Versionen mit Langzeitunterstützung (LTS) die übliche Wahl für den Produktivbetrieb. Bei Python richtet sich die Version nach dem Framework. Wichtig ist in beiden Fällen, dass die gewählte Version noch Sicherheitsupdates erhält und dass ein Update des Servers Ihre Version nicht ungefragt ersetzt.

Paketinstallation

Node.js-Projekte installieren ihre Abhängigkeiten mit npm, pnpm oder Yarn, Python-Projekte mit pip oder einem Werkzeug wie Poetry, meist in einer virtuellen Umgebung. Das Hosting muss diese Installation zulassen, genügend Speicher dafür bereitstellen und ausgehende Verbindungen zu den Paketquellen erlauben. Native Erweiterungen, etwa für Bildbearbeitung oder Datenbanktreiber, benötigen zusätzlich Compiler oder passende Systembibliotheken.

Prozessmanager

Jemand muss die Anwendung starten, bei einem Absturz neu starten und nach einem Serverneustart wieder hochfahren. Auf einem eigenen Server übernehmen das zum Beispiel systemd oder für Node.js PM2. Bei Plattformen und manchen Shared-Hosting-Tarifen erledigt das die Hosting-Umgebung, häufig auf Basis von Phusion Passenger. Für Python kommt ein Anwendungsserver hinzu: Gunicorn oder uWSGI für WSGI-Anwendungen, Uvicorn oder ähnliche für ASGI-Anwendungen.

Reverse Proxy

Vor der Anwendung sitzt in der Regel ein Webserver wie Nginx, Apache, Caddy oder ein Load Balancer der Plattform. Er nimmt Anfragen auf den Ports 80 und 443 entgegen, kümmert sich um das TLS-Zertifikat, liefert statische Dateien direkt aus und leitet dynamische Anfragen an den Port Ihrer Anwendung weiter. Für WebSockets muss der Proxy die Verbindungsaufwertung durchreichen. Moderne Protokolle und Kompression konfigurieren Sie ebenfalls hier, mehr dazu im Artikel HTTP/3, Brotli und OPcache.

Umgebungsvariablen und Geheimnisse

Datenbankzugang, API-Schlüssel und Modus (Entwicklung oder Produktion) gehören nicht in den Quellcode, sondern in Umgebungsvariablen oder einen Geheimnisspeicher der Plattform. Achten Sie darauf, dass Sie diese Werte setzen können, ohne sie in ein Repository einzuchecken.

Hintergrundaufgaben

Viele Anwendungen versenden E-Mails, verarbeiten Uploads oder rechnen regelmäßig Daten durch. Dafür brauchen Sie Cronjobs, eine Warteschlange oder einen zweiten Prozess. Plattformen berechnen solche Worker oft separat.

Datenbank und Speicher

Neben der Datenbank brauchen Anwendungen manchmal einen Cache wie Redis und dauerhaften Speicher für Dateien. Bei Containern und vielen Plattformen ist das Dateisystem flüchtig: Nach einem Neustart sind lokal gespeicherte Uploads weg. Dauerhafte Daten gehören dann in einen Objektspeicher oder ein eingebundenes Volume.

Die Hosting-Optionen im Vergleich

Option	Geeignet für	Stärken	Grenzen
Shared Hosting mit App-Funktion	kleine Anwendungen, Bots, einfache APIs	günstig, Verwaltung im Control Panel	wenig Speicher, eingeschränkte Versionen, nicht jede Funktion verfügbar
Plattform als Dienst (PaaS)	Webanwendungen ohne eigene Serverpflege	Deployment per Git, Skalierung, Zertifikate automatisch	Kosten wachsen mit Nutzung, Bindung an die Plattform
VPS oder Root-Server	volle Kontrolle, mehrere Anwendungen	frei konfigurierbar, planbare Kosten	Sicherheit, Updates und Überwachung liegen bei Ihnen
Managed Server	Unternehmen ohne eigene Administration	Hoster pflegt System und Sicherheit	teurer, Abstimmung bei Sonderwünschen
Container-Plattform	mehrere Dienste, Teams mit DevOps-Erfahrung	reproduzierbare Umgebungen	Einarbeitung und Betriebsaufwand
Serverless- und Edge-Funktionen	APIs, kleine Funktionen, Teile von Frontends	keine Serverpflege, Abrechnung pro Aufruf	Laufzeitgrenzen, nicht alle Bibliotheken nutzbar
Statisches Hosting	Seiten, die beim Build vollständig erzeugt werden	schnell, günstig, wenig Angriffsfläche	keine serverseitige Logik

Wann sich der Schritt vom Shared Hosting auf einen eigenen Server lohnt, beschreibt der Artikel Shared Hosting oder VPS. Einen Überblick über alle Varianten bietet der Ratgeber Hosting-Arten.

Besonderheiten bei Node.js

• Frameworks mit Build-Schritt: Anwendungen wie Next.js, Nuxt, Astro oder SvelteKit werden vor dem Start gebaut. Klären Sie, ob der Build auf dem Server oder in einer CI-Umgebung läuft, denn er braucht deutlich mehr Arbeitsspeicher als der laufende Betrieb.
• Ein Prozess, ein Kern: Ein Node.js-Prozess nutzt für JavaScript im Wesentlichen einen Prozessorkern. Für mehr Durchsatz starten Prozessmanager mehrere Instanzen.
• Speicherverbrauch: Lecks fallen oft erst nach Tagen auf. Eine Überwachung des Speichers und automatische Neustarts bei Grenzwerten verhindern schleichende Ausfälle.

Besonderheiten bei Python

• Virtuelle Umgebung: Installieren Sie Abhängigkeiten pro Projekt in einer eigenen Umgebung und halten Sie die Versionen in einer Datei fest.
• Statische Dateien: Django sammelt CSS, JavaScript und Bilder in einem Verzeichnis, das der Webserver direkt ausliefern sollte, nicht die Anwendung selbst.
• Worker-Anzahl: Die Zahl der Anwendungsserver-Prozesse richtet sich nach Prozessorkernen und Arbeitsspeicher. Zu viele Prozesse auf einem kleinen Server führen zu Speichermangel.

Typische Fehler beim ersten Deployment

• Anwendung lauscht nur auf localhost oder auf einem festen Port: Viele Plattformen geben den Port über eine Umgebungsvariable vor. Liest die Anwendung ihn nicht aus, ist sie von außen nicht erreichbar.
• Entwicklungsmodus im Produktivbetrieb: Debug-Ausgaben verraten interne Informationen und kosten Leistung. Setzen Sie den Produktionsmodus ausdrücklich.
• Abhängigkeiten ohne feste Versionen: Ohne Lockfile oder festgelegte Versionen installiert der Server womöglich andere Pakete als Ihr Rechner. Die Folge sind Fehler, die lokal nicht auftreten.
• Uploads im flüchtigen Dateisystem: Nach dem nächsten Neustart sind sie weg. Planen Sie einen dauerhaften Speicher ein.
• Keine Logs: Wer nicht weiß, wo die Ausgaben der Anwendung landen, sucht bei Fehlern im Dunkeln. Klären Sie vor dem Start, wo Logs liegen und wie lange sie aufbewahrt werden.
• Kein Neustart nach Änderungen: Neuer Code ist erst aktiv, wenn der Prozess neu gestartet wurde. Gute Deployment-Abläufe erledigen das automatisch und ohne Ausfall.

Checkliste für die Auswahl

• Gewünschte Laufzeitversion verfügbar und pro Anwendung festlegbar
• Paketinstallation mit ausreichend Speicher und Zugriff auf die Paketquellen
• Prozessmanager mit automatischem Neustart vorhanden
• Reverse Proxy mit TLS, Weiterleitung auf den Anwendungsport und WebSocket-Unterstützung
• Umgebungsvariablen ohne Eintrag im Repository setzbar
• Möglichkeit für Hintergrundprozesse oder Cronjobs
• Dauerhafter Speicher für Uploads und eine passende Datenbank
• Logs der Anwendung einsehbar
• Deployment per Git oder Skript, mit Rückkehr zur Vorversion
• Serverstandort und Vertrag zur Auftragsverarbeitung geklärt