VPS Deployment für Next.js: PM2, Nginx und SSL Schritt für Schritt

Wie funktioniert das VPS Deployment einer Next.js App?

Ein VPS Deployment für Next.js heißt: Sie bauen die App mit der Standalone Ausgabe, kopieren das Ergebnis auf den Server, starten den Node Prozess mit PM2, setzen Nginx als Reverse Proxy davor und aktivieren HTTPS mit Let's Encrypt. Diese fünf Schritte bilden das Grundgerüst eines Setups mit einem Server.

Wir haben diese Anleitung für Website Betreiber und Entwickler geschrieben, die ihren VPS selbst verwalten. Sie können die Befehle daher der Reihe nach ausführen. Außerdem erklären wir, warum jeder Schritt nötig ist, denn die meisten Probleme beim VPS Deployment entstehen durch eine falsche Annahme und nicht durch einen Tippfehler.

Wir sind ein Team für digitales Marketing und Webentwicklung, kein Hosting Anbieter. Deshalb stützt sich die Erklärung auf die offizielle Dokumentation von Next.js, PM2, Nginx und Certbot. Bei Befehlen oder Versionsnummern, bei denen wir nicht sicher waren, haben wir bewusst darauf verzichtet und schreiben stattdessen "aktuelle stabile Version".

Die Beispiele verwenden example.com als Domain und 203.0.113.10 als IP Adresse. Ersetzen Sie diese deshalb durch Ihre eigenen Werte. Schreiben Sie echte Passwörter, Schlüssel oder produktive Domains niemals in eine kopierte Datei oder in ein Repository.

VPS Deployment oder Vercel: Was passt zu Ihrem Projekt?

Das hängt von Ihrem Team und Ihrer Last ab, also von Ihren Rahmenbedingungen. Vercel ist die verwaltete Plattform des Unternehmens hinter Next.js und nimmt Ihnen die Serverwartung ab. Ein VPS gibt Ihnen volle Kontrolle, überlässt Ihnen aber auch Updates, Sicherheit, Backups und Monitoring.

Die Tabelle zeigt konkret die Kriterien, auf die es bei der Entscheidung ankommt. Preise haben wir nicht verglichen, weil sich Tarife oft ändern. Prüfen Sie die aktuellen Preise auf der Seite des jeweiligen Anbieters.

Kurz gesagt: Wenn Sie keine Zeit für Serverarbeit haben, ist eine verwaltete Plattform sicherer. Besitzen Sie bereits einen VPS oder wünschen Sie feste Kosten, ist der VPS dann sinnvoll. Hosting Optionen haben wir außerdem in unserem Leitfaden zur Frage Webhosting auswählen verglichen.

Welche Entscheidungen treffen Sie vor dem VPS Deployment?

Treffen Sie drei Entscheidungen, bevor Sie Ihr VPS Deployment starten. Erstens: Braucht Ihre App überhaupt einen Node Server? Zweitens: Wo bauen Sie? Drittens: Betreiben Sie einen Prozess oder mehrere?

Die Next.js Dokumentation beschreibt auch den statischen Export. Wenn alle Seiten schon beim Build entstehen können, liefern Sie die Ausgabe direkt über Nginx aus. Allerdings brauchen serverseitige Funktionen, Rendering zur Anfragezeit oder die Standard Bildoptimierung einen Node Server.

• Sind Ihre Seiten rein statisch, prüfen Sie den statischen Export; dann brauchen Sie weder einen Node Prozess noch PM2.
• Nutzen Sie dagegen Server Components, API Routen oder Daten zur Anfragezeit, betreiben Sie einen Node Server.
• Ein Build auf einem kleinen VPS kann den Arbeitsspeicher belasten; bauen Sie besser woanders und übertragen Sie nur die Ausgabe.
• Starten Sie mit einem Prozess, denn mehrere Prozesse brauchen zusätzliche Einstellungen für Cache und Schlüssel.

Der Ort des Builds ist zudem eine Sicherheitsentscheidung. Bauen Sie auf dem Server, landen Compiler und Entwicklungsabhängigkeiten auf der Produktionsmaschine. Bauen Sie dagegen woanders und übertragen nur den Standalone Ordner, bleibt der Server schlank. Diesen Weg empfehlen wir hier, und er macht das VPS Deployment auf kleinen Servern leichter.

