Vinext im Überblick: die auf Vite basierende Next.js-Alternative

Vinext ist ein Open-Source-Vite-Plugin von Cloudflare, das die Next.js-API neu implementiert. Eine bestehende Codebasis mit App Router oder Pages Router lässt sich damit über Vite statt über die Next.js-Toolchain bauen und ausliefern. Cloudflare hat Version 1.0 am 28. September 2026 angekündigt.

Viele Teams schätzen Next.js, nicht aber das Hosting, in das sie damit gedrängt werden. Gleichzeitig ist es schwer zu rechtfertigen, eine große Anwendung nur für einen Hosting-Wechsel auf ein anderes Framework zu portieren. Vinext bietet einen anderen Weg. Dieser Artikel zeigt, was Vinext unterstützt, wohin sich damit deployen lässt, mit welchen Befehlen Sie es an Ihrer eigenen Anwendung testen und welche Lücken Cloudflare selbst dokumentiert.

Was ist Vinext und wie unterscheidet es sich von anderen Next.js-Alternativen?

Vinext ist eine Neuimplementierung von Next.js auf Basis von Vite durch Cloudflare. Das Projekt begann im Februar 2026 als einwöchiges, KI-gestütztes Experiment und erreichte sieben Monate später Version 1.0. Das README stellt ausdrücklich klar, dass es sich nicht um einen Fork handelt: Der Kern wurde von Grund auf neu geschrieben, um der öffentlichen Next.js-API zu entsprechen.

Damit ist Vinext eine andere Art von Option als die üblichen Next.js-Alternativen. Ein Umstieg auf React Router, Astro oder SvelteKit bedeutet, Routen, Data Loading und Komponenten neu zu schreiben. Vinext lässt diesen Code unangetastet und ändert nur, was ihn baut und ausliefert. Ihr Projekt sieht weiterhin wie ein Next.js-Projekt aus – darunter erledigt Vite die Arbeit.

Was unterstützt Vinext?

Vinext deckt beide Router sowie die wichtigsten Server-Features des modernen Next.js ab. Die Ankündigung zu 1.0 und das README nennen Unterstützung für:

• App Router, Pages Router und hybride Anwendungen, die beide nutzen
• React Server Components und Server Actions
• Middleware, API-Routen und Route Handler
• ISR-Revalidierung
• Prerendering zur Build-Zeit über generateStaticParams() und getStaticPaths()
• Statischen Export mit output: "export"

Das README zielt auf Next.js 16.x ab und führt vite ^8.0.0 als Peer Dependency auf.

Cloudflare gibt die Next.js-Kompatibilität von Vinext auf zwei verschiedene Arten an, und die beiden Zahlen messen nicht dasselbe. Der Beitrag zu 1.0 nennt über 99 % Testkompatibilität, allerdings nur für die von Kunden am häufigsten nachgefragten Features und unter Ausklammerung der Cache Components. Das README gibt an, dass „rund 94 % der API-Oberfläche von Next.js 16 vollständig oder teilweise unterstützt werden“. Beide Werte stammen von Cloudflare. Keiner davon ersetzt einen Test mit Ihrer eigenen Anwendung.

Wohin lässt sich Vinext deployen?

Vinext deployt nativ auf Cloudflare Workers, und laut dem Beitrag zu 1.0 läuft es auch im kostenlosen Workers-Tarif. Derselbe Beitrag nennt Netlify und AWS Lambda als Deployment-Ziele. Das README erläutert den Mechanismus: Workers wird direkt über @vinext/cloudflare bedient, während Vercel, Netlify, AWS und Deno Deploy über das zusätzliche Nitro-Vite-Plugin angebunden werden. Ein nativer Adapter für Netlify oder Lambda kommt dabei nicht zum Einsatz.

Eine minimale Konfiguration fügt ein einziges Plugin hinzu:

// vite.config.ts
import { defineConfig } from "vite";
import vinext from "vinext";

export default defineConfig({
  plugins: [vinext()],
});

Um einen Host außerhalb von Cloudflare anzusteuern, installieren Sie nitro und fügen dessen Plugin hinzu:

// vite.config.ts
import { defineConfig } from "vite";
import vinext from "vinext";
import { nitro } from "nitro/vite";

