Node.js Hosting: der passende Platz für Ihre JavaScript-App

Node.js Hosting funktioniert anders als klassisches Webhosting mit PHP. Eine Node-App ist ein Programm, das dauerhaft läuft und auf Anfragen wartet, während ein PHP-Skript nur für die Dauer eines Aufrufs startet. Deshalb können viele günstige Webhosting-Tarife Node.js gar nicht oder nur eingeschränkt. Welcher Weg für Sie passt, hängt vor allem davon ab, ob Ihre App zur Laufzeit wirklich einen Node-Server braucht. Bei vielen modernen Websites ist das gar nicht der Fall.

Braucht Ihre Seite überhaupt Node.js Hosting?

Viele Projekte nutzen Node.js nur beim Bauen. Ein Static Site Generator wie Astro, Eleventy oder Hugo, aber auch React, Vue oder Svelte im reinen Browser-Modus erzeugen am Ende fertige HTML-, CSS- und JavaScript-Dateien. Diese Dateien laden Sie auf jeden normalen Webspace hoch. Node.js läuft dabei nur auf Ihrem Rechner oder in der Build-Pipeline, nicht auf dem Server.

Einen laufenden Node-Prozess brauchen Sie erst, wenn der Server bei jeder Anfrage etwas berechnet: eine API mit Express oder Fastify, Server-Side Rendering mit Next.js oder Nuxt, Websockets für einen Chat oder ein Bot, der rund um die Uhr läuft.

Prüfen Sie das vor der Wahl des Tarifs. Wer eine Next.js-Seite als statischen Export bauen kann, spart sich den ganzen Aufwand und nutzt einfach Webspace mit HTTPS.

Node.js Hosting ohne Serverkenntnisse

Sie müssen keinen eigenen Server verwalten, um eine Node-App online zu bringen. Viele Webhoster mit cPanel oder Plesk bieten im Kundenmenü einen Punkt wie „Node.js“ oder „Setup Node.js App“. Dort wählen Sie die Node-Version, geben den Ordner der App und die Startdatei an, etwa server.js, und klicken auf Starten. Den Neustart nach einem Absturz und die Weiterleitung der Domain auf die App übernimmt der Anbieter.

Fragen Sie vor der Buchung beim Support nach, ob der Tarif Node.js unterstützt und wie viel Arbeitsspeicher eine App nutzen darf. Für eine kleine Vereins- oder Projektseite reicht dieser Weg fast immer. Erst wenn Sie mehrere Apps, Datenbanken oder eigene Dienste brauchen, lohnt sich der vServer mit eigener Einrichtung, wie sie weiter unten beschrieben ist.

Die drei Wege für Node.js Hosting

Für eine App, die zur Laufzeit Node.js braucht, gibt es drei typische Wege. Sie unterscheiden sich vor allem darin, wie viel Sie selbst verwalten.

Webhosting mit Node.js-Unterstützung. Einige Anbieter bieten Node.js im Kundenmenü an, etwa über die Node.js-Erweiterung von Plesk oder die Funktion „Setup Node.js App“ in cPanel. Sie geben den Startpunkt der App an, wählen eine Version und der Server startet den Prozess bei Bedarf. Das ist bequem, hat aber Grenzen beim Arbeitsspeicher, bei der Zahl der Prozesse und oft bei Websockets. Lesen Sie die Tarifbeschreibung genau oder fragen Sie den Support. Steht dort nur „Node.js Hosting möglich“ ohne Angaben zu Speicher und Prozessen, ist das zu wenig.

vServer. Auf einem eigenen virtuellen Server haben Sie volle Kontrolle. Sie installieren Node.js selbst, starten die App als Dienst und setzen einen Webserver davor. Dafür kümmern Sie sich um Updates, Firewall und Backups.

Plattform als Dienst. Anbieter von Plattformen nehmen Ihren Code aus einem Git-Repository, bauen ihn und betreiben die App. Skalierung und Zertifikate laufen automatisch. Das ist der schnellste Weg, kostet bei wachsender Last aber oft deutlich mehr und viele Plattformen haben ihren Sitz in den USA. Für personenbezogene Daten müssen Sie dann die Fragen klären, die der Ratgeber zum DSGVO-konformen Hosting beschreibt.

