Bereitstellung

Herzlichen Glückwunsch, es ist Zeit, die Anwendung zu veröffentlichen.

Sie können verwaltetes Next.js mit Vercel bereitstellen oder auf einem Node.js-Server, Docker-Image oder sogar als statische HTML-Dateien selbst hosten. Bei der Bereitstellung mit next start werden alle Next.js-Funktionen unterstützt.

Produktions-Builds

Die Ausführung von next build generiert eine optimierte Version Ihrer Anwendung für die Produktion. HTML-, CSS- und JavaScript-Dateien werden basierend auf Ihren Seiten erstellt. JavaScript wird kompiliert und Browser-Bundles werden mit dem Next.js Compiler minimiert, um die beste Leistung zu erzielen und alle modernen Browser zu unterstützen.

Next.js erzeugt einen standardmäßigen Bereitstellungs-Output, der von verwalteten und selbst gehosteten Next.js-Instanzen genutzt wird. Dies stellt sicher, dass alle Funktionen bei beiden Bereitstellungsmethoden unterstützt werden. In der nächsten Hauptversion werden wir diesen Output in unsere Build Output API-Spezifikation umwandeln.

Verwaltetes Next.js mit Vercel

Vercel, die Ersteller und Betreuer von Next.js, bieten verwaltete Infrastruktur und eine Entwickler-Erlebnisplattform für Ihre Next.js-Anwendungen.

Die Bereitstellung auf Vercel erfolgt ohne Konfiguration und bietet zusätzliche Verbesserungen für Skalierbarkeit, Verfügbarkeit und globale Leistung. Alle Next.js-Funktionen werden jedoch auch bei selbst gehosteten Anwendungen unterstützt.

Erfahren Sie mehr über Next.js auf Vercel oder stellen Sie eine Vorlage kostenlos bereit, um es auszuprobieren.

Selbst-Hosting

Sie können Next.js auf drei verschiedene Arten selbst hosten:

• Ein Node.js-Server
• Ein Docker-Container
• Ein statischer Export

🎥 Video: Erfahren Sie mehr über Selbst-Hosting von Next.js → YouTube (45 Minuten).

Node.js-Server

Next.js kann auf jedem Hosting-Anbieter bereitgestellt werden, der Node.js unterstützt. Stellen Sie sicher, dass Ihre package.json die Skripte "build" und "start" enthält:

{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start"
  }
}

Führen Sie dann npm run build aus, um Ihre Anwendung zu bauen. Schließlich starten Sie den Node.js-Server mit npm run start. Dieser Server unterstützt alle Next.js-Funktionen.

Docker-Image

Next.js kann auf jedem Hosting-Anbieter bereitgestellt werden, der Docker-Container unterstützt. Sie können diesen Ansatz bei der Bereitstellung auf Container-Orchestrierungen wie Kubernetes oder beim Ausführen in einem Container in einem beliebigen Cloud-Anbieter verwenden.

1. Installieren Sie Docker auf Ihrem Rechner
2. Klonen Sie unser Beispiel (oder das Multi-Umgebungs-Beispiel)
3. Bauen Sie Ihren Container: docker build -t nextjs-docker .
4. Führen Sie Ihren Container aus: docker run -p 3000:3000 nextjs-docker

Next.js über Docker unterstützt alle Next.js-Funktionen.

Statischer HTML-Export

Next.js ermöglicht es, als statische Site oder Single-Page-Anwendung (SPA) zu starten und später optional Funktionen zu verwenden, die einen Server erfordern.

Da Next.js diesen statischen Export unterstützt, kann er auf jedem Webserver bereitgestellt und gehostet werden, der HTML/CSS/JS statische Assets ausliefern kann. Dies umfasst Tools wie AWS S3, Nginx oder Apache.

Der Betrieb als statischer Export unterstützt keine Next.js-Funktionen, die einen Server erfordern. Mehr erfahren.

Hinweis:

• Server-Komponenten werden mit statischen Exports unterstützt.

Funktionen

Bildoptimierung

Bildoptimierung über next/image funktioniert selbst gehostet ohne Konfiguration bei Bereitstellung mit next start. Wenn Sie einen separaten Dienst zur Bildoptimierung bevorzugen, können Sie einen Bildlader konfigurieren.

Bildoptimierung kann mit einem statischen Export verwendet werden, indem in next.config.js ein benutzerdefinierter Bildlader definiert wird. Beachten Sie, dass Bilder zur Laufzeit und nicht während des Builds optimiert werden.

Hinweis:

• Auf glibc-basierten Linux-Systemen kann die Bildoptimierung zusätzliche Konfiguration erfordern, um übermäßige Speichernutzung zu verhindern.
• Erfahren Sie mehr über das Caching-Verhalten von optimierten Bildern und wie Sie die TTL konfigurieren können.
• Sie können die Bildoptimierung deaktivieren und trotzdem andere Vorteile von next/image beibehalten, wenn Sie dies vorziehen. Zum Beispiel, wenn Sie Bilder separat selbst optimieren.

Middleware

