Ich betreibe Next.js in der Produktion seit Version 9. Die meiste Zeit war Vercel die offensichtliche Wahl — deployen, vergessen, weitermachen. Aber irgendwann um 2024 begannen die Rechnungen wie Autokreditraten auszusehen. Wenn deine Hosting-Rechnung für eine Marketing-Website deine eigentlichen Cloud-Infrastrukturkosten übertrifft, stimmt etwas nicht. Das war der Punkt, an dem ich anfing, mich in OpenNext zu vertiefen. Nach der Migration von drei Produktions-Apps von Vercel im letzten Jahr habe ich dazu eine Meinung.

Dies ist kein "Vercel ist schlecht"-Artikel. Vercel ist wirklich ausgezeichnet. Aber es ist nicht mehr die einzige Option, und für viele Teams ist es nicht die richtige. Lass mich dich durch alles führen, was ich über das Selbst-Hosting von Next.js mit OpenNext gelernt habe — das Gute, das Hässliche und das überraschend Erschwingliche.

Inhaltsverzeichnis

• Was ist OpenNext und warum existiert es
• Die Self-Hosting-Landschaft 2025-2026
• Deployment-Ziel: AWS mit SST
• Deployment-Ziel: Cloudflare Workers
• Deployment-Ziel: VPS mit Docker
• Kostenvergleich: Vercel vs. Self-Hosted
• Wann man Vercel verlässt
• Das Migrations-Playbook
• Häufige Fallstricke und wie man sie vermeidet
• FAQ

Was ist OpenNext und warum existiert es

Next.js wurde entwickelt, um auf Vercel zu laufen. Das ist keine Verschwörung — das ist Architektur. Features wie ISR (Incremental Static Regeneration), Middleware, Image-Optimierung und Server Actions haben alle Vercel-spezifische Implementierungen eingebaut. Wenn du versuchst, next start auf einem zufälligen Server auszuführen, bekommst du nur eine Teilmenge dessen, was Next.js kann.

OpenNext ist ein Open-Source-Adapter, der deine Next.js-Build-Ausgabe nimmt und sie in Deployment-Pakete umwandelt, die auf anderen Plattformen funktionieren. Es begann als SST-Community-Projekt, das sich auf AWS Lambda konzentrierte, aber ab v3 (die aktuelle Hauptversion 2025) unterstützt es mehrere Deployment-Ziele, einschließlich Cloudflare Workers, traditioneller Node.js-Server und mehr.

Das ist, was OpenNext tatsächlich handhabt:

• ISR und Revalidierung — Das Tag-basierte Revalidierungssystem, das Vercel mit ihrer internen Infrastruktur implementiert? OpenNext recreiert es mit DynamoDB + SQS auf AWS oder KV-Stores auf Cloudflare.
• Image-Optimierung — Die Next.js-<Image>-Komponente basiert auf einer Optimierungs-API. OpenNext packt einen Sharp-basierten Optimizer oder leitet zu plattformspezifischen Lösungen weiter.
• Middleware — Läuft am Edge auf Vercel. OpenNext bildet dies auf CloudFront Functions, Cloudflare Workers oder lokale Ausführung auf VPS ab.
• Server Actions — Vollständige Unterstützung, weitergeleitet durch die entsprechende Server-Funktion.
• Streaming und teilweises Prerendering — Die Unterstützung hat sich in OpenNext v3.x erheblich verbessert.

Was OpenNext nicht ist

Es ist keine Hosting-Plattform. Es ist kein CDN. Es ist ein Build-Adapter — eine Übersetzungsschicht zwischen Next.js's Ausgabe und deiner Infrastruktur. Du musst das Ding immer noch irgendwo tatsächlich ausführen.

Die Self-Hosting-Landschaft 2025-2026

Das Ökosystem ist explodiert, seit ich mich anfangs damit beschäftigt habe. So sieht es derzeit aus:

Plattform	OpenNext-Unterstützung	Reife	Am besten für
AWS (über SST)	First-class	Produktionsreife	Teams bereits auf AWS
Cloudflare Workers	Offizieller Adapter	Stabil (einige Randfälle)	Edge-First-Apps, Kostenoptimierung
Docker/VPS	Community + offiziell	Stabil	Einfache Deployments, existierende Infrastruktur
Kubernetes	Community Helm-Charts	Reifend	Enterprise, existierende K8s-Cluster
Netlify	Eingebaut (eigener Adapter)	Produktionsreife	Netlify-committed Teams
Google Cloud Run	Community	Experimentell	GCP-Shops

