30. Okt. 2026Blog

Stellen Sie Next.js auf einem VPS bereit: vom Build bis HTTPS

PRNext

Ihre Anwendung funktioniert lokal. Auf einem VPS muss es auch eine SSH-Trennung überstehen, seine Ressourcen bereitstellen und Formulare hinter Ihrer Domain verarbeiten. Dieser Leitfaden folgt diesem Weg vom Produktions-Build bis zur öffentlichen Verifizierung.

Die Beispiele zielen auf eine Next.js-Anwendung mit herkömmlichen Build- und Startskripts, auf Linux mit systemd und einem vorhandenen Nginx-Reverse-Proxy. Passen Sie Pfade, das Dienstkonto und die Domäne an Ihre Umgebung an. Für einen statischen Export und eine auf Anfrage gerenderte Anwendung gelten unterschiedliche Bereitstellungsanforderungen.

Bereiten Sie eine identifizierbare Veröffentlichung vor

Beginnen Sie mit einem bekannten Commit, seiner Sperrdatei und einer Knotenversion, die mit der installierten Next.js-Version kompatibel ist. Für npm installiert npm ci Abhängigkeiten von dieser Sperrdatei. Behalten Sie den vorhandenen Paketmanager und den reproduzierbaren Installationsmodus für pnpm oder Yarn bei.

Erstellen Sie in einem Release-Verzeichnis oder CI statt im Ausgabeverzeichnis eines laufenden Servers. Ein Build kann Anwendungscode ausführen und Dienste kontaktieren. Stellen Sie die benötigten Variablen bereit, ohne Geheimnisse preiszugeben. NEXT_PUBLIC_-Werte sind für den Browser gedacht und werden während des Builds eingebettet.

Terminal

node --version
npm ci
npm run build

Starten Sie den Produktionsserver im Loopback

Überprüfen Sie, ob das Startskript beim nächsten Start ausgeführt wird. Der Entwicklungsserver ist nicht der Prozess, der in der Produktion gehalten werden soll. Die Bindung an 127.0.0.1 schränkt den direkten Zugriff auf den Server und seinen lokalen Proxy ein und hält den Anwendungsport von der öffentlichen Schnittstelle fern.

Überprüfen Sie in einem anderen Terminal eine echte Seite mit curl -i http://127.0.0.1:3000/. Überprüfen Sie den Inhalt und die Vermögenswerte. Wenn Sie Ausgabe: Standalone ausgewählt haben, verwenden Sie die generierte server.js und die erwartete Verzeichnisstruktur, einschließlich public und .next/static. Dieser Modus verfügt über einen eigenen Einstiegspunkt.

Terminal

npm run start -- --hostname 127.0.0.1 --port 3000

Lassen Sie systemd den Prozess verwalten

Eine systemd-Einheit führt den Dienst unabhängig von Ihrer Sitzung aus. In diesem Beispiel wird von einem vorhandenen Webapp-Konto und einer Veröffentlichung unter /srv/my-next-app ausgegangen. Überprüfen Sie den Knotenpfad mit dem Befehl -v node und passen Sie ExecStart an. Das Konto muss die Version lesen und nur in die Anwendungsspeicherorte schreiben, die dies erfordern.

Behalten Sie Servervariablen in der Umgebungsdatei mit den für das Dienstkonto geeigneten Berechtigungen bei. Nachdem Sie das Gerät in Ihrer Umgebung installiert haben, validieren Sie es mit systemd-analyze verify, laden Sie systemd neu und starten Sie den Dienst. Überprüfen Sie das Journal, wenn der Start fehlschlägt. Automatische Neustarts ersetzen nicht die Untersuchung eines speicherbezogenen Exits.

my-next-app.service

[Unit]
Description=My Next.js application
After=network.target

[Service]
Type=simple
User=webapp
WorkingDirectory=/srv/my-next-app
Environment=NODE_ENV=production
EnvironmentFile=/etc/my-next-app.env
ExecStart=/usr/bin/node /srv/my-next-app/node_modules/next/dist/bin/next start --hostname 127.0.0.1 --port 3000
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Leiten Sie die Domäne an die Anwendung weiter

Innerhalb des Serverblocks der Domäne kann ein Standort Anfragen an die lokale Anwendung weiterleiten. Das folgende Fragment behandelt HTTP und Streaming; Integrieren Sie es in die vorhandene Konfiguration und führen Sie nginx -t vor dem Neuladen aus. Es handelt sich nicht um eine vollständige TLS-Konfiguration.

Die Domäne muss zum VPS aufgelöst werden und über ein gültiges Zertifikat mit funktionierender Erneuerung verfügen. Behalten Sie den Host und das Originalprotokoll für die Anwendung bei. Beginnen Sie ohne einen gemeinsamen Cache mit dynamischer Antwort: Private Seiten, Cookies und Navigationsvarianten benötigen eine explizite Richtlinie. Wenn die Anwendung WebSockets verwendet, fügen Sie die entsprechende Nginx-Upgrade-Header-Verarbeitung separat hinzu.

nginx.conf

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

Überprüfen Sie die öffentliche Website

Eine 200-Antwort von der Homepage überprüft nicht die gesamte Anwendung. Üben Sie eine dynamische Route, eine fehlende Seite, Anmeldung, Abmeldung und ein Formular aus. Überprüfen Sie Weiterleitungen, sichere Cookies, Bilder und Navigation in einem Browser.

Testen Sie auch eine Streaming-Seite. Wenn Inhalte auf einmal über die Domäne, aber nach und nach über Loopback eintreffen, prüfen Sie die Pufferung bei jedem Vermittler. Behalten Sie die vorherige Version und ihre Konfiguration bei, bevor Sie den Datenverkehr wechseln. Das Zurücksetzen des Anwendungscodes erfordert außerdem Kompatibilität mit etwaigen Datenbankmigrationen.

Größe und Weiterentwicklung der Bereitstellung

Messen Sie ungenutzten Speicher, Verkehrsspitzen und Bereitstellungsüberschneidungen. Zwei Releases können kurzzeitig nebeneinander existieren, und der Aufbau auf dem VPS fügt seinen eigenen Höhepunkt hinzu. Auch die Datenbank und der Proxy gehören in das Gesamtbudget.

Um PRNext auszuwerten, behalten Sie die Referenz Next.js bei und erstellen Sie einen Kandidaten in einem anderen Verzeichnis. Überprüfen Sie das Verhalten und die Leistung Ihrer Anwendung, bevor Sie deren Laufzeit ändern.

Größe des VPS-Speichers für Next.js

Überprüfen Sie vor der Migration die PRNext-Kompatibilität