Next.js auf Cloudflare Workers: Edge-First Architektur in der Praxis

Warum Edge?

Traditionelle Next.js-Deployments laufen auf Node.js-Servern — sei es bei Vercel, auf einem eigenen VPS oder in einem Kubernetes-Cluster. Das funktioniert gut, hat aber einen grundlegenden Nachteil: Latenz zum Nutzer ist von der Serverregion abhängig.

Cloudflare Workers lösen dieses Problem durch Ausführung direkt am Edge — in über 300 Rechenzentren weltweit. Ein Nutzer in Wien spricht mit einem Worker in Frankfurt. Eine Anfrage aus São Paulo landet in Südamerika.

OpenNext + @opennextjs/cloudflare

Next.js ist nicht nativ für Cloudflare Workers ausgelegt. Die Bridge liefert @opennextjs/cloudflare — ein Adapter, der Next.js-Output in Workers-kompatiblen Code umwandelt.

// wrangler.jsonc
{
  "name": "my-next-app",
  "compatibility_date": "2024-09-23",
  "compatibility_flags": ["nodejs_compat"],
  "main": ".open-next/worker.js"
}

// open-next.config.ts
import type { OpenNextConfig } from "@opennextjs/cloudflare";

export default {
  default: {
    override: {
      wrapper: "cloudflare-node",
      converter: "edge",
    },
  },
} satisfies OpenNextConfig;

Die wichtigsten Tradeoffs

✅ Vorteile

• Globale Latenz: Konsistent niedrige Response Times worldwide
• Cold Start: Workers starten in < 5ms vs. 200–2000ms bei Lambda
• Kosten: Pay-per-Request ohne Idle-Kosten
• Integriertes CDN: Kein separates CDN nötig

⚠️ Einschränkungen

• Kein Node.js-Standard-APIs: fs, net, crypto (nur Web Crypto) eingeschränkt
• Kein Next.js Image Optimizer: images.unoptimized: true erforderlich
• Memory-Limit: 128 MB pro Worker-Invocation
• Kein Long-Running Code: Requests müssen in < 30s abgeschlossen sein

Infrastruktur als Code mit OpenTofu

Das gesamte Setup — DNS, R2-Bucket für State, Secrets — verwalten wir mit OpenTofu:

resource "cloudflare_workers_script" "app" {
  account_id  = var.cloudflare_account_id
  script_name = "haintz-dev"
  content     = file(".open-next/worker.js")
}

resource "cloudflare_workers_route" "app" {
  zone_id     = var.cloudflare_zone_id
  pattern     = "haintz.dev/*"
  script_name = cloudflare_workers_script.app.script_name
}

CI/CD-Pipeline

GitHub Actions übernimmt Build und Deployment automatisch bei jedem Push auf main:

1. ci.yml: TypeScript-Check, Lint, pnpm Build
2. deploy.yml: wrangler deploy nach erfolgreichem CI

Fazit

Edge-First-Architektur mit Cloudflare Workers ist produktionsreif und kosteneffizient. Die Einschränkungen sind überschaubar und für typische B2B-Webapplikationen kein Problem. Der Setup-Aufwand amortisiert sich durch niedrigere Infrastrukturkosten und bessere globale Performance schnell.