Die zwei Pfade, die ich persönlich getestet und befürworten kann, sind AWS über SST und Docker auf einem VPS. Cloudflare ist der aufregende Newcomer, der monatlich besser wird.

Deployment-Ziel: AWS mit SST

Dies ist der goldene Weg. SST (Serverless Stack) hat eingebaute Next.js-Unterstützung mit OpenNext und es ist dort, wo die meiste Engineering-Anstrengung unternommen wurde.

Architektur-Übersicht

Wenn du Next.js über SST auf AWS bereitstellst, wird Folgendes erstellt:

• CloudFront-Verteilung — Dein CDN, handhabt statische Assets und Routing
• Lambda-Funktion(en) — Server-Side Rendering, API Routes, Server Actions
• S3-Bucket — Statische Assets, vorab gerenderte Seiten, ISR-Cache
• DynamoDB-Tabelle — ISR-Tag-Mapping für Revalidierung
• SQS-Queue — Asynchrone Revalidierungsverarbeitung
• CloudFront Function oder Lambda@Edge — Middleware-Ausführung

Klingt nach viel. Ist es. Aber SST abstrahiert all das auf etwa 20 Zeilen Config.

SST-Konfiguration

Hier ist eine echte sst.config.ts aus einem meiner Produktionsprojekte:

/// <reference path="./.sst/platform/config.d.ts" />

export default $config({
  app(input) {
    return {
      name: "my-nextjs-app",
      removal: input.stage === "production" ? "retain" : "remove",
      home: "aws",
      providers: {
        aws: {
          region: "us-east-1",
        },
      },
    };
  },
  async run() {
    const site = new sst.aws.Nextjs("Site", {
      domain: {
        name: "myapp.com",
        dns: sst.aws.dns(),
      },
      warm: 5, // keep 5 Lambda instances warm
      memory: "1024 MB",
      environment: {
        DATABASE_URL: process.env.DATABASE_URL!,
        NEXT_PUBLIC_API_URL: "https://api.myapp.com",
      },
    });

    return {
      url: site.url,
    };
  },
});

Dann deployen:

npx sst deploy --stage production

Erstes Deployment dauert 8-12 Minuten (CloudFront-Verteilungsausbreitung). Nachfolgende Deployments dauern 2-4 Minuten.

Lambda-Überlegungen

Der größte Fallstrick beim Lambda-basierten Hosting sind Cold Starts. Next.js-Server-Funktionen sind nicht klein — du schaust auf 20-80MB Bundles je nach deinen Abhängigkeiten. Cold Starts liegen zwischen 800ms und 3 Sekunden.

Mitigationen, die ich verwendet habe:

1. Bereitgestellte Concurrency — SSTs warm-Parameter hält Instanzen aktiv. Bei $0,0000041667 pro GB-Sekunde kostet das Halten von 5 Instanzen einer 1GB-Funktion warm etwa $15/Monat.
2. Kleinere Bundles — Überprüfe deine serverseitigen Abhängigkeiten. Ich fand ein Projekt, das lodash serverseitig importierte, obwohl wir nur lodash/get brauchten. Bundle sank von 68MB auf 31MB.
3. Regionales Deployment — Verwende Lambda@Edge nicht für SSR, es sei denn, du brauchst es unbedingt. Single-Region Lambda mit CloudFront-Caching ist für 95% der Apps ausreichend.

Deployment-Ziel: Cloudflare Workers

Cloudflare macht ernsthafte Fortschritte. Ihre Workers-Laufzeit unterstützt jetzt genug Node.js-APIs, damit Next.js dort tatsächlich ausgeführt werden kann, und der OpenNext Cloudflare-Adapter ist bemerkenswert stabil geworden.

Setup mit OpenNext Cloudflare

npm install @opennext/cloudflare

Füge zu deiner wrangler.toml hinzu:

name = "my-nextjs-app"
main = ".open-next/worker.js"
compatibility_date = "2025-01-01"
compatibility_flags = ["nodejs_compat_v2"]

[assets]
directory = ".open-next/assets"
binding = "ASSETS"

[[kv_namespaces]]
binding = "NEXT_CACHE_KV"
id = "your-kv-namespace-id"

Baue und deploye:

npx @opennext/cloudflare build
npx wrangler deploy

Die Cloudflare-Kompromisse

Vorteile:

