Nodejs Deployment auf Linux: Node.js installieren und live schalten

Was ist ein Nodejs Deployment auf einem Linux Server?

Ein Nodejs Deployment bedeutet, die Node.js Laufzeitumgebung auf einem Linux Server zu installieren und Ihre Anwendung aus dem Internet erreichbar zu machen. Konkret installieren Sie Node.js, holen den Code, legen Umgebungsvariablen fest, schalten Nginx davor und lassen systemd die Anwendung dauerhaft laufen.

Zudem richtet sich diese Anleitung an Website Betreiber und Entwickler, die einen eigenen VPS verwalten. Wenn Sie die Befehle der Reihe nach ausführen, läuft also am Ende eine einfache Node.js Anwendung hinter Ihrer Domain. Verwaltet Ihr Hoster den Server, wissen Sie danach, welche Fragen Sie ihm stellen sollten.

Wir sind ein Team für digitales Marketing und Webentwicklung, kein Hosting Unternehmen. Daher stützt sich die Anleitung auf die offizielle Dokumentation von Node.js, Nginx und systemd. In allen Beispielen stehen nur example.com und IP Adressen aus den Dokumentationsblöcken. Mischen Sie daher Ihre echten Adressen und Passwörter nie in Beispieldateien.

Außerdem wiederholen wir verwandte Themen hier nicht. PM2 als Prozessmanager bekommt einen eigenen Artikel, ebenso das Deployment einer Next.js Anwendung auf einen VPS. Dieser Artikel behandelt nur eine schlichte Node.js Anwendung.

Was sollten Sie vor dem Nodejs Deployment vorbereiten?

Zunächst brauchen Sie einen Linux Server mit Internetzugang, SSH Zugang und einem Benutzer mit sudo Rechten. Außerdem muss ein A Record Ihrer Domain auf die IP Adresse des Servers zeigen. Ohne ihn können Sie die Schritte für Nginx und TLS also nicht testen.

Ob die DNS Änderung schon angekommen ist, prüfen Sie mit unserem DNS Abfrage Tool. Zudem bestätigt die IP Abfrage die Serveradresse.

Konkret sieht die Checkliste für die Vorbereitung so aus:

• Melden Sie sich mit einem SSH Schlüssel statt mit einem Passwort an.
• Legen Sie für die Anwendung einen eigenen Systembenutzer ohne Root Rechte an.
• Aktualisieren Sie die Paketliste und spielen Sie Sicherheitsupdates ein.
• Richten Sie den A Record der Domain auf die Server IP aus.
• Lassen Sie in der Firewall nur SSH, 80 und 443 offen.

Öffnen Sie den Port der Anwendung, zum Beispiel 3000, nicht nach außen. Die Anwendung lauscht nur auf der lokalen Adresse, und Nginx nimmt den öffentlichen Verkehr an. Die Gründe erklären wir daher weiter unten.

Welche Installationsmethode für Node.js passt: Distributionspaket, NodeSource oder nvm?

Es gibt drei verbreitete Wege, und jeder hat einen anderen Kompromiss. Das Distributionspaket ist am einfachsten, allerdings folgt seine Version dem Zeitplan der Distribution. Das NodeSource Repository liefert dagegen eine neuere Hauptversion. Mit nvm hingegen halten Sie mehrere Versionen pro Benutzer bereit.

Auf einem Produktionsserver mit nur einer Anwendung empfehlen wir den Weg über den Paketmanager, denn Updates kommen zusammen mit dem restlichen System. Zudem vermeiden Sie Pfadprobleme in der systemd Unit. Verwalten Sie dagegen viele Projekte und Versionen, ist nvm bequemer.

Welche Node.js Version sollten Sie in der Produktion einsetzen?

Setzen Sie in der Produktion nur eine Active LTS oder Maintenance LTS Version ein. Die offizielle Seite zu den Node.js Release Status sagt es klar: Produktive Anwendungen sollen nur LTS Versionen nutzen. Die Current Linie ist dafür da, dass Bibliotheksautoren neue Funktionen testen.

