<span id="deploy-a-nextjs-static-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](https://lizard.build/de/docs/framework-guides/nextjs) für Serverfunktionen zur Anfragezeit.

<span id="configure-the-export" />

## Den Export konfigurieren

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

```js
/** @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](https://nextjs.org/docs/app/guides/static-exports) gegen die Funktionen, die Ihre App verwendet.

<span id="add-a-complete-dockerfile" />

## 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:

```dockerfile
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`:

```nginx
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.

<span id="build-and-deploy" />

## Bauen und bereitstellen

```bash
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:

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

Nach der [CLI-Einrichtung](https://lizard.build/de/docs/framework-guides#prepare-the-project) stellen Sie in einem neuen Service bereit:

```bash
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](https://lizard.build/de/docs/concepts/build-pipeline#build-decision-order).

<span id="verify-routes-and-updates" />

## 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](https://lizard.build/de/docs/framework-guides/static-routing#verify-http-responses).

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](https://lizard.build/de/docs/framework-guides/validation) für die Bereitstellungsprüfungen vom 9. September 2026 und ihre Grenzen.