Diese Anleitung behandelt also den häufigsten Fall, nämlich einen Node Server. Zudem folgen die Schritte dem Vorgehen aus der offiziellen Self Hosting Dokumentation von Next.js.

Wie bereiten Sie den VPS für Next.js vor?

Arbeiten Sie zunächst nicht mehr als root. Legen Sie einen Benutzer ohne Sonderrechte an, starten Sie die App mit ihm und melden Sie sich per SSH mit einem Schlüssel an. Die folgenden Befehle gehen von einer Debian basierten Distribution wie Ubuntu aus; bei anderen Distributionen weicht der Paketmanager ab.

sudo apt update
sudo apt upgrade
sudo adduser deploy
sudo usermod -aG sudo deploy
sudo apt install nginx ufw

Danach aktivieren Sie die Firewall. Geben Sie deshalb nach außen nur die Ports für SSH, HTTP und HTTPS frei. Der Next.js Prozess lauscht später auf Port 3000, aber das Internet darf diesen Port nie erreichen.

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable
sudo ufw status

Achtung: Fügen Sie die SSH Regel hinzu, bevor Sie die Firewall einschalten. Sonst sperren Sie sich selbst aus. Allgemeine Schwachstellen von Webanwendungen haben wir zum Beispiel im Beitrag zu den OWASP Top 10 Sicherheitslücken beschrieben.

Wie installieren Sie Node.js auf dem Server?

Es gibt nicht den einen richtigen Weg, Node.js zu installieren, denn die Lage ist je nach Server verschieden. Sie können das Paket Repository der Distribution, einen Versionsmanager wie nvm oder die offiziellen Paketquellen nutzen. Wählen Sie die Methode auf der Installationsseite von nodejs.org, denn Versionen und Repository Adressen ändern sich mit der Zeit.

Achten Sie bei der Version auf zwei Dinge. Erstens nennt die Installationsseite von Next.js die mindestens nötige Node Version. Außerdem sollten Sie in der Produktion die aktuelle stabile Linie (LTS) bevorzugen. So erhalten Sie also länger Sicherheitspatches.

Prüfen Sie nach der Installation die Version. Stellen Sie außerdem sicher, dass Entwicklungsrechner und Server dieselbe nutzen. Ein Versionsunterschied ist die häufigste Ursache für Fehler nach dem Muster "bei mir lief es".

node --version
npm --version

Wie erzeugen Sie die Standalone Ausgabe von Next.js?

Die Standalone Ausgabe bedeutet: Next.js verfolgt beim Build, welche Dateien die App braucht, und kopiert nur diese in einen eigenen Ordner. Laut offizieller Dokumentation liegt dieser Ordner unter .next/standalone und läuft allein, ohne dass Sie node_modules installieren.

Zum Aktivieren fügen Sie in der Datei next.config.js eine Einstellung hinzu.

module.exports = {
  output: 'standalone',
}

Nach dem Build kopiert Next.js die Ordner public und .next/static nicht von selbst. Die Dokumentation zeigt daher, wie Sie diese von Hand kopieren. Sonst lädt die Seite zwar, aber Bilder und Skripte liefern einen 404 Fehler.

npm ci
npm run build
cp -r public .next/standalone/
cp -r .next/static .next/standalone/.next/

Nutzen Sie ein Monorepo, brauchen Sie eine weitere Einstellung: outputFileTracingRoot. Sie legt fest, wo die Analyse beginnt, und das hilft konkret bei gemeinsamen Paketen. Dadurch landen auch gemeinsame Dateien außerhalb des Projektordners in der Ausgabe.

Wie starten Sie den Standalone Server von Hand?

Starten Sie den Server zuerst von Hand und testen Sie ihn, bevor Sie zu PM2 wechseln. So geben Sie dem Prozessmanager dann nicht die Schuld für einen einfachen App Fehler. Laut Dokumentation legen die Umgebungsvariablen PORT und HOSTNAME fest, auf welchem Port und welcher Adresse der Server lauscht.

cd .next/standalone
PORT=3000 HOSTNAME=127.0.0.1 node server.js