Laut dieser Seite dauert die Current Phase sechs Monate, und LTS garantiert insgesamt 30 Monate lang Korrekturen für kritische Fehler. Versionsnummern ändern sich oft, deshalb schreiben wir hier keine feste Nummer. Prüfen Sie daher die aktuelle LTS Nummer immer auf dieser Seite.

Zwei praktische Regeln helfen bei der Entscheidung:

• Tragen Sie die unterstützte Version im Feld engines Ihrer package.json ein.
• Bleiben Sie nicht auf einer Version, deren Support abgelaufen ist, denn sie bekommt keine Sicherheitskorrekturen.
• Testen Sie jedes Upgrade zuerst auf einer Kopie und installieren Sie danach die Abhängigkeiten neu.

Somit bleiben Entwicklung und Produktion auf derselben Hauptversion. Außerdem enden viele "bei mir lief es noch" Probleme genau dort.

Wie installieren Sie Node.js aus dem Distributionspaket?

Auf einem Debian basierten System genügen dann zwei Befehle. Zuerst aktualisieren Sie die Paketliste, dann installieren Sie die Pakete nodejs und npm. Danach bestätigen Sie die Versionen auf der Kommandozeile.

sudo apt update
sudo apt install nodejs npm
node --version
npm --version

Die Version im Distributionspaket ist nicht unbedingt eine LTS Version. Vergleichen Sie also die Ausgabe mit der offiziellen Release Seite. Zeigt sie eine alte Hauptversion, denken Sie stattdessen über NodeSource oder nvm nach.

Die RHEL Familie nutzt einen anderen Paketmanager, die Logik bleibt aber gleich. Lesen Sie die Dokumentation Ihrer Distribution und prüfen Sie dort, welches Modul oder Paket Node.js enthält. Deshalb erfinden wir für diese Systeme hier keine Befehle.

Wie installieren Sie Node.js mit dem NodeSource Repository?

NodeSource ist ein Repository eines Drittanbieters, das die gewünschte Hauptversion als Paket anbietet. Zunächst trägt ein Setup Skript dieses Repository in Ihren Paketmanager ein. Danach installieren Sie Node.js wie gewohnt mit apt oder dnf.

Holen Sie Skriptadresse und Befehle von der Seite von NodeSource selbst. Wir drucken hier keinen festen Befehl ab, weil sich Skriptadresse und Versionsauswahl mit der Zeit ändern. Zum Beispiel kann ein Befehl aus einem alten Blogartikel heute eine andere Version installieren.

Leiten Sie Skripte nicht direkt in eine Shell. Laden Sie stattdessen die Datei herunter, lesen Sie sie und führen Sie sie dann aus. Diese Gewohnheit gilt zudem für jedes Installationsskript, nicht nur für NodeSource.

Sobald das Repository eingetragen ist, kommen Updates über den Paketmanager. Außerdem steigen Sie bewusst um, weil ein Wechsel der Hauptversion eine Änderung am Repository verlangt. Somit vermeiden Sie überraschende Upgrades.

Wie installieren Sie Node.js mit nvm und was gilt für Dienste?

nvm verwaltet Node.js Versionen in Ihrem Home Verzeichnis. Die offizielle README empfiehlt, das Installationsskript von einer Adresse mit Versionsnummer zu laden. Zum Zeitpunkt dieses Artikels stand dort v0.40.8, prüfen Sie die aktuelle Nummer aber im Repository.

curl -o install-nvm.sh https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.8/install.sh
less install-nvm.sh
bash install-nvm.sh
nvm install --lts
nvm alias default node

Das Skript erst zu speichern und mit less zu lesen, ist sicherer als ein blindes Ausführen. Öffnen Sie nach der Installation zunächst eine neue Sitzung oder laden Sie die Shell neu. Sonst finden Sie den Befehl nvm nicht.

Ein Punkt ist entscheidend. Laut der nvm README ist nvm eine eingebundene Shell Funktion und keine ausführbare Datei. Dienste und systemd laden Ihre Profildateien nämlich nicht automatisch. Daher müssen Sie den vollen Pfad von node in die systemd Unit schreiben.