• Keine Cold Starts — Workers spinnen in unter 5ms global auf
• Global Edge standardmäßig — Dein SSR läuft an 300+ Orten
• Absurdes Pricing — $5/Monat für 10 Millionen Anfragen im bezahlten Plan

Nachteile:

• Speicherlimits — 128MB kostenlos, 256MB bezahlt. Große Next.js-Apps können dies treffen.
• CPU-Zeit-Limits — 30 Sekunden im bezahlten Plan. Schwere SSR-Seiten können ein Problem sein.
• Node.js-Kompatibilitätslücken — Die meisten Dinge funktionieren, aber wenn du native Node-Module wie sharp direkt verwendest, brauchst du Workarounds. Cloudflare Images kann Optimierung stattdessen handhaben.
• Einige Next.js-Features werden nicht unterstützt — Ab Anfang 2025 ist die Unterstützung für teilweises Prerendering auf Cloudflare immer noch experimentell.

Für inhaltsreiche Websites und Marketing-Seiten ist Cloudflare Workers unglaublich überzeugend. Für komplexe Web-Apps mit schwerer serverseitiger Logik würde ich immer noch zu AWS oder Docker neigen.

Deployment-Ziel: VPS mit Docker

Manchmal möchtest du einfach einen Server. Keine Lambda-Funktionen, keine Edge-Laufzeit, keine 47-Service-Architektur-Diagramme. Ein Box, der deinen Code ausführt. Ich respektiere das.

Das Dockerfile

Hier ist das Production-Dockerfile, das ich verwende. Es ist mehrstufig, optimiert und funktioniert tatsächlich:

# Stage 1: Dependencies
FROM node:20-alpine AS deps
RUN apk add --no-cache libc6-compat
WORKDIR /app
COPY package.json pnpm-lock.yaml ./
RUN corepack enable pnpm && pnpm install --frozen-lockfile

# Stage 2: Build
FROM node:20-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .

ENV NEXT_TELEMETRY_DISABLED=1
ENV NODE_ENV=production

RUN corepack enable pnpm && pnpm build

# Stage 3: Production
FROM node:20-alpine AS runner
WORKDIR /app

ENV NODE_ENV=production
ENV NEXT_TELEMETRY_DISABLED=1

RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs

COPY --from=builder /app/public ./public
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static

USER nextjs

EXPOSE 3000
ENV PORT=3000
ENV HOSTNAME="0.0.0.0"

CMD ["node", "server.js"]

Kritisch: Du brauchst output: 'standalone' in deiner next.config.js:

/** @type {import('next').NextConfig} */
const nextConfig = {
  output: 'standalone',
};

module.exports = nextConfig;

VPS-Empfehlungen

Ich habe dieses Setup bei mehreren Anbietern betrieben:

Anbieter	Spezifikation	Monatliche Kosten	Notizen
Hetzner CAX21	4 vCPU ARM, 8GB RAM	€7,49 (~$8)	Bestes Preis-Leistungs-Verhältnis, EU-Rechenzentren
DigitalOcean Droplet	2 vCPU, 4GB RAM	$24	Gute US-Abdeckung
Fly.io (machine)	2 vCPU, 4GB RAM	~$30	Auto-Scaling, globale Regionen
Railway	Nutzungsbasiert	$5-50	Einfachstes Setup, Vercel-ähnliche DX
AWS EC2 t4g.medium	2 vCPU, 4GB RAM	~$25	Bereits auf AWS

Für ein einfaches Docker-Deployment ist Hetzner absurd werthaltig. Ich betreibe eine Next.js-App, die 2M+ Seitenaufrufe/Monat bedient, auf einer €7,49 Hetzner ARM-Instanz hinter Cloudflare's kostenlosem CDN-Tier. Der Server kommt kaum ins Schwitzen.

Was du mit Docker/VPS verlierst

Lass uns ehrlich sein, was next start auf einem VPS dir nicht gibt im Vergleich zu Vercel oder dem SST-Setup:

• ISR-Revalidierung ist grundlegend — Nur Dateisystem-Cache. Kein verteilter Cache über mehrere Instanzen. Wenn du einen einzelnen Server betreibst, ist das in Ordnung. Multi-Server? Du brauchst Redis oder eine gemeinsame Cache-Ebene.
• Keine Edge-Middleware — Middleware läuft in-process, was völlig in Ordnung ist für die meisten Anwendungsfälle.
• Image-Optimierung — Funktioniert über Sharp, aber du bedienst optimierte Bilder von deinem einzelnen Origin. Stelle Cloudflare oder ein CDN davor.
• Keine atomaren Deployments — Du musst Zero-Downtime-Deployments selbst handhaben (Docker Compose mit Health Checks oder ein Reverse Proxy wie Caddy/Traefik).