Wir haben hier 127.0.0.1 gewählt. Das heißt, nur der Server selbst erreicht den Prozess. Da Nginx später die einzige Tür nach außen sein wird, ist das aus Sicherheitssicht die sauberere Wahl.

Prüfen Sie danach die Antwort in einem zweiten Terminal. In der Kopfzeile sollten Sie den Statuscode 200 sehen.

curl -I http://127.0.0.1:3000

Läuft alles, beenden Sie den Prozess und wechseln zu PM2. Läuft etwas nicht, lesen Sie zunächst die Log Ausgabe. Eine fehlende Umgebungsvariable und eine falsche Node Version sind die zwei häufigsten Ursachen.

Wie verwalten Sie Umgebungsvariablen?

Next.js unterstützt Umgebungsvariablen zur Build Zeit und zur Laufzeit. Standardmäßig sieht also nur der Server sie. Damit eine Variable im Browser ankommt, muss ihr Name mit NEXT_PUBLIC_ beginnen, und Next.js schreibt diese Werte beim next build fest in das JavaScript Bundle.

Daraus folgt praktisch: Einen NEXT_PUBLIC_ Wert auf dem Server zu ändern und den Prozess neu zu starten, reicht nicht. Sie müssen daher neu bauen. Geheime Schlüssel dürfen niemals mit diesem Präfix beginnen, weil jeder sie im Browser lesen kann.

• Halten Sie Geheimnisse aus dem Repository heraus; speichern Sie sie auf dem Server in einer Datei, die nur der App Benutzer lesen darf.
• Nutzen Sie das Präfix NEXT_PUBLIC_ nur, wenn ein Wert wirklich im Browser ankommen muss.
• Starten Sie den Prozess nach jeder Änderung neu und testen Sie, ob der neue Wert ankommt.
• Fügen Sie keine echten Passwörter oder Schlüssel in Beispieldateien, Screenshots oder Chatnachrichten ein.

Laut Dokumentation wertet der Server Werte, die er beim dynamischen Rendering liest, zur Laufzeit aus. Somit können Sie eine Build Ausgabe in verschiedenen Umgebungen mit unterschiedlichen Werten betreiben.

Wie betreiben Sie Next.js mit PM2?

PM2 ist ein Prozessmanager, der Node Prozesse im Hintergrund ausführt, bei Abstürzen neu startet und Logs sammelt. Die Ecosystem Datei aus der offiziellen Dokumentation bündelt alle Einstellungen an einer Stelle. So tippen Sie nicht jedes Mal einen langen Befehl.

module.exports = {
  apps: [{
    name: 'site',
    script: 'server.js',
    cwd: '/var/www/example.com/current/.next/standalone',
    max_memory_restart: '500M',
    env_production: {
      NODE_ENV: 'production',
      PORT: 3000,
      HOSTNAME: '127.0.0.1'
    }
  }]
}

Der Wert bei max_memory_restart ist nur ein Beispiel; messen Sie den Speicherverbrauch Ihrer App und leiten Sie den Wert daraus ab. Laut Dokumentation startet PM2 den Prozess neu, sobald er den festgelegten Speicher überschreitet.

pm2 start ecosystem.config.js --env production
pm2 status
pm2 logs site

Ein Schwesterbeitrag von uns behandelt PM2 ausführlicher. Hier nehmen wir deshalb nur den Teil mit, den Next.js braucht.

Wie startet die App nach einem Neustart wieder?

PM2 startet beim Booten allerdings nicht von selbst. Sie müssen ein Startup Skript erzeugen und die Prozessliste speichern. Die PM2 Dokumentation sagt: Führen Sie zuerst pm2 startup aus, danach den Sudo Befehl, den PM2 ausgibt.

pm2 startup
pm2 save

Der erste Befehl erkennt Ihr Init System (auf den meisten modernen Distributionen systemd) und gibt Ihnen einen Befehl zum Kopieren und Ausführen. Führen Sie ihn genau so aus; Benutzername und Node Pfad stehen schon darin.

Dann speichert der zweite Befehl die Liste der laufenden Apps. Speichern Sie die Liste erneut, sobald Sie eine App hinzufügen oder entfernen. Schließlich starten Sie den Server zum Test einmal neu und prüfen, ob die App von allein zurückkehrt.