Legen Sie eine Datei .nvmrc in das Projektverzeichnis, liest nvm use die Version daraus. In der Produktion bevorzugen Sie deshalb einen festen Pfad statt häufigen Wechselns. Diese Beständigkeit spart außerdem Zeit, wenn das Team wächst.

Wie bringen Sie den Anwendungscode auf den Server?

Für jedes Nodejs Deployment holen Sie den Code am saubersten aus einem Git Repository. Dateien von Hand zu kopieren führt zu Fehlern, denn Sie sehen nicht, welche Version auf dem Server läuft. Mit Git hat jede Auslieferung eine Commit ID, und ein Rollback wird einfach.

Die Befehle finden Sie in unserer Git und GitHub Anleitung. Nutzen Sie dagegen auf dem Server einen Deploy Key mit reinem Lesezugriff. Legen Sie den Schlüssel Ihres persönlichen Kontos nicht auf der Maschine ab.

sudo useradd --system --create-home --home-dir /srv/nodeapp --shell /usr/sbin/nologin nodeapp
sudo -u nodeapp git clone https://git.example.com/team/nodeapp.git /srv/nodeapp/current
cd /srv/nodeapp/current
sudo -u nodeapp npm ci --omit=dev

Wir wählen npm ci aus gutem Grund. Der Node.js Sicherheitsleitfaden empfiehlt es statt npm install, um die Lockfile durchzusetzen. Das heißt, der Befehl installiert genau die Versionen aus der Lockfile.

Braucht Ihr Projekt einen Build Schritt, etwa bei TypeScript, führen Sie den Build bei der Auslieferung aus. Allerdings benötigen manche Projekte dafür ihre Entwicklungsabhängigkeiten. Installieren Sie dann zuerst alles, bauen Sie und behalten Sie danach nur die Produktionsabhängigkeiten.

Wie verwalten Sie die .env Datei und die Umgebungsvariablen?

Beim Nodejs Deployment halten Umgebungsvariablen Geheimnisse wie Passwörter und API Schlüssel aus dem Code heraus. Committen Sie diese Werte daher nie in das Git Repository. Ein Schlüssel, der im Repository landet, bleibt in der Historie, auch wenn Sie ihn später löschen. Tragen Sie daher die Zeile .env in Ihre .gitignore ein.

Node.js kann eine solche Datei zudem ohne zusätzliches Paket lesen. Laut der offiziellen CLI Dokumentation kam die Option --env-file mit v20.6.0 und hat in neueren Versionen ihr experimentelles Label verloren. Existiert dieselbe Variable in der Umgebung und in der Datei, gewinnt der Wert aus der Umgebung.

PORT=3000
NODE_ENV=production
DATABASE_URL=postgres://appuser:PASSWORT@127.0.0.1:5432/appdb

In der Produktion ist allerdings die systemd Einstellung EnvironmentFile oft praktischer. Sie legen die Datei außerhalb des Code Verzeichnisses ab, zum Beispiel unter /etc/nodeapp/nodeapp.env. systemd liest sie, bevor es zum Dienstbenutzer wechselt. Deshalb darf die Datei root gehören und die Rechte 600 haben.

Halten Sie das Format einfach: ein Paar SCHLUESSEL=wert pro Zeile. PASSWORT im Beispiel ist ein Platzhalter. Kopieren Sie also nie einen echten Wert aus diesem Artikel, einem Screenshot oder einem Chat.

Wie starten Sie die Anwendung zum ersten Mal von Hand?

Bevor Sie beim Nodejs Deployment den Dienst anlegen, starten Sie die Anwendung von Hand und prüfen, ob sie läuft. Geht etwas schief, sehen Sie den Fehler dann direkt im Terminal und nicht hinter systemd. Der kleine Server unten reicht für einen Test.

const http = require('node:http');
const port = process.env.PORT || 3000;
const server = http.createServer(function (req, res) {
  res.writeHead(200, { 'Content-Type': 'text/plain; charset=utf-8' });
  res.end('Anwendung laeuft\n');
});
server.listen(port, '127.0.0.1');

