Vercel vs Cloudflare (Workers + Pages) Vergleich

Die Quelle von Next.js – liefert die neuesten Funktionen ohne Konfiguration und ohne Verzögerung

VS
Cloudflare (Workers + Pages)

Globales V8-Isolate-Netzwerk – Zero-Egress, jetzt mit eigener Next.js-Schicht vinext

15 Min. LesezeitDevOps

Schnelles Fazit

Es kommt auf die Situation an. Wenn du die neuesten Next.js-Funktionen ohne Verzögerung willst, wähle Vercel – das Paritätsrisiko ist null. Wenn du ein bandbreitenintensives, globales Projekt hast und Kostenvorhersehbarkeit priorisierst, ist Cloudflare die richtige Wahl; neben OpenNext gibt es inzwischen auch das noch in der Beta befindliche, aber sich schnell weiterentwickelnde vinext. Für kritische Workloads starte mit OpenNext, bei neuen Projekten probiere vinext aus.

VercelCloudflare (Workers + Pages)
Vollständiges Fazit lesen

Punktevergleich

Diagramm wird geladen...

Detaillierte Bewertung

Detaillierte Bewertung: Vercel und Cloudflare (Workers + Pages) — Bewertungen pro Kategorie auf einer Skala von 1 bis 10
KategorieVercelCloudflare (Workers + Pages)
Performance
8/10
9/10
Erlernbarkeit
9/10
6/10
Ökosystem
9/10
7/10
Community
9/10
8/10
Arbeitsmarkt
8/10
7/10
Zukunftssicherheit
8/10
8/10

Vor- und Nachteile

Vercel

Vorteile

  • Da das Unternehmen Next.js selbst entwickelt, reifen neue Funktionen (PPR, Turbopack, App Router) hier zuerst
  • Zero-Config-Deploy – ein git push genügt, Build/ISR/Edge-Middleware werden automatisch konfiguriert
  • 126 PoPs / 51 Länder CDN + 20 Compute-fähige Regionen für latenzarmes SSR
  • Active-CPU-Abrechnung mit Fluid Compute – bei wartenden I/O-Operationen wird nicht berechnet
  • Preview-Deployments automatisch für jeden PR, natürlich in Team-Workflows integriert
  • Offizielle Next.js-Cache-APIs (revalidateTag, revalidatePath) werden aus erster Hand unterstützt

Nachteile

  • Fast Data Transfer $0,15/GB (bei Pro sind die ersten 1 TB inkludiert) – bei bandbreitenintensiven Seiten steigen die Kosten schnell
  • Keine native relationale/Vektor-Datenbank; außer Blob Storage ist man für Daten auf externe Anbieter (Marketplace) angewiesen
  • SAML SSO ist bei Pro ein separates Add-on ($300/Monat); Directory Sync (SCIM) nur im Enterprise-Plan
  • Die Anzahl der Edge-PoPs (126) ist im Vergleich zu Cloudflares globalem Footprint begrenzter
  • Das funktionsbasierte Preismodell kann bei anfragereichen, CPU-armen Seiten teurer bleiben als bei Workers

Am besten geeignet für

Teams, die neue Next.js-Funktionen (PPR, Turbopack, Cache-APIs) ohne Verzögerung nutzen wollenStartups und Agenturen, die mit Zero-DevOps schnell iterierenProduktteams, die einen auf Preview-Deployments basierenden Team-Workflow wünschenCPU-intensive, aber mittelstark frequentierte SSR-Anwendungen

Cloudflare (Workers + Pages)

Vorteile

  • Keine Egress-/Bandbreitengebühr – abgerechnet werden nur Anfragen ($0,30/zusätzliche Million) und CPU-Zeit ($0,02/zusätzliche Million CPU-ms)
  • 95 % des Netzwerks liegen innerhalb von 50 ms zur Internetbevölkerung – sehr breite geografische Abdeckung
  • Die V8-Isolate-Architektur ist strukturell leichtgewichtiger beim Kaltstart als container-basierte Funktionen
  • Mit vinext werden inzwischen rund 94 % der Next.js-16-API-Oberfläche neu implementiert unterstützt
  • KV, R2, D1, Hyperdrive und Durable Objects halten Daten im selben Edge-Netzwerk
  • Mit Access for Workers (Aug. 2026) ist die Identitätsrichtlinie direkt an den Worker gebunden, unabhängig von Route/Preview-URL

Nachteile

  • vinext befindet sich in der Beta – vor der Einführung wird empfohlen, `npx vinext check` auszuführen; das GitHub-Repository sagt, es sei noch kein vollständiger Ersatz für jeden Produktions-Workload
  • Das ISR+PPR-R2-Cache-Backend des OpenNext-Adapters birgt das Risiko, nach ~24 Stunden zu veralten (Issue #662; mit Adapter-Version 1.0.2 gemeldet, weiterhin offen)
  • next/image-Optimierung wird nur teilweise unterstützt – in manchen Szenarien ist zusätzliche Konfiguration nötig
  • Da das Unternehmen nicht die Quelle von Next.js ist, kommen neue Framework-Funktionen später als bei Vercel
  • Grundgebühr $5/Monat plus Anfrage-/CPU-Zeit-Modell verringert die Vorhersehbarkeit bei Anwendungen mit geringem Traffic, aber hoher CPU-Last
  • Die OpenNext-/vinext-Schicht bringt zusätzlichen Betriebsaufwand (Adapter-Updates, Wahl des Cache-Backends) mit sich

Am besten geeignet für

Bandbreitenintensive Seiten (bild-/video-/API-lastig) – da Egress kostenlos ist, sind die Kosten vorhersehbarGlobale, mehrregionale NutzerbasenTeams, die eine einheitliche Datenebene mit KV/D1/R2/Hyperdrive bevorzugenInterne Multi-Route-Anwendungen, die eine zentrale Identitäts-/Zugriffsrichtlinie (Access) benötigen

Code-Vergleich

Vercel
// Vercel — Next.js 16 App Router, Cache Components (PPR standardmäßig) + On-Demand-Purge
// next.config.ts
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  cacheComponents: true,
};