Middleware funktioniert selbst gehostet ohne Konfiguration bei Bereitstellung mit next start. Da sie Zugriff auf die eingehende Anfrage benötigt, wird sie bei Verwendung eines statischen Exports nicht unterstützt.

Middleware verwendet eine Laufzeitumgebung, die eine Teilmenge aller verfügbaren Node.js-APIs umfasst, um eine geringe Latenz zu gewährleisten, da sie möglicherweise vor jeder Route oder jedem Asset in Ihrer Anwendung ausgeführt wird. Diese Laufzeitumgebung erfordert keine Ausführung "am Rand" und funktioniert auf einem Server in einer einzigen Region. Zusätzliche Konfiguration und Infrastruktur sind erforderlich, um Middleware in mehreren Regionen auszuführen.

Wenn Sie Logik hinzufügen möchten (oder ein externes Paket verwenden möchten), das alle Node.js-APIs erfordert, können Sie diese Logik möglicherweise in ein Layout als Server-Komponente verschieben. Beispielsweise das Überprüfen von Headern und Umleiten. Sie können auch Header, Cookies oder Abfrageparameter verwenden, um über next.config.js umzuleiten oder umzuschreiben. Wenn das nicht funktioniert, können Sie auch einen benutzerdefinierten Server verwenden.

Umgebungsvariablen

Next.js kann sowohl Umgebungsvariablen zur Bauzeit als auch zur Laufzeit unterstützen.

Standardmäßig stehen Umgebungsvariablen nur auf dem Server zur Verfügung. Um eine Umgebungsvariable für den Browser verfügbar zu machen, muss sie mit NEXT_PUBLIC_ beginnen. Diese öffentlichen Umgebungsvariablen werden jedoch während next build in das JavaScript-Bundle eingebettet.

Um Umgebungsvariablen zur Laufzeit zu lesen, empfehlen wir die Verwendung von getServerSideProps oder schrittweiser Einführung des App Routers.

Dies ermöglicht die Verwendung eines einzelnen Docker-Images, das durch verschiedene Umgebungen mit unterschiedlichen Werten promoviert werden kann.

Hinweis:

• Du kannst Code beim Serverstart mithilfe der register-Funktion ausführen.
• Wir empfehlen nicht die Verwendung der runtimeConfig Option, da diese nicht mit dem Standalone-Ausgabemodus funktioniert. Stattdessen empfehlen wir das schrittweise Einführen des App Routers.

Caching und ISR

Next.js kann Antworten, generierte statische Seiten, Build-Ausgaben und andere statische Assets wie Bilder, Schriftarten und Skripte zwischenspeichern.

Caching und Revalidierung von Seiten (mit Inkrementeller Statischer Regeneration) verwenden den gleichen gemeinsamen Cache. Standardmäßig wird dieser Cache im Dateisystem (auf Festplatte) auf Ihrem Next.js-Server gespeichert. Dies funktioniert automatisch beim Selbst-Hosting sowohl mit dem Pages- als auch dem App-Router.

Sie können den Next.js-Cache-Speicherort konfigurieren, wenn Sie zwischengespeicherte Seiten und Daten in dauerhaftem Speicher speichern oder den Cache über mehrere Container oder Instanzen Ihrer Next.js-Anwendung hinweg teilen möchten.

Automatisches Caching

• Next.js setzt den Cache-Control-Header von public, max-age=31536000, immutable für absolut unveränderliche Assets. Dies kann nicht überschrieben werden. Diese unveränderlichen Dateien enthalten einen SHA-Hash im Dateinamen, sodass sie sicher unbegrenzt zwischengespeichert werden können. Zum Beispiel Statische Bildimporte. Sie können die TTL für Bilder konfigurieren.
• Inkrementelle Statische Regeneration (ISR) setzt den Cache-Control-Header von s-maxage: <Revalidierung in getStaticProps>, stale-while-revalidate. Diese Revalidierungszeit wird in Sekunden in Ihrer getStaticProps-Funktion definiert. Wenn Sie revalidate: false setzen, wird standardmäßig eine einjährige Cache-Dauer verwendet.
• Dynamisch gerenderte Seiten setzen einen Cache-Control-Header von private, no-cache, no-store, max-age=0, must-revalidate, um zu verhindern, dass benutzerspezifische Daten zwischengespeichert werden. Dies gilt sowohl für den App-Router als auch für den Pages-Router. Dies umfasst auch den Entwurfsmodus.

Statische Assets

Wenn Sie statische Assets auf einer anderen Domäne oder einem CDN hosten möchten, können Sie das assetPrefix Configuration in next.config.js verwenden. Next.js wird diesen Asset-Präfix beim Abrufen von JavaScript- oder CSS-Dateien verwenden. Die Trennung der Assets auf eine andere Domäne hat den Nachteil zusätzlicher Zeit für DNS- und TLS-Auflösung.

Mehr über assetPrefix erfahren.

Caching konfigurieren

Standardmäßig werden generierte Cache-Assets im Speicher (Standard 50 MB) und auf der Festplatte gespeichert. Wenn Sie Next.js mit einer Container-Orchestrierungsplattform wie Kubernetes hosten, hat jedes Pod eine Kopie des Caches. Um zu verhindern, dass veraltete Daten angezeigt werden, da der Cache standardmäßig nicht zwischen Pods geteilt wird, können Sie den Next.js-Cache so konfigurieren, dass er einen Cache-Handler bereitstellt und Caching im Speicher deaktiviert.