Beachten Sie, dass der Aufruf listen die Adresse 127.0.0.1 nutzt. Somit antwortet die Anwendung nur von innerhalb des Servers. Niemand verbindet sich direkt von außen, denn der Verkehr läuft über Nginx.

Starten Sie die Anwendung, öffnen Sie dann ein zweites Terminal und führen Sie curl -i http://127.0.0.1:3000/ aus. Sehen Sie dann den Status 200 und den Text, ist die Anwendung bereit. Beenden Sie sie danach mit Strg+C.

Warum sollten Sie Node.js nicht direkt auf den Ports 80 und 443 betreiben?

Ports unter 1024 brauchen zusätzliche Rechte, und die Anwendung als root zu starten, ist ein großes Risiko. Außerdem erledigt Nginx TLS, Kompression, statische Dateien und Anfragelimits deutlich reifer. Somit kann sich Ihre Anwendung auf die Geschäftslogik konzentrieren.

Auch der Node.js Sicherheitsleitfaden geht in dieselbe Richtung, denn er empfiehlt eine klare Trennung. Gegen Denial of Service Angriffe auf den HTTP Server rät er zu einem Reverse Proxy, der Anfragen annimmt und weiterleitet. Derselbe Abschnitt betont passende Server Timeouts wie headersTimeout und requestTimeout. Quelle: Node.js Security Best Practices.

Kurz gesagt sieht die Architektur so aus:

• Nginx lauscht auf den Ports 80 und 443 und beendet die TLS Verbindung.
• Die Node.js Anwendung lauscht auf einer lokalen Adresse, zum Beispiel Port 3000.
• systemd startet die Anwendung als Benutzer ohne Root Rechte und startet sie nach einem Absturz neu.

Für das größere Sicherheitsbild lesen Sie unseren Artikel zu den OWASP Top 10. Wer die Serverseite besser verstehen will, startet mit was ist ein Backend.

Wie schalten Sie Nginx als Reverse Proxy vor die Node.js Anwendung?

Sie öffnen in Nginx einen Server Block und leiten Anfragen an die lokale Adresse der Anwendung weiter. Auf Debian basierten Systemen liegen die Konfigurationsdateien meist unter sites-available. Andere Distributionen nutzen dagegen oft den Ordner conf.d. Prüfen Sie daher das Layout Ihrer eigenen Distribution.

