Wir haben unsere Next.js-App mit vinext von Vercel zu Cloudflare gezügelt, und sie ist schneller geworden

DriveFlow läuft seit dem 27. Oktober 2026 auf Cloudflare Workers, gebaut mit vinext statt mit Next.js. Seiten hinter dem Login antworten bis zu einem Drittel schneller als auf Vercel, und auf einem langsamen Handy erscheint der Hauptinhalt auf jeder getesteten Seite früher.

DriveFlow ist unsere Plattform für Schweizer Fahrschulen: 89 Seiten, 44 Route Handler, eine proxy.ts, Login über Supabase und PDF-Rechnungen mit QR-Rechnung. Als wir nach jemandem suchten, der eine App in dieser Grösse umgezogen hat, fanden wir Pull Requests für Demos und persönliche Websites. Hier ist darum unserer.

Warum wir unsere Next.js-App von Vercel weggezogen haben

Ein Grund war Geld, der andere Distanz.

Der Hobby-Plan von Vercel ist für den persönlichen, nicht kommerziellen Gebrauch gedacht. DriveFlow wickelt Zahlungen für Fahrschulen ab, also hätte der Livegang Vercel Pro bedeutet: 20 Dollar pro Entwickler-Sitz und Monat.

Die Distanz wog schwerer. Unsere Supabase-Datenbank steht in Zürich, Vercel liess unsere Funktionen in Frankfurt laufen. proxy.ts ruft bei jeder Navigation hinter dem Login supabase.auth.getUser() auf, also wartete jede Seite, die ein Fahrlehrer öffnete, auf den Weg von Frankfurt nach Zürich und zurück. Cloudflare beantwortet Besucher aus der Schweiz aus seinem Standort in Zürich, und dort läuft auch der Worker.

Was der Umzug nicht ändert: von wem du abhängst. Vercel und Cloudflare sind beides US-Firmen. Wer die Verarbeitung bei Cloudflare strikt in der EU halten will, braucht die Data Localization Suite, und die gibt es nur im Enterprise-Plan. Für DSGVO und Schweizer DSG zählt vor allem, wo die Kundendaten liegen, und die lagen schon vorher in Zürich. Wo Daten verarbeitet werden, ist dieselbe Frage, die entscheidet, ob du ein KI-Modell auf Kundendaten loslassen darfst. Das haben wir in lokale KI-Modelle und Schweizer Datenschutz durchgespielt.

Was vinext ist und wie es sich von OpenNext unterscheidet