Um den ISR/Data-Cache-Speicherort beim Selbst-Hosting zu konfigurieren, können Sie in Ihrer next.config.js-Datei einen benutzerdefinierten Handler konfigurieren:

module.exports = {
  cacheHandler: require.resolve('./cache-handler.js'),
  cacheMaxMemorySize: 0, // Standard-Speicher-Caching deaktivieren
}

Erstellen Sie dann cache-handler.js im Stammverzeichnis Ihres Projekts, zum Beispiel:

const cache = new Map()
 
module.exports = class CacheHandler {
  constructor(options) {
    this.options = options
  }
 
  async get(key) {
    // Dies könnte überall gespeichert werden, wie dauerhafter Speicher
    return cache.get(key)
  }
 
  async set(key, data, ctx) {
    // Dies könnte überall gespeichert werden, wie dauerhafter Speicher
    cache.set(key, {
      value: data,
      lastModified: Date.now(),
      tags: ctx.tags,
    })
  }
 
  async revalidateTag(tags) {
    // tags ist entweder ein String oder ein Array von Strings
    tags = [tags].flat()
    // Alle Einträge im Cache durchlaufen
    for (let [key, value] of cache) {
      // Wenn die Tags des Wertes den angegebenen Tag enthalten, diesen Eintrag löschen
      if (value.tags.some((tag) => tags.include(tag))) {
        cache.delete(key)
      }
    }
  }
}

Die Verwendung eines benutzerdefinierten Cache-Handlers ermöglicht es Ihnen, Konsistenz über alle Pods zu gewährleisten, die Ihre Next.js-Anwendung hosten. Sie können die zwischengespeicherten Werte beispielsweise überall speichern, wie Redis oder AWS S3.

Hinweis:

• revalidatePath ist eine Komfortschicht über Cache-Tags. Der Aufruf von revalidatePath ruft die revalidateTag-Funktion mit einem speziellen Standard-Tag für die angegebene Seite auf.

Build-Cache

Next.js generiert während next build eine ID, um zu identifizieren, welche Version der Anwendung bereitgestellt wird. Der gleiche Build sollte zum Hochfahren mehrerer Container verwendet werden.

Wenn Sie für jede Umgebungsstufe neu erstellen, müssen Sie eine konsistente Build-ID generieren, die zwischen Containern verwendet wird. Verwenden Sie den generateBuildId-Befehl in next.config.js:

module.exports = {
  generateBuildId: async () => {
    // Dies kann alles sein, mit Verwendung des neuesten Git-Hashs
    return process.env.GIT_HASH
  },
}

Versions-Skew

Next.js wird automatisch die meisten Instanzen von Versions-Skew abmildern und die Anwendung automatisch neu laden, um neue Assets zu erhalten, wenn sie erkannt werden. Wenn beispielsweise eine Unstimmigkeit in der deploymentId vorliegt, werden Seitenübergänge eine harte Navigation durchführen, anstatt einen vorher abgerufenen Wert zu verwenden.

Wenn die Anwendung neu geladen wird, kann es zum Verlust des Anwendungszustands kommen, wenn dieser nicht so konzipiert ist, dass er zwischen Seitennavigationen persistent bleibt. Zum Beispiel würden URL-Status oder lokaler Speicher den Status nach einem Seitenneuladen beibehalten. Komponentenstatus wie useState würde jedoch bei solchen Navigationen verloren gehen.

Vercel bietet zusätzlichen Skew-Schutz für Next.js-Anwendungen, um sicherzustellen, dass Assets und Funktionen der vorherigen Version für ältere Clients weiterhin verfügbar sind, auch nach der Bereitstellung der neuen Version.

Sie können die deploymentId-Eigenschaft in Ihrer next.config.js-Datei manuell konfigurieren, um sicherzustellen, dass jede Anfrage entweder die ?dpl-Abfragezeichenfolge oder den x-deployment-id-Header verwendet.

Manuelle Graceful Shutdowns

Bei Self-Hosting möchten Sie möglicherweise Code ausführen, wenn der Server bei SIGTERM- oder SIGINT-Signalen heruntergefahren wird.

Sie können die Umgebungsvariable NEXT_MANUAL_SIG_HANDLE auf true setzen und dann einen Handler für dieses Signal in Ihrer _document.js-Datei registrieren. Sie müssen die Umgebungsvariable direkt im package.json-Skript registrieren und nicht in der .env-Datei.

Hinweis: Manuelles Signalhandling ist nicht in next dev verfügbar.

{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "NEXT_MANUAL_SIG_HANDLE=true next start"
  }
}

if (process.env.NEXT_MANUAL_SIG_HANDLE) {
  process.on('SIGTERM', () => {
    console.log('SIGTERM empfangen: Bereinigung')
    process.exit(0)
  })
  process.on('SIGINT', () => {
    console.log('SIGINT empfangen: Bereinigung')
    process.exit(0)
  })
}