export default defineConfig({
  plugins: [vinext(), nitro()],
});

npm install nitro
NITRO_PRESET=netlify npx vite build

So testen Sie Vinext an einer bestehenden Next.js-Anwendung

Um Vinext an einer bestehenden Anwendung zu testen, genügen zwei Befehle, und keiner davon beeinträchtigt Ihren bisherigen Next.js-Workflow. Führen Sie sie in einem eigenen Branch aus:

npx vinext check
npx vinext init

vinext check analysiert das Projekt und meldet bekannte Inkompatibilitäten, bevor Sie etwas ändern. vinext init arbeitet nicht-destruktiv, sodass next dev parallel zum neuen Setup weiter funktioniert. Der Befehl fragt nach einem Deployment-Ziel und verwendet standardmäßig Cloudflare. Seit dem Release 1.0 nutzen Cloudflare-Setups standardmäßig die cf CLI mit einer typisierten cloudflare.config.ts. Wenn Sie stattdessen beim älteren Wrangler-Setup bleiben möchten, übergeben Sie --legacy-wrangler-cloudflare-init.

Eine neue Vinext-Anwendung erstellen

Bei einem Greenfield-Projekt erzeugen Sie zunächst das Grundgerüst der Anwendung, starten sie, bauen sie und deployen sie anschließend:

npm create vinext-app@latest my-app
npx vite dev
npx vite build
npx @vinext/cloudflare deploy

Mit Release 1.0 erhält der Deploy-Befehl das Flag --warm-cache. Es lädt die neue Version mit 0 % des Traffics hoch, ruft die cachebaren Seiten darüber ab, um die Caches zu befüllen, und schaltet die Version erst danach live.

Welche Einschränkungen und bekannten Lücken hat Vinext?

Der Abschnitt „Known gaps“ im README nennt vier Bereiche, in denen Vinext noch nicht mit Next.js übereinstimmt: Cache Components, Bild- und Font-Optimierung zur Build-Zeit, native Module in der App-Router-Entwicklung sowie einige plattformspezifische Routenkonfigurationen. Laut Cloudflare wird an allen vier Punkten noch gearbeitet – es handelt sich also nicht um dauerhafte Einschränkungen.

• Cache Components und PPR: "use cache" funktioniert teilweise, das vollständige cacheComponents-Modell ist jedoch noch nicht fertiggestellt. Cache-Profile, Tags, partielle Shells, Resuming, Prefetching sowie Teile des Cachings in Dev und Build können sich noch anders verhalten als in Next.js.
• Bilder und Fonts: Auf Cloudflare können Bilder zum Zeitpunkt der Anfrage optimiert werden. Vinext bildet die vollständige Bild-Pipeline, die Next.js zur Build-Zeit ausführt, noch nicht nach, und Fonts werden zur Laufzeit geladen statt während des Builds verarbeitet.
• Native Module: Pakete wie sharp, resvg, satori, lightningcss und @napi-rs/canvas können in der RSC-Entwicklungsumgebung von Vite fehlschlagen. Produktions-Builds kommen mit mehr dieser Pakete zurecht als der Dev-Modus.
• Routenkonfiguration: Vinext ignoriert die Routeneinstellungen runtime und preferredRegion.

Das README weist zudem darauf hin, dass Vinext noch kein Drop-in-Ersatz für jede Anwendung ist.

Wer sollte Vinext einsetzen und wer sollte noch abwarten?

Vinext eignet sich für Teams, die weiterhin mit Next.js entwickeln möchten, ohne an einen bestimmten Host gebunden zu sein. Bei der Produktionsreife sind sich die Quellen nicht ganz einig: Die Ankündigung von Cloudflare bezeichnet 1.0 als produktionsreif, während das README mit „Ja, aber mit Vorsicht“ antwortet und darauf hinweist, dass Vinext noch Kompatibilitätslücken aufweist und sich noch nicht bei allen Arten von Next.js-Produktionsanwendungen bewährt hat.

