Unabhängiger Vergleich · keine bezahlten Platzierungen
Startseite / Blog / Ratgeber / Hosten Sie Ihre erste Node.js-Anwendung, ohne sie wie eine PHP-Site zu behandeln

Hosten Sie Ihre erste Node.js-Anwendung, ohne sie wie eine PHP-Site zu behandeln

Node.js wird als langer Prozess ausgeführt, nicht als kurzlebige PHP-Anfrage. PM2, Reverse-Proxy, Umgebungsvariablen und Listening-Port verändern alles – von der ersten Express- oder Nest-App an.

Redaktion Hébergeurs.eu 6 Min. Aktualisiert 19 Juli 2026

Ein Entwickler sendet seine Express-Anwendung per FTP an Shared PHP Hosting. Es startet nichts: kein permanentes „node server.js“, kein offengelegter Port 3000, kein konfigurierter Reverse-Proxy. Es ist nicht Node.js, das „kompliziert“ ist, sondern Node.js, das wie PHP gehostet wird, bei dem jede Anfrage einen Interpreter startet, der sofort abstürzt.

Wenn Sie Ihre erste Node.js-Anwendung hosten, müssen Sie ein anderes Ausführungsmodell akzeptieren. PHP-FPM verarbeitet kurze Anfragen; Node.js unterhält einen lebenden Prozess, der den Status im Speicher behält, einen HTTP-Port abhört und auf Verbindungen wartet. Ohne Prozessmanager, Proxy und automatischen Neustart beendet die erste Datenverkehrswelle – oder der erste Absturz des Prozesses – Ihren „Go-Live“.

PHP und Node.js: zwei Ausführungsmodelle

AussehenKlassisches PHP (FPM)Node.js
ProzessKurz, auf AnfrageLang, anhaltend
HörenÜber Apache oder Nginx zu FPMEigener HTTP-Port
Zustand im GedächtnisBegrenztSitzungen, Anwendungscache möglich
BereitstellungDateien + OPcachenpm ci, erstellen, Prozess neu starten
SkalierungMehr FPM-MitarbeiterPM2-Cluster, mehrere Instanzen

Node.js wie PHP zu behandeln ist, als würde man ein Restaurant bitten, den Ofen für jede Bestellung aufzuwärmen.

Auf einem gemeinsam genutzten PHP weiß der Webserver, wie er „.php“-Dateien ausführt. Es weiß nicht, wie ein Node.js-Prozess zwischen zwei Anfragen aktiv gehalten werden kann. Selbst wenn Sie „server.js“ hochladen, startet es niemand – und niemand startet es neu, wenn es um 3 Uhr morgens abstürzt.

Minimaler Stapel für eine erste Produktion

1. Kontinuierlicher Integrations-Build. „npm ci“, automatisierte Tests, „npm run build“, wenn ein Frontend kompiliert wird. Die Produktion erhält ein getestetes Artefakt, keinen improvisierten „Git Pull“.

2. Prozessmanager. PM2-Ökosystemdatei oder Systemd-Einheit mit „Restart=always“. Der Prozess muss nicht erkannte Fehler überstehen und beim Serverstart neu starten.

3. Reverse Proxy. Nginx mit „proxy_pass“ zu „127.0.0.1:PORT“. Node.js stellt Port 3000 nicht direkt dem Internet zur Verfügung – der Proxy übernimmt TLS, Header und Komprimierung.

4. TLS-Verschlüsselung. Let's Encrypt auf Nginx, nicht in Node.js, sofern dies nicht ausdrücklich eingeschränkt ist. Automatisierte Erneuerung und dokumentiertes Nginx-Neuladen.

5. Umgebungsvariablen. „NODE_ENV=Produktion“, Geheimnisse über Umgebungsvariablen – werden nie an das Repository übergeben. Eine „.env“-Datei auf dem Server, eingeschränkte Berechtigungen.

6. Protokolle. aggregierte stdout und stderr; Rotation beim Schreiben auf die Festplatte. Ohne zentralisierte Protokolle bleibt ein nächtlicher Absturz bis Montagmorgen unsichtbar.

7. Gesundheitsprüfung. Route „/health“ für Überwachung und Lastausgleich. Ohne sie kann ein Zombie-Prozess „online“ bleiben, ohne Anfragen zu bearbeiten.

Wählen Sie den richtigen Host

OptionenFür wen
PaaS-Knoten (Eisenbahn, Clever Cloud, Heroku-ähnlich)Erste Anwendung, wenig Nutzen
VPS + PM2Volle Kontrolle, vorhersehbare Kosten
Container (Docker, Kubernetes)Team bereits im Container