Können Sie systemd statt PM2 verwenden?

Ja, das können Sie. Denn auf modernen Linux Distributionen ist systemd ohnehin der Prozessmanager. Daher liefert eine Unit Datei für den Node Prozess dasselbe Ergebnis ohne zusätzliches Werkzeug. PM2 bietet andererseits mehr Komfort bei Logs und mehreren Prozessen.

Eine Beispiel Unit Datei sieht so aus. Sie speichern sie als /etc/systemd/system/site.service und aktivieren sie danach.

[Unit]
Description=Next.js site
After=network.target

[Service]
User=deploy
WorkingDirectory=/var/www/example.com/current/.next/standalone
Environment=NODE_ENV=production PORT=3000 HOSTNAME=127.0.0.1
ExecStart=/usr/bin/node server.js
Restart=always

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now site
sudo systemctl status site

Prüfen Sie den vollen Pfad von Node mit which node; bei nvm sieht er anders aus. Die Wahl ist also Geschmackssache. Kennt Ihr Team PM2, nutzen Sie PM2. Wollen Sie ein schlankes Setup, passt systemd.

Wie richten Sie Nginx als Reverse Proxy für Next.js ein?

Die Next.js Dokumentation empfiehlt einen Reverse Proxy wie Nginx, statt den Server direkt ins Internet zu stellen. Zudem fängt ein Proxy fehlerhafte Anfragen, Angriffe mit langsamen Verbindungen, Größenlimits und Ratenbegrenzung ab. Dann kann sich Next.js auf das Rendern konzentrieren.

Unter Debian und Ubuntu legen Sie die Site Datei in sites-available an und verlinken sie in sites-enabled. Eine Beispielkonfiguration folgt.

server {
    listen 80;
    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;
    }
}

Testen Sie nach dem Speichern zuerst die Syntax und laden Sie dann die Konfiguration neu. Der Test verhindert, dass eine einzige falsche Einstellung die ganze Seite lahmlegt.

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Welche Nginx Einstellungen sind für Next.js wichtig?

Drei Einstellungen zählen besonders. Die erste ist der Header Host. Laut Nginx Dokumentation lautet der Standardwert $proxy_host, daher hält die App ihre eigene Adresse womöglich für 127.0.0.1:3000. Deshalb haben wir oben Host $host ergänzt.

Die zweite ist der Header X-Forwarded-Proto. Die App erfährt daran nämlich, dass die Anfrage per HTTPS kam. Fehlt er, können daher Weiterleitungen und absolute Links mit http Adressen entstehen.

Die dritte ist das Streaming. Laut Next.js Dokumentation unterstützt der App Router Streaming, aber Nginx puffert Antworten standardmäßig. Damit das Streaming erhalten bleibt, zeigt die Dokumentation, den Header X-Accel-Buffering auf no zu setzen; Sie können ihn über headers() in der next.config.js ergänzen.

• Der Standardwert von proxy_read_timeout beträgt laut Nginx Dokumentation 60 Sekunden; denken Sie daran bei langen Anfragen.
• Prüfen Sie zum Beispiel bei Formularen mit Datei Upload das Limit client_max_body_size.
• Setzen Sie einen Load Balancer ein, sollte jede Zwischenschicht gestreamte Antworten ohne Pufferung durchreichen.

Die Namen der Einstellungen können Sie auf der offiziellen Seite nachprüfen: Dokumentation des Nginx Proxy Moduls.

Wie installieren Sie ein Let's Encrypt SSL Zertifikat?

Für HTTPS können Sie Certbot nutzen. Konkret holt Certbot mit dem Nginx Plugin das Zertifikat und ergänzt den HTTPS Block in Ihrer Konfiguration. Die Installation unterscheidet sich je nach Distribution, daher wählen Sie auf der Certbot Seite Ihre Distribution und folgen der aktuellen Anleitung.

Ohne DNS Eintrag, der auf die IP Adresse Ihres Servers zeigt, bekommen Sie also kein Zertifikat. Prüfen Sie zuerst die A und AAAA Einträge mit unserem DNS Abfrage Tool.

sudo certbot --nginx -d example.com -d www.example.com
sudo certbot renew --dry-run