Für die meisten Apps bei Social Animal, besonders die Headless-CMS-Builds, die wir durch unsere Headless-CMS-Entwicklung machen, ist ein einzelner VPS mit einem CDN davor völlig ausreichend.

Kostenvergleich: Vercel vs. Self-Hosted

Lass uns übers Geld sprechen. Dies basiert auf echten Abrechnungsdaten von einer Next.js-App, die ~5M Anfragen/Monat mit ISR, Image-Optimierung und moderatem Server-Side Rendering macht.

Kostenfaktor	Vercel Pro	Vercel Enterprise	AWS/SST	Cloudflare	Hetzner VPS
Base-Plattform	$20/Benutzer/Monat	Benutzerdefiniert (~$3k+/Monat)	$0	$5/Monat	€7,49/Monat
Compute/Anfragen	$150-400/Monat	Enthalten	$40-80/Monat	$0-15/Monat	Enthalten
Bandbreite (100GB)	Enthalten	Enthalten	$8,50 (CloudFront)	Enthalten	Enthalten
Image-Optimierung	$50-200/Monat	Enthalten	$5-15/Monat (Lambda)	$5/Monat (CF Images)	Enthalten (Sharp)
ISR/Cache	Enthalten	Enthalten	$2-5/Monat (DynamoDB)	$0-5/Monat (KV)	$0
Geschätzter Gesamtbetrag	$300-700/Monat	$3.000+/Monat	$55-110/Monat	$10-25/Monat	$8-15/Monat

Diese Vercel-Nummern sind nicht hypothetisch. Ich habe die Rechnungen gesehen. Die Pro-Tier-Kosten pro Benutzersitz, Funktionsausführungs-Overages und Bandbreitengebühren summieren sich schnell für Teams mit 5+ Mitgliedern.

Die AWS/SST-Nummern gehen von moderatem Traffic mit bereitgestellter Concurrency aus. Cloudflares Preismodell ist wirklich verrückt — es ist schwer, echtes Geld dort auszugeben, es sei denn, du machst etwas Exotisches.

Wann man Vercel verlässt

Verlasse nicht einfach, weil du kannst. Verlasse, weil du solltest. Hier ist mein Rahmen:

Bleibe bei Vercel, wenn:

• Dein Team ist klein (1-3 Entwickler) und Entwicklerzeit ist deine teuerste Ressource
• Du gibst unter $100/Monat für Vercel aus
• Du niemanden hast, der gerne Infrastruktur-Arbeit macht
• Du iterierst schnell und brauchst sofortige Previews für jeden PR
• Du Vercel-spezifische Features wie Analytics, Speed Insights oder Vercel AI SDK-Integrationen verwendest

Verlasse Vercel, wenn:

• Monatliche Rechnung überschreitet $500 und wächst
• Du brauchst Infrastruktur in bestimmten Regionen für Compliance (GDPR, Datenspeicherung)
• Du betreibst bereits erhebliche AWS/GCP/Cloudflare-Infrastruktur
• Cold Starts auf Serverless sind für deinen Anwendungsfall inakzeptabel
• Du brauchst benutzerdefinierte Caching-Strategien, die nicht zu Vercels Modell passen
• Du hast Vercels Funktionsgröße-Limits oder Execution-Time-Limits erreicht

Überdenke ernsthaft Vercel zu verlassen, wenn:

• Du bist auf Vercel Enterprise Pricing und die Vertragserneuerung kam gerade herein
• Deine App ist größtenteils statisch/ISR und du zahlst Preise für dynamisches SSR
• Du dein Frontend neben deinem Backend in der gleichen Infrastruktur betreiben möchtest

Das Migrations-Playbook

Ich habe das dreimal gemacht. Hier ist der Prozess, dem ich folge, verfeinert durch schmerzhafte Erfahrung.

Schritt 1: Überprüfe deine Next.js-Features

Bevor du etwas berührst, katalogisiere, welche Next.js-Features du tatsächlich verwendest:

# Finde Middleware
find . -name "middleware.ts" -o -name "middleware.js"

# Finde API Routes
find ./app -name "route.ts" -o -name "route.js" | head -20