Die richtige Node-Version

Egal welches Node.js Hosting Sie wählen, die Version entscheidet über Sicherheit und Kompatibilität. Node.js erscheint zweimal im Jahr in einer neuen Hauptversion. Versionen mit gerader Nummer werden zu Long Term Support, kurz LTS, und bekommen rund 30 Monate lang Sicherheitsupdates. Für den Betrieb nehmen Sie immer eine LTS-Version, ungerade Versionen sind nur für Tests gedacht. Welche Versionen gerade unterstützt werden und wann ihr Support endet, zeigt der Release-Plan von Node.js.

Halten Sie die Version im Projekt fest, zum Beispiel im Feld engines der package.json oder in einer Datei .nvmrc. Dann läuft auf Ihrem Rechner und auf dem Server dieselbe Version, und ein Update planen Sie bewusst statt zufällig.

Node.js Hosting auf dem vServer einrichten

Auf einem vServer mit Debian oder Ubuntu sieht ein schlanker, sicherer Aufbau so aus: Node.js aus einer aktuellen Quelle, die App unter einem eigenen Benutzer ohne Root-Rechte, systemd als Wächter und Nginx als Reverse Proxy für HTTPS. Wie Sie den Server vorher einrichten und absichern, zeigt der Leitfaden vServer für Einsteiger.

1. Node.js installieren. Die Pakete in Debian sind oft älter. Aktuelle LTS-Versionen bekommen Sie über die Paketquelle von NodeSource. Das Einrichtungsskript fügt die Quelle hinzu, danach installieren Sie wie gewohnt mit apt. Ersetzen Sie die Zahl durch die LTS-Version, die Sie nutzen wollen:

curl -fsSL https://deb.nodesource.com/setup_24.x -o nodesource_setup.sh
less nodesource_setup.sh   # vor dem Ausführen ansehen
sudo bash nodesource_setup.sh
sudo apt install nodejs
node -v

Alternativ installiert der Versionsmanager nvm Node.js pro Benutzer, was praktisch ist, wenn mehrere Apps verschiedene Versionen brauchen. Für einen Dienst unter systemd müssen Sie dann aber den vollen Pfad zur Node-Version angeben.

Zum Ausprobieren reicht eine winzige App. Legen Sie eine Datei server.js an:

const http = require('node:http');
const port = process.env.PORT || 3000;
http.createServer((req, res) => {
  res.end('Hallo vom vServer');
}).listen(port, '127.0.0.1');

Mit node server.js startet sie, und curl http://127.0.0.1:3000 zeigt die Antwort. Genau so wird später jede echte App gestartet, nur mit mehr Code.

2. Eigener Benutzer und Code. Legen Sie einen Benutzer an, etwa mit sudo adduser --system --group nodeapp, und legen Sie den Code nach /srv/meine-app. Installieren Sie die Abhängigkeiten mit npm ci --omit=dev. Der Befehl hält sich genau an die package-lock.json und lässt Werkzeuge weg, die nur für die Entwicklung gebraucht werden.

3. Als Dienst starten. Eine Datei /etc/systemd/system/meine-app.service sorgt dafür, dass die App beim Booten startet und nach einem Absturz neu anläuft:

[Unit]
Description=Meine Node-App
After=network.target

[Service]
User=nodeapp
WorkingDirectory=/srv/meine-app
Environment=NODE_ENV=production
Environment=PORT=3000
EnvironmentFile=/etc/meine-app.env
ExecStart=/usr/bin/node server.js
Restart=on-failure
NoNewPrivileges=true
ProtectSystem=strict
ReadWritePaths=/srv/meine-app/uploads
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Mit sudo systemctl enable --now meine-app starten Sie den Dienst, mit journalctl -u meine-app -f lesen Sie seine Ausgaben. Passwörter und Schlüssel stehen in der Datei /etc/meine-app.env, die nur Root lesen darf, und nicht im Code. Die Zeilen ab NoNewPrivileges schränken die App ein: Sie darf sich keine zusätzlichen Rechte verschaffen und nur in den Ordner uploads schreiben. Braucht Ihre App weitere Ordner zum Schreiben, ergänzen Sie diese bei ReadWritePaths. Wer lieber mit PM2 arbeitet, bekommt ähnliche Funktionen, braucht aber ein zusätzliches Werkzeug. Für eine einzelne App reicht systemd.