Laut Certbot Dokumentation bringen die meisten Installationen eine automatische Erneuerung mit, also eine geplante Aufgabe, die regelmäßig certbot renew ausführt. Dennoch sollten Sie den Test mit renew --dry-run nicht auslassen. Außerdem zeigt die Ausgabe von systemctl list-timers, ob der Timer existiert.

Prüfen Sie nach der Installation die Kette mit dem SSL Check. Wofür das Zertifikat gut ist, lesen Sie in unserem Beitrag Was ist ein SSL Zertifikat.

Wie funktioniert die Bildoptimierung von Next.js auf einem VPS?

Laut Dokumentation funktioniert die Bildoptimierung mit next/image ohne zusätzliche Einrichtung, wenn Sie next start nutzen. Allerdings beansprucht sie CPU und Arbeitsspeicher Ihres Servers, denn Next.js optimiert Bilder zur Laufzeit und nicht beim Build.

Beim Standalone Betrieb prüfen Sie, ob das Paket sharp in der Ausgabe landet; nutzen Sie bei Bedarf das Beispiel zu outputFileTracingIncludes aus der Dokumentation. Die Dokumentation weist außerdem darauf hin, dass Linux Systeme mit glibc eine zusätzliche Einstellung für den Speicherallokator brauchen können.

• Laden Sie auf einem kleinen VPS deshalb keine riesigen Quellbilder hoch; verkleinern Sie sie vorher.
• Möchten Sie einen separaten Bilddienst, können Sie einen eigenen Image Loader definieren.
• Sie können die Optimierung stattdessen abschalten und die Bilder selbst vorbereiten.

Zur SEO Seite der Bildgröße lesen Sie unseren Leitfaden zum Thema Bilder für die Website optimieren.

Wie verhalten sich Cache und ISR auf einem einzelnen VPS?

Next.js hält erzeugte Seiten und Daten in einem Server Cache. Laut Dokumentation liegt dieser Cache standardmäßig auf der lokalen Festplatte jeder Next.js Instanz. Auf einem einzelnen Server mit dauerhaftem Speicher funktioniert das somit ohne zusätzliche Einrichtung.

Das Bild ändert sich, wenn Sie den Prozess vervielfachen. Jede Instanz hält ihren eigenen Cache, also erreicht eine Revalidierung auf einer Instanz die andere nicht. Die Lösung ist daher ein eigener Cache Handler mit einem gemeinsamen Speicher wie Redis.

Ein praktischer Tipp für kleine und mittlere Seiten mit VPS Deployment: Starten Sie mit einem Prozess. Wechseln Sie erst zu mehreren Instanzen, wenn Traffic oder der Bedarf an unterbrechungsfreien Updates wirklich da ist. Die Cache Logik haben wir zudem im Beitrag Caching erklärt: Redis und Memcached beschrieben.

Wie richten Sie nach dem VPS Deployment Updates und Rollback ein?

Legen Sie jede Version in einen eigenen Ordner und veröffentlichen Sie sie über einen symbolischen Link namens current. Ist eine neue Version bereit, tauschen Sie dann den Link. Geht etwas schief, kehren Sie in Sekunden zur alten Version zurück.

/var/www/example.com/
  releases/
    20250101-1200/
    20250108-0930/
  current -> releases/20250108-0930

Bauen Sie auf Ihrem eigenen Rechner oder in der CI und übertragen Sie den Standalone Ordner, sinkt auch der Speicherdruck auf einem kleinen Server. Für die Übertragung reicht rsync.

rsync -az --delete .next/standalone/ deploy@203.0.113.10:/var/www/example.com/releases/20250108-0930/
ssh deploy@203.0.113.10 "ln -sfn /var/www/example.com/releases/20250108-0930 /var/www/example.com/current"
ssh deploy@203.0.113.10 "pm2 reload ecosystem.config.js --env production"

Für ein Rollback setzen Sie den Link auf den vorigen Ordner und laden den Prozess neu. Prüfen Sie danach die Ausgabe von pm2 describe site und die Antwort Header, damit Sie sicher sind, dass die richtige Version läuft. Beachten Sie allerdings: Das macht nur den Code rückgängig. Haben Sie das Datenbankschema geändert, überlegen Sie vorher, ob der alte Code mit dem neuen Schema arbeitet. Zu Sicherungen lesen Sie unsere Website Backup Strategie.

