So stellen Sie eine Next.js-App im Jahr 2026 für die Produktion bereit: Vollständiger Leitfaden

Eine Next.js-App zu erstellen ist eine Sache; Eine andere Möglichkeit besteht darin, es zuverlässig in der Produktion bereitzustellen. Dieser Leitfaden behandelt die wichtigsten Bereitstellungspfade – Vercel (am einfachsten) und Selbsthosting mit Docker (größte Kontrolle) – sowie die Konfiguration und Optimierung, die für eine Next.js-Produktionsanwendung im Jahr 2026 wichtig sind.

Übersicht über Bereitstellungsoptionen

Methode 1: Vercel (am einfachsten)

# Install Vercel CLI
npm install -g vercel

# Deploy from your project directory
vercel                    # preview deployment
vercel --prod             # production deployment

# Or connect your Git repo in the Vercel dashboard for
# automatic deployments on every push

Vercel (erstellt von den Entwicklern von Next.js) verarbeitet Builds, Edge-Caching, serverlose Funktionen und Bildoptimierung automatisch. Legen Sie Umgebungsvariablen im Dashboard fest. Dies ist der schnellste Weg zu einer produktiven Next.js-App ohne Infrastrukturverwaltung.

Methode 2: Docker-Selbsthosting

Für vollständige Kontrolle und vorhersehbare Kosten im großen Maßstab können Sie mit Docker selbst hosten. Die eigenständige Ausgabe von Next.js macht dies effizient:

// next.config.js — enable standalone output
module.exports = {
  output: 'standalone',   // bundles only needed files for a small image
};

# Dockerfile — multi-stage for a small production image
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
# Copy standalone output (much smaller than full node_modules)
COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static
COPY --from=builder /app/public ./public
EXPOSE 3000
CMD ["node", "server.js"]

# Build and run
docker build -t my-nextjs-app .
docker run -p 3000:3000 --env-file .env.production my-nextjs-app

Nginx Reverse Proxy für Selbsthosting

# /etc/nginx/sites-enabled/myapp
server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        proxy_pass http://localhost:3000;
        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;
    }

    # Cache Next.js static assets aggressively
    location /_next/static {
        proxy_pass http://localhost:3000;
        add_header Cache-Control "public, max-age=31536000, immutable";
    }
}

Umgebungsvariablen in der Produktion

# Server-only secrets (never exposed to browser)
DATABASE_URL=postgresql://...
API_SECRET=...

# Client-exposed vars need NEXT_PUBLIC_ prefix (these are PUBLIC)
NEXT_PUBLIC_API_URL=https://api.example.com

# Set these in Vercel dashboard, or pass via --env-file to Docker
# NEVER commit production secrets

Caching und erneute Validierung

// Incremental Static Regeneration — cache pages, revalidate periodically
export const revalidate = 3600;   // regenerate at most once per hour

// Or on-demand revalidation via API
import { revalidatePath } from 'next/cache';

export async function POST(request) {
  // After content changes, revalidate the affected page
  revalidatePath('/blog');
  return Response.json({ revalidated: true });
}

// Fetch caching
const data = await fetch('https://api.example.com/data', {
  next: { revalidate: 60 },   // cache this fetch for 60 seconds
});

Produktionscheckliste

• Eigenständige Ausgabe aktivieren für kleinere Docker-Images
• Legen Sie alle Umgebungsvariablen fest in Ihrer Plattform (nicht festgeschrieben)
• Caching konfigurieren – ISR für Seiten, Cache-Header für statische Assets
• Bilder optimieren — next/image verwenden (automatisch auf Vercel; beim Selbsthosten einen Loader konfigurieren)
• Fehlerüberwachung hinzufügen — Wachposten o.ä. für Produktionsfehler
• HTTPS einrichten — automatisch bei Vercel; Let’s Encrypt für Selbsthosting
• Komprimierung aktivieren – gzip/brotli auf Proxy-Ebene

Häufig gestellte Fragen

F: Vercel oder Selbsthosting?
A: Vercel für die schnellste Bereitstellung und kein Infrastrukturmanagement (ideal für die meisten Apps). Selbsthosting mit Docker für vollständige Kontrolle, vorhersehbare Kosten im großen Maßstab oder spezifische Infrastrukturanforderungen. Beginnen Sie mit Vercel; Wechseln Sie zum Selbsthosting, wenn Kosten oder Kontrolle dies erfordern.

F: Unterstützt selbstgehostetes Next.js alle Funktionen?
A: Die meisten, ja – SSR, ISR, API-Routen und Bildoptimierung funktionieren alle selbst gehostet (Bildoptimierung erfordert einen konfigurierten Loader). Einige Vercel-spezifische Edge-Funktionen unterscheiden sich, aber der Kern von Next.js funktioniert vollständig, wenn er selbst gehostet wird.

F: Warum funktioniert meine selbst gehostete Bildoptimierung nicht?
A: Die Next/Image-Optimierung erfolgt automatisch auf Vercel, muss jedoch beim Selbsthosten konfiguriert werden – verwenden Sie entweder den integrierten Optimierer (erfordert Sharp) oder konfigurieren Sie einen externen Image Loader/CDN. Überprüfen Sie die Bildeinstellungen von next.config.js.

F: Wie gehe ich mit Umgebungsvariablen um, die je nach Umgebung unterschiedlich sind?
A: Legen Sie sie in Ihrer Hosting-Plattform fest (Vercel-Dashboard, Docker –env-file oder Ihr Orchestrator). Verwenden Sie das Präfix NEXT_PUBLIC_ nur für Werte, die sicher im Browser angezeigt werden können. Bewahren Sie Geheimnisse serverseitig auf.

F: Wie reduziere ich Kaltstarts?
A: Auf Vercel haben serverlose Funktionen einen Kaltstart. Halte sie schlank. Selbstgehostet mit einem Knotenserver mit langer Laufzeit hat keine Kaltstarts. Bei ISR/statischen Seiten werden die meisten Anfragen unabhängig davon sofort aus dem Cache bedient.

Fazit

Die Bereitstellung von Next.js in der Produktion im Jahr 2026 erfolgt über zwei Hauptpfade:Vercel für die schnellste Bereitstellung ohne Konfiguration mit automatischer Optimierung und Edge-Caching, oderDocker-Selbsthosting für volle Kontrolle und vorhersehbare Kosten Verwenden einer eigenständigen Ausgabe für kleine Bilder hinter einem Nginx-Proxy. Wofür Sie sich auch entscheiden, legen Sie Umgebungsvariablen in der Plattform fest (nie festgeschrieben), konfigurieren Sie das Caching mit ISR und Cache-Headern, optimieren Sie Bilder und fügen Sie eine Fehlerüberwachung hinzu. Beginnen Sie der Einfachheit halber mit Vercel und wechseln Sie zum Selbsthosting, wenn Kosten oder Kontrollanforderungen den zusätzlichen Betriebsaufwand rechtfertigen.