export default nextConfig;

// app/blog/[slug]/page.tsx — mit 'use cache' + cacheTag gecachte Daten
import { cacheTag } from "next/cache";

async function getPost(slug: string) {
  "use cache";
  cacheTag(`post-${slug}`);
  const res = await fetch(`https://api.example.com/posts/${slug}`);
  return res.json();
}

export default async function BlogPost({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  const post = await getPost(slug);

  return (
    <article>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.html }} />
    </article>
  );
}

// app/api/revalidate/route.ts — On-Demand-Purge (Vercel Data Cache)
// "max" = stale-while-revalidate; für sofortiges Invalidieren per Webhook { expire: 0 }
import { revalidateTag } from "next/cache";
import { NextRequest, NextResponse } from "next/server";

export async function POST(req: NextRequest) {
  const { slug } = await req.json();
  revalidateTag(`post-${slug}`, "max");
  return NextResponse.json({ revalidated: true });
}

// vercel.json — Regionspräferenz und Funktionsdauer
{
  "regions": ["fra1"],
  "functions": {
    "app/api/revalidate/route.ts": { "maxDuration": 10 }
  }
}

// Deploy
// $ vercel --prod
Cloudflare (Workers + Pages)
// Cloudflare — Next.js 16 auf Workers deployen (vinext, offizieller Standardweg)
// 1) Zuerst Kompatibilität prüfen, dann zum Projekt hinzufügen (vinext init erzeugt die Vite-Config)
// $ npx vinext check
// $ npx vinext init

// vite.config.ts — Workers Cache für Route-Level-ISR, KV für Daten-Cache
import { cloudflare } from "@cloudflare/vite-plugin";
import { cdnAdapter } from "@vinext/cloudflare/cache/cdn-adapter";
import { kvDataAdapter } from "@vinext/cloudflare/cache/kv-data-adapter";
import { defineConfig } from "vite";
import vinext from "vinext";

export default defineConfig({
  plugins: [
    vinext({
      // cdnAdapter funktioniert nur, wenn in wrangler.jsonc "cache": { "enabled": true } gesetzt ist
      cache: { cdn: cdnAdapter(), data: kvDataAdapter() },
    }),
    cloudflare({
      viteEnvironment: { name: "rsc", childEnvironments: ["ssr"] },
    }),
  ],
});

// Deploy — erzeugt die Worker-Konfiguration selbst
// $ npx @vinext/cloudflare deploy

// Alternative: OpenNext-Adapter — open-next.config.ts
import { defineCloudflareConfig } from "@opennextjs/cloudflare";
import r2IncrementalCache from "@opennextjs/cloudflare/overrides/incremental-cache/r2-incremental-cache";

export default defineCloudflareConfig({ incrementalCache: r2IncrementalCache });
// $ opennextjs-cloudflare build && opennextjs-cloudflare deploy

// Access for Workers — Worker mit der Access-Anwendung verbinden
// POST /accounts/{account_id}/access/apps
// "destinations": [{ "type": "worker", "worker_id": "<worker-id>" }]

Fazit

Es kommt auf die Situation an. Wenn du die neuesten Next.js-Funktionen ohne Verzögerung willst, wähle Vercel – das Paritätsrisiko ist null. Wenn du ein bandbreitenintensives, globales Projekt hast und Kostenvorhersehbarkeit priorisierst, ist Cloudflare die richtige Wahl; neben OpenNext gibt es inzwischen auch das noch in der Beta befindliche, aber sich schnell weiterentwickelnde vinext. Für kritische Workloads starte mit OpenNext, bei neuen Projekten probiere vinext aus.

Kostenlose Beratung erhalten
FAQ

Häufig gestellte Fragen

Nicht vollständig, aber nah dran: Cloudflares neue vinext-Schicht unterstützt rund 94 % der Next.js-16-API-Oberfläche (App Router, Server Actions, ISR, Middleware) und ist der offizielle Standardweg – befindet sich aber noch in der Beta; die Dokumentation empfiehlt, vor der Einführung in einer bestehenden Produktionsanwendung `npx vinext check` auszuführen. Der ausgereiftere Adapter `@opennextjs/cloudflare` wiederum hat ein Veralterungsproblem im R2-Cache-Backend für ISR + Partial Prerendering (offenes GitHub-Issue).

Verwandte Blogartikel

Alle Artikel ansehen

Verwandte Projekte

Alle Projekte ansehen
Alle Vergleiche