vinext ist Cloudflares Neuimplementierung der Next.js-API auf Vite. Es liest dasselbe app/-Verzeichnis, dieselbe next.config.ts und dieselben next/*-Imports und baut daraus einen Worker. OpenNext, der ältere Weg, nimmt stattdessen die Ausgabe von next build und übersetzt sie. Wir haben nur vinext versucht: Version 1.0 war gerade erschienen, und npx vinext check stufte DriveFlow als zu 98 Prozent kompatibel ein. Die fehlenden zwei Prozent waren das Build-Plugin von Sentry.

Der Preis von vinext ist klar. Es ist ein zweites Framework, das jedem Next.js-Release folgen muss, und es ist jung: Version 1.0 kam am 28. September 2026, getestet haben wir 1.3.0.

Vercel vs. Cloudflare: der Benchmark

Auf Vercel lief der normale Build mit Next.js 16, auf Cloudflare der vinext-Build desselben Commits, beide gegen dieselbe produktive Datenbank. Ein Skript rief jede Seite 30 Mal mit curl ab, abwechselnd auf beiden Hosts, damit beide dasselbe Netz sahen, und meldete sich dort, wo eine Seite es verlangt, mit echten Testkonten an.

Am meisten gewannen die Seiten, bei denen wir es erwartet hatten. Hinter dem Login geht die Auth-Abfrage jetzt von Zürich nach Zürich, und die Finanzseite für Inhaber sank von 185 auf 125 ms.

Im echten Browser mit schneller Desktop-Verbindung waren die Abstände meist klein: Die Startseite zeigte ihren Hauptinhalt auf Vercel nach 300 ms, auf Cloudflare nach 308 ms. Die Ausnahme war das Schulprofil mit 784 gegen 328 ms. Mit einem gedrosselten Handy-Profil wurde der Unterschied spürbar.

Dafür überträgt Cloudflare mehr. Im Handy-Profil waren es auf der Startseite 818 KB in 102 Anfragen, auf Vercel 734 KB in 38. vinext teilt das JavaScript in viele kleine Stücke und lädt den Code verlinkter Seiten nach dem Laden vor, das erste Bild wartet also nicht darauf. Auf einer Verbindung mit Datenlimit zählen die Bytes trotzdem.

Eine Einstellung ist Pflicht. Unser erster Build lief ohne Bildoptimierung, und die Startseite schickte 1186 KB Bilder statt 175 KB. Mit Cloudflare Images war ein Screenshot mit 640 Pixeln Breite als AVIF 23 KB gross, auf Vercel als WebP 24,5 KB.

Alle Zahlen stammen von einem Rechner in der Schweiz an einem Abend, dem 26. Oktober. Über Nutzer in der Schweiz sagen sie viel, über alle anderen nichts.

Was wir für Workers ändern mussten

Die meiste Arbeit hatte nichts mit vinext zu tun. Sie hatte mit Workers zu tun, und Workers ist kein Node.js: Es gibt weder Dateisystem noch Kindprozesse, und fetch verhält sich stellenweise anders.

Vor dem Wechsel sind wir jede Seite hinter dem Login als Inhaber, Fahrlehrer und Schüler durchgegangen und haben jede Datei, die die App erzeugt, auf beiden Hosts erzeugt. Dieselbe Rechnung mit QR-Rechnung, einmal von Vercel und einmal vom Worker, nebeneinander. Ein 200 sagt nichts darüber, ob ein PDF stimmt.

Was vinext anders macht und was es noch nicht kann

vinext selbst hat uns dreimal kurz überrascht. Es baut nicht, wenn zwei Seiten unter demselben Pfad liegen, was Next.js erlaubt; bei uns war es eine ungenutzte Seite in einer Route Group, die wir gelöscht haben. Es schreibt seine Cache-Regel für gehashte JavaScript-Dateien nur in _headers, wenn die Datei noch nicht existiert, und wenn ein anderes Plugin sie zuerst anlegt, bleibt jede Datei bei max-age=0; unser Build führt beide Regeln jetzt zusammen. Und es ruft register() in instrumentation.ts auf, ohne NEXT_RUNTIME zu setzen, also startete @sentry/nextjs auf dem Server nie, und @sentry/cloudflare hat dort übernommen. Keiner der drei Punkte stand im Issue-Tracker, als wir am 27. Oktober gesucht haben.

Ein paar offene Issues solltest du vor dem Wechsel lesen. Anfragen können in den Sekunden nach einem Deploy eine leere 503 bekommen. Es gibt keinen Skew-Schutz: Ein Tab, der vor einem Deploy geöffnet wurde, kann nach Code fragen, den es nicht mehr gibt. Vercel Hobby hatte allerdings auch keinen. Server Actions brechen in Tabs, die vor einem Deploy offen waren, was uns nicht trifft, weil DriveFlow keine verwendet. Und manche Muster in headers() greifen anders als in Next.js. Unsere haben wir auf dem Test-Worker geprüft, und wir prüfen sie nach jeder Änderung an der next.config.ts wieder.

Vercel vs. Cloudflare: Was kostet das ein kleines Team?

Vercel Pro kostet 20 Dollar pro Entwickler-Sitz und Monat, mit 20 Dollar Nutzung inklusive. Workers Paid kostet 5 Dollar pro Monat für das ganze Cloudflare-Konto, und Anfragen auf statische Dateien werden nicht verrechnet. Beim heutigen Verkehr von DriveFlow bleiben beide beim Grundpreis. Der Unterschied liegt also bei 15 Dollar pro Sitz und Monat und wächst mit dem Team und dem Verkehr.

Der Gratis-Plan von Workers kommt für eine App dieser Grösse nicht in Frage. Unser Server-Bundle ist komprimiert 4,5 MB gross, Workers Free erlaubt 3 MB, Paid 10 MB. Schneller gebaut wird auch: lokal 26 statt 34 Sekunden, vom Push bis in die Produktion 58 bis 75 statt 85 bis 100 Sekunden.

Lohnt sich der Wechsel weg von Vercel?

Wenn deine Nutzer und deine Datenbank in einer Region sitzen und Vercel deine Funktionen in einer anderen ausführt, zahlt sich der Umzug zuerst bei der Latenz aus und erst dann beim Geld. Wenn deine App stark auf Server Actions setzt oder heute schon Skew-Schutz braucht, wart, bis diese Issues geschlossen sind.

Wenn du es versuchst, halt dich an diese Reihenfolge. npx vinext check laufen lassen. Denselben Commit auf eine workers.dev-URL deployen und sie zuerst auf noindex setzen. Beide Hosts abwechselnd messen, nicht nacheinander. Dann alles, was eine Datei erzeugt, von PDFs bis zu Vorschaubildern, nebeneinanderlegen. Diesen letzten Schritt nimmt dir keine Testsuite ab.

Hat sich der Umzug weg von Vercel gelohnt?

Für uns ja. Die App ist für die Leute, die sie nutzen, schneller, und sie kostet weniger als der Vercel-Plan, den wir gebraucht hätten. Den Ausschlag gab das Kontomodell. Meinen Kollegen Nino ins Cloudflare-Konto einzuladen, kostete nichts, also arbeiten wir zu zweit in einem Konto mit einem Workers-Paid-Plan, vorerst für 5 Dollar im Monat. Cloudflare Tunnel ist ebenfalls gratis und gibt einem internen Dienst eine öffentliche Adresse, ohne dass ein Port offen sein muss. Darum blieb es nicht bei DriveFlow: Der Rest unserer Infrastruktur ist ins selbe Konto umgezogen.

Eine produktive App umziehen, ohne dass ihre Nutzer es merken, ist die Art Webentwicklung, die wir für Agenturen übernehmen. Das Audit, das DriveFlow vor dem Pilot durchlaufen hat, steht in was wir prüfen, bevor ein Betrieb damit arbeitet.