# Überprüfe auf ISR
grep -r "revalidate" ./app --include="*.ts" --include="*.tsx" | head -20

# Überprüfe auf Server Actions
grep -r "use server" ./app --include="*.ts" --include="*.tsx" | head -20

# Überprüfe next.config auf spezielle Features
cat next.config.js

Schritt 2: Wähle dein Ziel

Basierend auf der Überprüfung:

• Heavy ISR + Middleware + Image-Optimierung → AWS/SST
• Einfaches SSR + Content-Site → Cloudflare oder VPS
• Bereits Docker/K8s-Infrastruktur vorhanden → VPS/Docker
• Muss bis Freitag erledigt sein → Docker auf Railway oder Fly.io

Wenn du mit Next.js oder Astro baust, beeinflusst die Wahl der Zielplattform deine Architektur-Entscheidungen erheblich.

Schritt 3: Richte CI/CD ein

Vercels CI/CD ist wirklich großartig. Du wirst es vermissen. Repliziere es mit GitHub Actions:

# .github/workflows/deploy.yml
name: Deploy
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: pnpm/action-setup@v4
        with:
          version: 9

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'

      - run: pnpm install --frozen-lockfile
      - run: pnpm build
      - run: pnpm test

      # Für SST:
      - run: npx sst deploy --stage production
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

      # Für Docker/VPS (Alternative):
      # - run: docker build -t myapp .
      # - run: docker push registry.example.com/myapp:latest
      # - run: ssh deploy@server 'cd /app && docker compose pull && docker compose up -d'

Schritt 4: Preview-Deployments

Das ist das eine, das Leute am meisten von Vercel vermissen. Für SST, verwende Stages:

# In deinem PR-CI-Workflow
npx sst deploy --stage pr-${{ github.event.pull_request.number }}

Für Docker, Tools wie Coolify (Self-Hosted) oder Railway handhaben Preview-Deployments gut.

Schritt 5: DNS-Umschaltung

Der eigentliche Migrations-Moment. Ich empfehle immer:

1. Deploye zur neuen Infrastruktur neben Vercel
2. Teste gründlich mit einer Staging-Domain
3. Senke DNS-TTL auf 60 Sekunden einen Tag vorher
4. Schalte DNS während Zeiten mit wenig Traffic um
5. Halte Vercel-Deployment für 48 Stunden als Fallback laufen
6. Überwache Fehlerraten, TTFB und Core Web Vitals genau

Schritt 6: Vercel abreißen

Sobald du sicher bist (gib dem mindestens eine Woche), kündige das Vercel-Abonnement und entferne das Projekt. Hinterlasse keine Zombie-Projekte, die Gebühren aufhäufen.

Häufige Fallstricke und wie man sie vermeidet

Umgebungsvariablen verschwinden. Next.js hat NEXT_PUBLIC_ prefixed Vars (gebündelt zum Build-Zeit) und nur-Server Vars (verfügbar zur Laufzeit). Bei Vercel ist diese Unterscheidung etwas verschwommen. Bei Self-Hosted ist sie streng. Stelle sicher, dass alle NEXT_PUBLIC_ Vars zur Build-Zeit verfügbar sind in deinem CI.

ISR-Cache persistiert nicht. Auf Docker muss das .next/cache Verzeichnis auf einem persistenten Volume sein. Andernfalls verlierst du bei jedem Container-Restart deine gecachten Seiten:

# docker-compose.yml
services:
  web:
    build: .
    ports:
      - "3000:3000"
    volumes:
      - next-cache:/app/.next/cache

volumes:
  next-cache:

Sharp-Installationsfehler. Die sharp Image-Optimierungs-Bibliothek braucht plattformspezifische Binaries. In Docker stelle sicher, dass du Abhängigkeiten in der gleichen Architektur wie deine Laufzeit installierst. Das obige Dockerfile handhabt dies mit mehrstufigen Builds mit dem gleichen Basis-Image.

Middleware-Verhaltensunterschiede. Vercel führt Middleware auf ihrem Edge-Netzwerk aus. Auf AWS/SST läuft sie als CloudFront Function (limitiert auf 10ms Ausführung, 2MB Größe). Komplexe Middleware müssen möglicherweise zur Server-Funktion verschoben werden. Ich musste Auth-Middleware wegen dieser Limits umgestalten.

