Framework-AnleitungenStatischer Export

Einen statischen Next.js-Export bereitstellen

Ein statischer Next.js-Export erzeugt HTML, JavaScript und Assets in out/. Stellen Sie dieses Verzeichnis auf Lizard mit einem nginx-Dockerfile bereit. Verwenden Sie diesen Weg für Seiten, die vorab gebaut werden können; verwenden Sie den Leitfaden für den Node.js-Server für Serverfunktionen zur Anfragezeit.

Den Export konfigurieren

Fügen Sie diese Optionen in next.config.mjs zusammen:

/** @type {import('next').NextConfig} */
const nextConfig = {
  output: 'export',
  trailingSlash: true,
  images: { unoptimized: true },
};
 
export default nextConfig;

Behalten Sie "build": "next build" in package.json bei. Dieses Beispiel verwendet einfache exportierte Bilder; ein externer Image-Loader ist eine weitere Option. Erzeugen Sie während des Builds alle erforderlichen Parameter für dynamische Routen. Cookies zur Anfragezeit, Server Actions und andere Funktionen, die einen laufenden Next.js-Server benötigen, können in diesem statischen Container nicht ausgeführt werden. Prüfen Sie die Next.js-Referenz für statische Exporte gegen die Funktionen, die Ihre App verwendet.

Ein vollständiges Dockerfile hinzufügen

Die automatische Erkennung für Next.js erwartet einen Node-Server. Sie wechselt nicht zu nginx, nur weil die Konfiguration out/ exportiert. Fügen Sie dieses Dockerfile im App-Stammverzeichnis hinzu; es setzt npm und ein eingechecktes package-lock.json voraus:

FROM node:22-slim AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build
 
FROM nginx:alpine
COPY --from=build /app/out /usr/share/nginx/html
COPY nginx.conf /etc/nginx/conf.d/default.conf
EXPOSE 80

Erstellen Sie daneben nginx.conf:

server {
  listen 80;
  server_name _;
  root /usr/share/nginx/html;
  index index.html;
  location / {
    try_files $uri $uri/ =404;
  }
  error_page 404 /404.html;
  location = /404.html {
    internal;
  }
}

Der Export mit Trailing Slash erstellt Routenverzeichnisse mit index.html. Die nginx-Regel bedient diese Verzeichnisse und gibt für fehlende Pfade HTTP 404 zurück. Fügen Sie node_modules, .next, out, .git und .env* zu .dockerignore hinzu und schließen Sie lokale Build-Dateien von Uploads aus.

Bauen und bereitstellen

npm ci
npm run build

Prüfen Sie, dass out/index.html und eine erwartete innere Route vorhanden sind. Wenn Docker verfügbar ist, testen Sie den tatsächlichen Server lokal:

docker build -t nextjs-static .
docker run --rm -p 8080:80 nextjs-static

Nach der CLI-Einrichtung stellen Sie in einem neuen Service bereit:

lizard init --name nextjs-static
lizard add --service web
lizard up --service web --port 80
lizard logs --build --service web --json
lizard ps --json

Das vollständige Dockerfile enthält einen npm-Build-Schritt, den lizardpack erkennen kann. Prüfen Sie bei einem bestehenden Service vor der Auswahl eines Dockerfiles widersprüchliche Build-/Start-Überschreibungen und entfernen Sie sie; siehe Reihenfolge der Build-Entscheidung.

Routen und Aktualisierungen prüfen

Rufen Sie die Live-Startseite, eine exportierte innere Route, ein JavaScript-Asset und einen erfundenen Pfad auf. Der erfundene Pfad muss HTTP 404 zurückgeben, nicht die Startseite mit HTTP 200. Verwenden Sie die Prüfungen unter statische Routen und 404er.

Alle Änderungen an exportierten Inhalten erfordern einen neuen Build. Laufzeit-Umgebungsvariablen können Werte, die bereits in out/ geschrieben wurden, nicht ändern. Deklarieren Sie für öffentliche Build-Variablen in einem benutzerdefinierten Dockerfile das erforderliche ARG vor RUN npm run build; legen Sie niemals private Zugangsdaten im exportierten Bundle ab.

Siehe getestete Versionen und Cloud-Ergebnisse für die Bereitstellungsprüfungen vom 9. September 2026 und ihre Grenzen.

Next.jsReact (Vite)