server {
    listen 80;
    server_name example.com www.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Nach dem Speichern testen Sie zuerst die Syntax und laden dann neu. Eine fehlerhafte Datei kann nämlich eine laufende Website lahmlegen. Überspringen Sie den Schritt nginx -t deshalb nie.

sudo nginx -t
sudo systemctl reload nginx

Laut der Nginx Dokumentation legt die Direktive proxy_pass Protokoll und Adresse des Zielservers fest. Hängen Sie an die Adresse einen URI an, ersetzt er den passenden Teil der Location. Lassen Sie ihn dagegen weg, gibt Nginx den normalisierten Anfrage URI unverändert weiter. Quelle: ngx_http_proxy_module.

Für HTTPS tragen Sie dann das Zertifikat in Nginx ein. Was ein Zertifikat ist, haben wir im Artikel SSL Zertifikat und HTTPS erklärt. Danach prüfen Sie die Kette mit dem SSL Check.

Welche Nginx Header und Timeouts sind besonders wichtig?

Achten Sie zunächst auf drei Dinge: den Host Header, die Client IP und die Timeouts. Laut der Nginx Dokumentation hat Host standardmäßig den Wert $proxy_host. Braucht Ihre Anwendung die ursprüngliche Domain, müssen Sie $host ausdrücklich weitergeben.

Zweitens geht es um die Client IP. Hinter einem Proxy sieht die Anwendung nämlich als Aufrufer immer 127.0.0.1. Die Header X-Forwarded-For und X-Forwarded-Proto tragen die echten Angaben. Ihr Framework braucht eventuell eine Proxy Einstellung, um ihnen zu vertrauen. Zum Beispiel bietet Express dafür die Einstellung trust proxy.

Hat Ihre Anwendung lange Anfragen oder nutzt WebSockets, prüfen Sie proxy_read_timeout. Für WebSockets müssen Sie außerdem die Header Upgrade und Connection weitergeben. Weitere Details finden Sie auf der Nginx Seite zu WebSocket Proxying.

Wie hält ein systemd Dienst die Node.js Anwendung am Laufen?

systemd startet Ihre Anwendung im Hintergrund, startet sie nach einem Absturz neu und führt sie beim Hochfahren des Servers aus. Dafür schreiben Sie zunächst eine Unit Datei. Legen Sie sie unter /etc/systemd/system/nodeapp.service ab.

[Unit]
Description=Beispiel Node.js Anwendung
After=network.target

[Service]
Type=simple
User=nodeapp
Group=nodeapp
WorkingDirectory=/srv/nodeapp/current
EnvironmentFile=/etc/nodeapp/nodeapp.env
ExecStart=/usr/bin/node server.js
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Den Pfad in der Zeile ExecStart finden Sie auf Ihrem System mit command -v node. systemd verlangt den vollen Pfad. Haben Sie nvm genutzt, dann liegt der Pfad unter Ihrem Home Verzeichnis.

Laut der systemd Dokumentation ist Type=simple der Standard, und der Dienst gilt als gestartet, sobald der Hauptprozess forkt. Restart=on-failure startet bei einem Exit Code ungleich null neu. RestartSec legt die Pause vor dem Neustart fest. Quelle: Handbuch systemd.service.

sudo systemctl daemon-reload
sudo systemctl enable --now nodeapp
sudo systemctl status nodeapp
sudo journalctl -u nodeapp -f

Der letzte Befehl zeigt die Logs live. Startet die Anwendung nicht, schauen Sie also dort zuerst nach.

Wie härten Sie den systemd Dienst ab?

Mit wenigen Zeilen in der Unit Datei verengen Sie zudem die Rechte der Anwendung. Das Handbuch systemd.exec beschreibt diese Zeilen. Jede verkleinert die Angriffsfläche, aber strenge Einstellungen können auch Schreibzugriffe blockieren. Fügen Sie also eine Zeile hinzu und testen Sie dann.

• NoNewPrivileges=true verhindert, dass Prozesse neue Rechte erwerben.
• PrivateTmp=true gibt dem Dienst eigene Verzeichnisse für /tmp und /var/tmp.
• ProtectSystem=strict macht das Dateisystem schreibgeschützt, nur Pfade aus ReadWritePaths= bleiben beschreibbar.

Schreibt Ihre Anwendung in einen Upload Ordner oder eine Logdatei, öffnen Sie diesen Pfad mit ReadWritePaths. Sonst meldet die Anwendung einen Berechtigungsfehler, und die Ursache ist auf den ersten Blick nicht klar.

Fügen Sie die Einstellungen einzeln hinzu und starten Sie nach jeder neu. Prüfen Sie dann das Log. Diese Methode wirkt zwar langsam. Dennoch finden Sie so schnell die Zeile, die ein Problem auslöst.

Sollten Sie die Node.js Anwendung stattdessen mit Docker ausliefern?

Docker ist ein Weg, eine Anwendung samt Abhängigkeiten in einem Paket auszuführen. Die Methode in diesem Artikel startet dagegen die Anwendung direkt auf dem Server. Beides ist richtig, allerdings passt es nicht zu jedem Team. Die Wahl hängt von den Gewohnheiten Ihres Teams und der Größe Ihrer Infrastruktur ab.

Für eine kleine Anwendung reicht ein schlichtes Nodejs Deployment mit systemd oft aus. Betreiben Sie mehrere Dienste oder wollen Sie exakt dieselbe Umgebung wie lokal, ist Docker sinnvoll. Die Grundlagen zu Containern haben wir zudem im Docker Leitfaden erklärt.

Wie behalten Sie Abhängigkeiten und Firewall im Griff?

Zwei Gewohnheiten schützen Sie am meisten: Abhängigkeiten prüfen und offene Ports klein halten. Der Node.js Sicherheitsleitfaden empfiehlt Lockfiles und automatisierte Schwachstellenprüfungen mit npm audit im CI Prozess.

Außerdem behandelt der Leitfaden schädliche Module von Drittanbietern. Er rät deshalb dazu, genaue Versionen festzulegen. Das heißt, Sie nutzen exakte Versionen und eine Lockfile statt loser Bereiche. So installiert jede Auslieferung denselben Abhängigkeitsbaum.

In der Firewall lassen Sie nur die nötigen Ports offen:

• Den SSH Port für die Verwaltung, am besten nur für bekannte Adressen.
• Die Ports 80 und 443 für HTTP und HTTPS.
• Der Anwendungsport bleibt dagegen geschlossen, in unserem Beispiel 3000.

Das Firewall Werkzeug unterscheidet sich außerdem je nach Distribution. Folgen Sie der Dokumentation Ihres Systems und stellen Sie sicher, dass Ihre SSH Sitzung bestehen bleibt, bevor Sie Regeln anwenden. Eine falsche Regel kann Sie nämlich an diesem Schritt vom Server aussperren.

Wie liefern Sie eine neue Version auf den Server aus?

Der Ablauf eines Nodejs Deployments ist kurz: Code holen, Abhängigkeiten installieren, bei Bedarf bauen und den Dienst neu starten. Fassen Sie diese Schritte in einem kleinen Skript zusammen, sinkt die Fehlerquote. Zudem läuft jede Auslieferung in derselben Reihenfolge.

cd /srv/nodeapp/current
sudo -u nodeapp git pull --ff-only
sudo -u nodeapp npm ci --omit=dev
sudo systemctl restart nodeapp
sudo systemctl status nodeapp

Ein Neustart verursacht eine kurze Unterbrechung. Für kleine Websites ist das allerdings oft akzeptabel. Brauchen Sie einen Wechsel ohne Ausfallzeit, benötigen Sie einen Prozessmanager oder mehrere Kopien der Anwendung. Diesen Ansatz behandeln wir im PM2 Artikel.

Bereiten Sie daher auch einen Rollback Plan vor. Markieren Sie zum Beispiel jede Auslieferung mit einem Tag. Geht etwas schief, kehren Sie zum vorigen Tag zurück und starten den Dienst neu. Bei Änderungen am Datenbankschema ist der Rollback allerdings schwieriger. Erstellen Sie dann vorher Backups.

Für die Backup Routine lesen Sie unsere Website Backup Strategie.

Wie beobachten Sie Logs und Ressourcenverbrauch?

systemd schreibt die Ausgabe des Dienstes in das Journal. Sie brauchen also keine eigene Logdatei. Der Befehl journalctl -u nodeapp --since "1 hour ago" zeigt die letzte Stunde. So sehen Sie, wann der Fehler begann.

Speicherlecks sind nach jedem Nodejs Deployment ein häufiges Problem, weil Node.js Prozesse lange laufen. Der Dienst belegt mit der Zeit mehr Speicher und stürzt schließlich ab. Restart=on-failure verdeckt das eine Weile, behebt die Ursache aber nicht. Daher sollten Sie auch die Zahl der Neustarts beobachten.

Für ein einfaches Monitoring richten Sie eine externe Erreichbarkeitsprüfung ein. Ein Dienst, der Ihre Adresse in festen Abständen abfragt und Sie warnt, wenn keine Antwort kommt, genügt schon. Eine Prüfung von innen warnt Sie dagegen nicht, wenn der ganze Server ausfällt.

Was prüfen Sie nach dem Nodejs Deployment?

Zunächst bestätigen Sie, dass der Dienst läuft. Dann prüfen Sie, ob er von außen antwortet. Danach suchen Sie in den Logs nach Fehlern. Schließlich messen Sie Geschwindigkeit und Sicherheit. Diese vier Prüfungen fangen die meisten Überraschungen nach einer Auslieferung ab.

• systemctl status nodeapp zeigt, dass der Dienst läuft.
• curl -I https://example.com/ liefert die Antwort von außen samt Headern.
• journalctl -u nodeapp listet die Logs der Anwendung auf.
• Prüfen Sie zudem die Zertifikatskette mit dem SSL Tool und den DNS Eintrag mit dem DNS Tool.

Für die Performance empfehlen wir einen Google Lighthouse Test. Wie sich die Ergebnisse auf die Sichtbarkeit auswirken, haben wir im Artikel wie die Ladezeit das SEO beeinflusst erklärt.

Liest Ihre Anwendung oft dieselben Daten, hilft zudem ein Cache. Den Unterschied zwischen Redis und Memcached finden Sie in unserem Artikel Caching erklärt.

Welche Fehler treten bei Node.js Deployments am häufigsten auf?

Am häufigsten sind abweichende Ports, Berechtigungsprobleme und fehlende Umgebungsvariablen. Die meisten zeigen sich daher im Browser als 502 Bad Gateway. Dieser Fehler bedeutet, dass Nginx die Anwendung nicht erreicht. Die Ursache ist meist, dass die Anwendung nicht läuft oder auf einem anderen Port lauscht.

Lesen Sie beim Debuggen zuerst das Log. Raten Sie nicht, sondern lesen Sie die Ausgabe von journalctl. Oft steht die Antwort nämlich in den letzten Zeilen. Kommen Sie damit nicht weiter, stoppen Sie den Dienst und starten die Anwendung von Hand, um das Problem auf eine Variable einzugrenzen.

Wann sollten Sie das Nodejs Deployment nicht selbst übernehmen?

Überlassen Sie die Arbeit Ihrem Hoster bei einer Datenbankänderung im Livebetrieb ohne Backup, bei einem Server unter Angriff oder bei einem Shop mit Zahlungen. Serverbetrieb braucht außerdem ständige Pflege. Fehlt Ihnen die Zeit für Updates, Monitoring und Störungsbehebung, ist ein verwalteter Dienst sicherer.

Wir sind kein Hosting Unternehmen, deshalb enthält dieser Artikel keine Betriebsbehauptungen. Er stützt sich stattdessen auf offizielle Dokumentation. Betreiben Sie eine geschäftskritische Anwendung, verlangen Sie von Ihrem Anbieter schriftlich Backups, Monitoring und Supportzeiten.

In diesen Fällen wenden Sie sich an einen Anbieter oder eine verwaltete Plattform:

• Bei Ihnen kann niemand jede Woche Sicherheitspatches einspielen.
• Ein Ausfall bedeutet also direkten Umsatzverlust.
• Sie verarbeiten personenbezogene Daten oder Zahlungsdaten und haben Compliance Pflichten.

Zur Wahl des Hostings lesen Sie unseren Leitfaden zur Auswahl von Webhosting. Möchten Sie die Anwendung selbst entwickeln oder übernehmen lassen, hilft unsere individuelle Softwareentwicklung.

Fazit: Eine kurze Checkliste für das Nodejs Deployment

Zusammengefasst sieht der Ablauf so aus: LTS Version installieren, Code per Git holen, Geheimnisse aus dem Code heraushalten, die Anwendung nur lokal lauschen lassen und den öffentlichen Verkehr Nginx überlassen. Für Dauerbetrieb nutzen Sie systemd und prüfen nach jeder Auslieferung die Logs.

• Gibt es auf dem Server einen Dienstbenutzer ohne Root Rechte?
• Ist die Node.js Version Active oder Maintenance LTS?
• Liegen die Geheimnisse außerhalb von Git in einer Datei mit Rechten 600?
• Lauscht die Anwendung auf 127.0.0.1?
• Läuft nginx -t ohne Fehler durch?
• Startet der Dienst nach einem Neustart von selbst?

Wiederholen Sie daher diese Liste bei jedem neuen Projekt. Mit der Wiederholung wird der Ablauf also zur Routine.