Fehlende Header und Rewrites. Falls du auf vercel.json für Header, Redirects oder Rewrites angewiesen warst, musst du diese zu next.config.js oder deiner CDN/Reverse-Proxy-Konfiguration verschieben.

Wenn all das überwältigend wirkt, das ist genau die Art von Infrastruktur-Arbeit, die wir bei Social Animal handhaben. Schaue dir unser Pricing an oder kontaktiere uns — wir haben diese Migrationen oft genug gemacht, um einen verfeinerten Prozess zu haben.

FAQ

Ist OpenNext 2025 produktionsreife? Ja. OpenNext v3.x läuft Produktions-Workloads für tausende Unternehmen. Der SST/AWS-Pfad ist am meisten erprobt, mit Cloudflare-Unterstützung dicht dahinter. Ich würde die Unterstützung für Google Cloud oder bare Kubernetes noch nicht reif nennen, aber AWS und Cloudflare sind solide.

Unterstützt OpenNext Next.js App Router und Server Components? Volle Unterstützung. App Router, Server Components, Server Actions, Streaming und Suspense funktionieren alle. Das OpenNext-Team verfolgt Next.js-Releases genau, obwohl es typischerweise einen 1-3-Wochen-Lag nach Hauptversionen gibt, bevor OpenNext aufgeholt hat.

Wie viel kann ich tatsächlich sparen, indem ich Vercel verlasse? Das hängt stark von deinen Nutzungsmustern ab. Für ein Team von 5 Entwicklern, das eine moderat-Traffic-App betreibt, habe ich Teams von $600-800/Monat auf Vercel Pro zu $30-80/Monat auf AWS/SST oder unter $20/Monat auf einem VPS wechseln sehen. Die Einsparungen sind real, aber so ist auch die zusätzliche Wartungslast.

Kann ich ISR (Incremental Static Regeneration) ohne Vercel verwenden? Absolut. Auf AWS/SST verwendet ISR DynamoDB für den Tag-Cache und SQS für asynchrone Revalidierung — es ist vollständig funktionsfähig, einschließlich On-Demand-Revalidierung via revalidateTag() und revalidatePath(). Auf einem VPS funktioniert ISR mit dem Dateisystem-Cache, was für Single-Server-Deployments ausreicht.

Was ist mit Vercels Preview-Deployments? Kann ich die replizieren? Du kannst 80% des Erlebnis reproduzieren. SST unterstützt stage-basierte Deployments, also kann jeder PR seinen eigenen Stack bekommen. Coolify und ähnliche Tools bieten Preview-Deployments für Docker-basierte Setups. Was du nicht leicht reproduzieren wirst, ist Vercels visuelles Kommentar-System und die enge GitHub-Integration für Deployment-Status. Die meisten Teams finden den Kompromiss akzeptabel.

Sollte ich OpenNext mit Cloudflare oder AWS für eine Headless-CMS-Site verwenden? Für inhaltsreiche Headless-CMS-Sites (Sanity, Contentful, Storyblok) ist Cloudflare Workers eine ausgezeichnete Wahl. Diese Sites neigen zu ISR-lastig mit relativ leichter serverseitiger Logik — perfekt für Cloudflares Preismodell. Ich würde nur zu AWS gehen, wenn du Features brauchst, die Cloudflare noch nicht unterstützt, oder wenn du bereits tief im AWS-Ökosystem bist.

Ist Self-Hosting von Next.js schwerer als Self-Hosting von Astro oder Remix? Ehrlich gesagt? Ja. Next.js hat die komplexeste Build-Ausgabe aller Frameworks wegen Features wie ISR, Middleware, Image-Optimierung und teilweisem Prerendering. Astro und Remix haben viel einfachere Deployment-Stories. Wenn du ein neues Projekt startest und Self-Hosting ist eine Priorität, betrachte Astro — es ist dramatisch einfacher zu hosten. Aber wenn du bereits auf Next.js bist, macht OpenNext die Migration praktisch.

Was passiert, wenn OpenNext nicht mehr gepflegt wird? OpenNext wird von SST unterstützt und hat eine aktive Community mit Hauptsponsoren. Das ist dennoch eine legitime Besorgnis für jede Open-Source-Abhängigkeit. Die Mitigation ist, dass der Docker/Standalone-Ansatz (next start) ohne OpenNext überhaupt funktioniert — du verlierst einfach einige der fortgeschritteneren Features wie ISR-Tag-Revalidierung und Edge-Middleware. Es ist eine sanfte Verschlechterung, keine Klippe.