• Einsetzen, wenn Ihre Anwendung beide Router, RSC, Server Actions und ISR nutzt und Sie auf Workers oder über Nitro deployen möchten.
• Abwarten, wenn Sie stark auf Cache Components, PPR oder "use cache"-Semantik wie Tags und Profile angewiesen sind.
• OpenNext in Betracht ziehen, wenn Sie bewährte Produktionsreife benötigen. Wie das README von Vinext erläutert, setzt OpenNext auf der Ausgabe von next build auf, deckt dadurch einen größeren Teil der Next.js-API ab und kann auf eine deutlich längere Erfolgsbilanz verweisen.

Fazit

Mit Vinext können Sie Vercel verlassen, ohne Ihre Next.js-Anwendung neu schreiben zu müssen. Dafür müssen Sie dokumentierte Lücken in Kauf nehmen, vor allem bei den Cache Components. Um zu prüfen, ob Vinext zu Ihrem Projekt passt, erstellen Sie einen Branch, führen npx vinext check aus, gleichen die gemeldeten Punkte mit den bekannten Lücken ab, führen dann npx vinext init aus und vergleichen das Verhalten mit next dev. Wenn Sie auch den Rest Ihrer Toolchain umstellen möchten, lesen Sie Getting Started with Vite+ (für Vite+-Projekte nennt das README vp exec vinext-cloudflare deploy). Zum cloudflare.config.ts-Workflow, den init einrichtet, empfiehlt sich der Artikel „A Practical Guide to Cloudflare’s New cf CLI“.

FAQs

Kann ich meine benutzerdefinierte webpack-Konfiguration oder mein next/jest-Setup beim Umstieg auf Vinext beibehalten?

Nein. Vinext läuft auf Vite, daher greifen Turbopack- und webpack-Konfigurationen nicht, und benutzerdefinierte webpack-Loader oder -Plugins müssen durch Vite-Plugins ersetzt werden. Das README von Vinext führt next/jest als nicht unterstützt auf und empfiehlt stattdessen Vitest. Auch AMP wird nicht unterstützt – useAmp() liefert stets false –, und der veraltete Befehl next export wird durch die Einstellung output: 'export' in der Next.js-Konfiguration ersetzt.

Welche Versionen von React und Vite benötigt Vinext?

Vinext deklariert Peer Dependencies auf react ^19.3.1, react-dom ^19.3.1, react-server-dom-webpack ^19.3.1 und vite ^8.0.0 und zielt auf Next.js 16.x ab. In App-Router-Projekten muss zusätzlich @vitejs/plugin-rsc installiert sein. Vinext registriert dieses Plugin automatisch, sobald es ein app-Verzeichnis erkennt. Ein eigener rsc()-Aufruf lässt den Build daher mit einem Fehler wegen doppelten Plugins scheitern, sofern Sie vinext() nicht rsc: false übergeben.

Was ändert vinext init an einem bestehenden Next.js-Projekt?

vinext init ergänzt 'type': 'module' in der package.json und benennt CommonJS-Konfigurationsdateien um, etwa postcss.config.js in postcss.config.cjs, um ESM-Konflikte zu vermeiden. Außerdem installiert es die Vite- und Vinext-Pakete und fügt neben den bestehenden Next.js-Skripten die Skripte dev:vinext, build:vinext und start:vinext hinzu. Da die ursprünglichen Skripte erhalten bleiben, können next dev und der Vinext-Dev-Server aus derselben Codebasis heraus parallel laufen und direkt verglichen werden.

Liefert revalidateTag in Vinext auf Cloudflare veraltete Seiten aus, während diese neu generiert werden?

Ja, seit den 1.1-Releases vom Oktober 2026, sofern Sie ein Cache-Profil übergeben, etwa revalidateTag(tag, 'max'). Frühere Releases haben passende Seiten aus dem Workers Cache gelöscht, sodass die nächste Anfrage auf ein vollständiges Rendering warten musste. Inzwischen markieren Workers Cache und Response Store diese Einträge als veraltet und liefern weiterhin die gecachte Version aus, während im Hintergrund neu generiert wird – genau wie in Next.js. Ein Aufruf von revalidateTag nur mit einem Tag oder mit expire: 0 lässt Einträge weiterhin sofort ablaufen. Auch veraltete 'use cache'-Einträge werden während der Neugenerierung weiter ausgeliefert.