Vermeiden Sie „Shared PHP Unlimited“-Angebote ohne explizite Erwähnung von Node.js – das ist das falsche Produkt. Vergleichen Sie PaaS- und VPS-Angebote in unserem Verzeichnis und im Vergleich. Informationen zur seit langem bestehenden Bereitstellungskultur finden Sie auch unter Django in der Produktion und PM2 und Bereitstellung – andere Stacks, dieselben Prinzipien.

Klassische Fehler bei der ersten Produktion

  • node_modules von Windows auf Linux hochgeladen, ohne native Module neu zu erstellen – bcrypt, Sharp und sqlite3 stürzen lautlos ab.
  • Anwendung, die auf „0.0.0.0“ ohne Firewall lauscht – der Node.js-Port wird direkt verfügbar gemacht, unter Umgehung von Nginx.
  • Kein Speicherlimit – ein JavaScript-Leck zerstört den gesamten Server nach ein paar Stunden.
  • Vergessene WebSockets in der Nginx-Konfiguration – „Upgrade“- und „Connection“-Header fehlen, Echtzeit funktioniert nicht.
  • Bereitstellung = Git Pull ohne PM2-Neustart – der alte Code läuft immer noch im Speicher.

Jeder Fehler ist vorhersehbar. Keine sind unvermeidlich, wenn Sie den gesamten Zyklus testen, bevor Sie die Veröffentlichung ankündigen.

Oben: Node.js fragt nach einem Host, der einen Prozess leben lässt

Hier erfahren Sie, was in den Tutorials zur „Bereitstellung in fünf Minuten“ vergessen wird.

Entscheide dich und gehe ohne blinden Fleck voran

An einem Tag können Sie den Grundstein für eine echte Node.js-Produktion legen:

  1. Validieren Sie ein Node.js-, PaaS- oder VPS-Angebot mit Root-Zugriff.
  2. Konfigurieren Sie PM2 oder systemd, dann nginx als Reverse-Proxy.
  3. Automatisieren Sie die Bereitstellung mit einem Neustart des Prozesses bei jeder Veröffentlichung.
  4. Testen Sie die Wiederherstellung nach einem Absturz – beenden Sie den Prozess manuell und prüfen Sie den Neustart.
  5. Überwachen Sie den Speicher und die Anzahl der PM2-Neustarts.

Überprüfen Sie zunächst, ob Ihr Host einen dauerhaften Prozess zulässt – dies ist die nicht verhandelbare Voraussetzung. Dokumentieren Sie als Nächstes, wer die Konfiguration ändert, wie Nginx nach der TLS-Erneuerung neu gestartet wird und wo die Protokolle im Falle eines Absturzes gelesen werden können. Weitere Informationen zu Speicherlecks finden Sie unter Node.js-Speicherleck.

Häufig gestellte Fragen

Können wir Node.js auf einer gemeinsam genutzten PHP-Plattform hosten?

Selten. Ein gemeinsam genutztes PHP unterhält keinen dauerhaften Node.js-Prozess, stellt keinen benutzerdefinierten Port bereit und konfiguriert keinen Reverse-Proxy für Ihre Anwendung. Suchen Sie nach einem dedizierten Node.js-Angebot, PaaS oder VPS.

PM2 oder systemd in der Produktion?

Beide funktionieren. PM2 vereinfacht den Cluster-Modus und das nahtlose Nachladen; systemd integriert sich nativ in das Linux-Systemprotokoll. In beiden Fällen ist ein automatischer Neustart nach einem Absturz und beim Serverstart zwingend erforderlich.

Sollte Nginx vor Node verwendet werden?

Ja, in der Praxis: Nginx verwaltet TLS-Verschlüsselung, HTTP/2, statische Dateien und Ratenbegrenzung. Node.js lauscht lokal an einem internen Port, Nginx leitet öffentlichen Datenverkehr dorthin weiter.

Wie erfolgt die Bereitstellung ohne Dienstunterbrechung?

Verwenden Sie PM2-Neuladen, eine Blau-Grün-Bereitstellung oder zwei Instanzen hinter einem Load Balancer. Erstellen Sie immer mit „npm ci“ in kontinuierlicher Integration, niemals manuell auf dem Produktionsserver.


Node.js in der Produktion ist keine hochgeladene Datei – es ist ein Prozess, den jemand am Leben erhalten muss.

Europäische Hoster vergleichen

Filtern nach Compliance, Standort und Einsatzzweck — dann die Datenblätter öffnen, um den echten Umfang zu prüfen.

Verzeichnis durchsuchen
Blog

Weiterlesen

Alle Artikel →