Was ändert sich bei mehreren Instanzen und unterbrechungsfreien Reloads?

Der Cluster Modus von PM2 ermöglicht zwar unterbrechungsfreie Reloads. Allerdings verlangt die Next.js Dokumentation zusätzliche Einstellungen, sobald mehr als eine Instanz läuft. Sonst sehen Sie merkwürdige Fehler.

• Starten Sie alle Instanzen mit derselben Build Ausgabe; erzeugen Sie bei Bedarf mit generateBuildId eine einheitliche Build ID.
• Geben Sie den Server Functions auf jeder Instanz denselben NEXT_SERVER_ACTIONS_ENCRYPTION_KEY, sonst erscheint der Fehler "Failed to find Server Action".
• Nutzen Sie die Einstellung deploymentId, um Versionsunterschiede zu vermeiden.
• Definieren Sie einen Cache Handler, der den Cache in einen gemeinsamen Speicher verlagert.

Die Details dieser Liste stammen aus dem Self Hosting Leitfaden von Next.js selbst. Lesen Sie den Self Hosting Leitfaden von Next.js ganz durch, bevor Sie ihn anwenden.

Wie wirkt sich die Servereinrichtung auf SEO aus?

Suchmaschinen erreichen Ihre Seite über Ihren Server, deshalb zählt dessen Zustand. Daher beeinflusst die Serverkonfiguration die Sichtbarkeit indirekt. Eine langsame erste Antwort, eine falsche Weiterleitung und ein langer 5xx Ausfall sind die bekanntesten Risiken; das VPS Deployment ist also auch eine SEO Entscheidung.

Die Regel ist einfach: Jede URL sollte in genau einer kanonischen Form erreichbar sein. Richten Sie deshalb eine einstufige, dauerhafte Weiterleitung zwischen http und https sowie zwischen www und ohne www ein. Weiterleitungsketten bremsen zudem Besucher und Crawler.

Planen Sie Wartung, melden Sie das Besuchern und Suchmaschinen mit dem passenden Statuscode. Eine leere Seite mit Code 200 während der Wartung sendet nämlich ein falsches Signal. Außerdem kann ein Serverstandort weit weg von Ihrer Zielgruppe die Zeit bis zum ersten Byte verlängern.

Den Einfluss der Geschwindigkeit auf das Ranking besprechen wir weiter unten. Next.js kann dank Rendering auf dem Server Inhalte als HTML senden, doch dieser Vorteil hilft nur, wenn der Server gesund ist.

Wie richten Sie Logs und Überwachung ein?

Eine laufende Seite braucht Logs, denn Sie können nichts beheben, was Sie nicht lesen können. PM2 zeigt zum Beispiel die Ausgabe der App mit pm2 logs. Nginx führt Zugriffs und Fehlerlogs; unter Debian und Ubuntu liegen sie standardmäßig im Ordner /var/log/nginx/. Diese Dateien wachsen mit der Zeit, also prüfen Sie die Log Rotation.

Für PM2 gibt es ein Modul zur Log Rotation. Lesen Sie vor der Installation die aktuelle Anleitung auf der offiziellen Seite des Moduls.

pm2 install pm2-logrotate
pm2 logs site --lines 50

Richten Sie außerdem eine externe Überwachung ein. Dann meldet Ihnen ein einfacher Check den Ausfall früher als Ihre Besucher. Für eine schnelle Prüfung nutzen Sie das Tool Ist die Seite down.

Achten Sie auch auf die Festplatte. Vor allem Logs, alte Release Ordner und der Cache können sie füllen. Legen Sie sich daher eine einfache Aufräumroutine zu, die die letzten Versionen behält und ältere löscht.

Was sollten Sie nach dem VPS Deployment testen?

Schauen Sie nach dem Start nicht nur auf die Startseite. Einige Prüfungen sind zudem für Marketing und SEO wichtig. Eine falsche Weiterleitung oder ein falscher Statuscode kann die Sichtbarkeit in der Suche unbemerkt senken.