4. Nginx als Reverse Proxy. Die App lauscht nur auf 127.0.0.1:3000, von außen ist sie nicht direkt erreichbar. Nginx nimmt die Anfragen auf Port 443 an und reicht sie weiter:

server {
    listen 443 ssl;
    server_name app.beispiel.de;
    # Zertifikat: siehe Let's Encrypt

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Die letzten drei Zeilen braucht es nur für Websockets. Das Zertifikat holen Sie mit Certbot, wie im Ratgeber zu Let's Encrypt beschrieben. Achten Sie darauf, dass Port 3000 in der Firewall geschlossen bleibt.

Updates und Deployment

Ein neues Release spielen Sie am einfachsten so ein: Code holen, Abhängigkeiten installieren, bauen, Dienst neu starten.

cd /srv/meine-app
git pull
npm ci --omit=dev
npm run build
sudo systemctl restart meine-app

Während des Neustarts ist die App ein bis zwei Sekunden weg. Für die meisten Projekte ist das in Ordnung. Wer keinen einzigen Aufruf verlieren will, betreibt zwei Instanzen hinter Nginx und startet sie nacheinander neu. Vergessen Sie neben der App das System selbst nicht. Node.js, Nginx und das Betriebssystem brauchen ebenfalls regelmäßig Sicherheitsupdates.

Prüfen Sie die Abhängigkeiten mit npm audit auf bekannte Lücken. Ein Node-Projekt bringt schnell Hunderte Pakete mit, und nicht jedes wird gut gepflegt.

Arbeitsspeicher und Leistung

Beim Node.js Hosting ist der Arbeitsspeicher meist knapper als die Rechenleistung. Eine kleine Express-API kommt mit 100 bis 200 MB Arbeitsspeicher aus. Next.js mit Server-Side Rendering braucht im Betrieb eher 300 bis 600 MB, beim Bauen kurzzeitig deutlich mehr. Auf einem vServer mit 2 GB laufen deshalb zwei, drei kleine Apps mit einer Datenbank. Bauen Sie große Projekte lieber auf Ihrem Rechner oder in der CI und kopieren Sie nur das Ergebnis auf den Server.

Ein Node-Prozess nutzt nur einen Prozessorkern. Auf Servern mit mehreren Kernen können Sie mehrere Instanzen auf verschiedenen Ports starten und Nginx die Last verteilen lassen. Wann sich der Umstieg auf einen größeren Server lohnt, beschreibt der Ratgeber zur vServer-Skalierung.

Protokolle und Überwachung

Was Ihre App auf die Konsole schreibt, landet bei systemd im Journal. Mit journalctl -u meine-app --since today lesen Sie die Ausgaben des Tages, mit -p err nur die Fehler. Das Journal begrenzt seine Größe selbst, eine eigene Rotation brauchen Sie dafür nicht.

Geben Sie Ihrer App eine einfache Adresse wie /health, die nur „ok“ zurückgibt, wenn die App und ihre Datenbank erreichbar sind. Ein externer Uptime-Check ruft diese Adresse jede Minute ab und meldet einen Ausfall sofort. Wie Sie das einrichten, zeigt der Ratgeber zum Website-Monitoring. Startet systemd die App wegen eines Fehlers immer wieder neu, sehen Sie das am schnellsten mit systemctl status meine-app.

Checkliste für Ihr Node.js Hosting

• LTS-Version festgelegt und auf Server und Rechner gleich
• App läuft unter eigenem Benutzer, nicht als Root
• Port nur auf 127.0.0.1, davor Nginx mit HTTPS
• Geheimnisse in einer geschützten Datei, nicht im Repository
• Neustart nach Absturz und nach dem Booten getestet
• Protokolle lesbar und begrenzt
• Backup für Datenbank und hochgeladene Dateien
• Überwachung, die einen Ausfall meldet