• Prüfen Sie mit dem Redirect Checker, dass http auf https und, falls gewünscht, www auf die Hauptadresse in einem Schritt weiterleitet.
• Bestätigen Sie außerdem, dass eine nicht vorhandene URL den Statuscode 404 liefert.
• Stellen Sie sicher, dass robots.txt und Ihre Sitemap vom Server erreichbar sind.
• Messen Sie Seitengeschwindigkeit und Zeit bis zum ersten Byte mit einem Google Lighthouse Test.
• Prüfen Sie in der Browser Konsole, ob statische Dateien einen 404 Fehler liefern.

Eine kurze Checkliste nach jedem Release bewahrt Sie davor, denselben Fehler zweimal zu machen. Dokumentieren Sie auch, welche Befehle Sie ausgeführt haben, damit Sie sie später nachvollziehen können.

Welche Fehler treten am häufigsten auf und wie beheben Sie sie?

Die folgende Tabelle sammelt Beschwerden, die beim Deployment oft auftauchen, und die erste Stelle zum Prüfen. Sie ist eine Prüfreihenfolge, die wir aus den offiziellen Dokumentationen abgeleitet haben; sie passt nicht in jeder Umgebung.

Bleibt das Problem bestehen, sammeln Sie Belege statt zu raten. Lesen Sie das Prozess Log, das Nginx Fehlerlog und die Anfrage Header nebeneinander. Oft zeigt eine der drei Quellen nämlich die Schicht des Problems. Ändern Sie dann nur diese Schicht; mehrere Änderungen gleichzeitig verdecken, was geholfen hat.

Arbeiten Sie beim VPS Deployment in dieser Reihenfolge: zuerst der Prozess, dann der Proxy, zuletzt Domain und Zertifikat. Wer die Reihenfolge überspringt, verliert daher Zeit.

Wann sollten Sie das nicht selbst tun?

Seien wir ehrlich: Einen VPS zu betreiben ist nicht für jedes Team richtig. Wenn niemand Ihren Server aktualisiert, überwacht und sichert, ist eine verwaltete Lösung sicherer. Vor allem bei einem Shop mit Zahlungen bedeutet Ausfallzeit direkt entgangenen Umsatz.

• Niemand verfolgt Server Patches und Sicherheitsupdates? Wählen Sie dann eine verwaltete Plattform.
• Keine Bereitschaft für Ausfälle? Rechnen Sie das Risiko deshalb durch, bevor Sie starten.
• Gesetz, Datenhaltung oder Vertrag verlangen einen dedizierten Server? Planen Sie ihn gemeinsam mit Ihrem Anbieter.
• Plötzliche Lastspitzen können einen einzelnen VPS überfordern, also planen Sie Reserven ein.

Möchten Sie das Setup gemeinsam planen? Unsere individuelle Softwareentwicklung deckt solche Projekte ab. Container sind eine weitere Option; unser Leitfaden Was ist Docker eignet sich als Einstieg.

In welcher Reihenfolge gehen Sie beim VPS Deployment vor?

Kurz gesagt lautet die Reihenfolge beim VPS Deployment: entscheiden, Server vorbereiten, Standalone Ausgabe erzeugen, von Hand testen, zu PM2 wechseln, Nginx einrichten, SSL aktivieren und den Update Ablauf aufbauen. Wer in jeder Stufe den vorigen Schritt prüft, hält Fehler klein.

Zum Schluss unsere wichtigste Warnung: Kopieren Sie keine Befehle, die Sie nicht verstehen. Prüfen Sie in der offiziellen Dokumentation, was jeder Befehl tut, führen Sie ihn zuerst auf einem Testserver aus und erst danach auf der Live Seite. So senken Sie somit das Fehlerrisiko und die Ausfallzeit.

Denken Sie außerdem daran, dass Deployment keine einmalige Aufgabe ist. Updates, Backups und Überwachung hören nämlich nie auf. Können Sie das nicht leisten, ist eine verwaltete Lösung womöglich klüger als ein VPS.

Wenn Sie Unterstützung bei technischer Grundlage und Sichtbarkeit Ihrer Seite wünschen, sprechen Sie unser Team an. Wir schauen uns Ihr Setup dann gern gemeinsam mit Ihnen an.