Warum KI-Tools das falsche Framework für dein Projekt wählen

Du beschreibst einem KI-Tool eine App-Idee. Eine Stunde später hast du ein lauffähiges Projekt. Next.js, App Router, TypeScript, Tailwind. Alles kompiliert, alles sieht gut aus. Jetzt willst du es auf deinen Server stellen. Und genau hier fängt das eigentliche Projekt an.

KI-Coding-Assistenten wählen Next.js, weil React die Trainingsdaten dominiert. Next.js ist das meistverbreitete React-Meta-Framework, also liefern Claude, ChatGPT und Copilot es als Standard. Das ist kein Qualitätsurteil. Es ist ein statistischer Effekt. Und für ein Projekt, das du auf einem eigenen VPS hosten willst, ist es die schwierigere Wahl.

Dieser Artikel erklärt, warum. Und warum Nuxt für KI-generierte Projekte auf eigenem Server die ehrlichere Alternative ist.

Zwei Router in einem Framework

Next.js hat zwei grundverschiedene Routing-Systeme: den Pages Router und den App Router. Beide existieren parallel im selben Projekt. Der Pages Router nutzt getServerSideProps und getStaticProps für Daten. Der App Router nutzt React Server Components, async-Komponenten und ein völlig anderes mentales Modell.

Das Problem: Beide erscheinen massenhaft in den Trainingsdaten. KI-Assistenten mischen sie. Du bekommst getServerSideProps neben App-Router-Handlern im selben Projekt, oder "use client" an Stellen, wo es keine Wirkung hat. Der Code kompiliert. Und scheitert zur Laufzeit mit Fehlern, die für jemanden ohne Next.js-Erfahrung kryptisch sind.

Wenn du Vibe Coding gewählt hast, um schnell zu sein, willst du nicht als Erstes zwei Routing-Paradigmen debuggen.

React Server Components: Das unsichtbare mentale Modell

Der App Router baut auf React Server Components (RSC). Jede Komponente ist standardmäßig eine Server Component, es sei denn, du markierst sie explizit mit "use client". Das klingt einfach. In der Praxis hat es subtile Konsequenzen.

In Server Components kannst du keine Hooks verwenden. Du kannst keine Funktionen als Props über die Client-Server-Boundary übergeben. Event-Handler existieren nicht. Wenn eine KI-generierte Komponente useState in einer Server Component nutzt, kompiliert das. Es bricht erst zur Laufzeit. Der Fehler liest sich wie ein React-internes Problem, nicht wie "du hast vergessen, use client zu schreiben".

KI-Modelle liegen hier regelmäßig daneben, weil die RSC-Boundary unsichtbar ist. Es gibt kein Syntax-Highlight, kein Linting, das dir vorher sagt: Diese Komponente wird auf dem Server ausgeführt, jene im Browser. Du musst das Modell im Kopf haben. Oder die Fehler manuell aufräumen.

Sechs Rendering-Modi, pro Seite mischbar

Next.js bietet SSR, SSG, ISR, Partial Prerendering (PPR), Edge Runtime und Streaming. Alle pro Seite mischbar. Für erfahrene Teams ist das mächtig. Für KI-generierte Projekte ist es ein Minenfeld.

Das KI-Modell wählt pro Seite eine Strategie, basierend auf Pattern-Matching in den Trainingsdaten. Es gibt keine Garantie, dass die Strategien zusammenpassen. Du bekommst statische Seiten neben ISR-Seiten neben Edge-Seiten, und musst als Reviewer herausfinden, welche Strategie gewählt wurde und ob sie für dein Deployment-Setup funktioniert.

Auf einem VPS sieht die Realität so aus:

Vier Caching-Layer, wechselnde Defaults

Next.js stapelt vier Cache-Schichten übereinander: Request Memoization, Data Cache, Full Route Cache und Router Cache. Die Defaults haben sich zwischen Version 13, 14 und 15 geändert. Wer mit einem KI-Tool Code generiert, bekommt Code für die Version, die in den Trainingsdaten dominiert. Ob die Caching-Annahmen für deine installierte Version stimmen, erfährst du erst im Betrieb.

Selbst gehostet liegen der Full Route Cache und der Data Cache standardmäßig im lokalen Dateisystem. Das funktioniert mit einer Instanz. Sobald du eine zweite Instanz startest (zum Beispiel für Redundanz oder Lastverteilung), bedient jede Instanz ihren eigenen Cache. Daten divergieren. Stale Content taucht auf. Die Lösung ist ein custom cacheHandler in der next.config.js, der einen shared Store wie Redis anspricht. Das ist kein Bug. Es ist ein Feature, das Vercel automatisch löst und das du auf deinem VPS selbst bauen musst.

Die Vercel-Annahme

Next.js wurde um Vercel herum entworfen. Das ist kein Geheimnis und kein Vorwurf. Es bedeutet, dass bestimmte Features einen Infrastruktur-Layer voraussetzen, den du auf einem einzelnen VPS nicht hast.

next/image verarbeitet Bilder on-demand mit der nativen sharp-Library. Auf deinem VPS teilen sich Bildoptimierung und Request-Handling dieselben CPU-Kerne. Auf kleinen Instanzen merkst du das. In Docker-Builds (Alpine, ARM-Cross-Compilation) fehlt sharp regelmäßig oder trifft auf einen Architektur-Mismatch. Du konfigurierst entweder einen externen Image-Loader oder installierst sharp explizit.

ISR speichert seinen Cache lokal. Das bricht bei mehreren Instanzen (siehe oben). Zusätzlich hängt ISRs stale-while-revalidate-Verhalten von einem CDN ab, das den stale-while-revalidate Cache-Control-Header unterstützt. CloudFront und Fastly tun das. Cloudflare nicht. Das typische "VPS hinter Cloudflare"-Setup, das viele Self-Hoster nutzen, bekommt das vorgesehene ISR-Verhalten nicht.

Edge Middleware ist für Vercels Edge-Netzwerk gebaut, das Code geographisch nah am Nutzer ausführt. Auf einem VPS läuft sie in deinem einzelnen Node-Prozess an einem Standort. Der Code funktioniert, aber das Latenz-Modell aus der Dokumentation gilt nicht. Edge Functions setzen explizit eine Edge-Runtime voraus, die auf einem einzelnen Server nicht existiert.

Keines dieser Probleme ist ein Bug in Next.js. Es sind Features, die für eine spezifische Infrastruktur gebaut wurden. Wenn du diese Infrastruktur nicht hast, musst du jedes Feature einzeln ersetzen oder umgehen.

Warum KI-Projekte das am härtesten trifft

Die Ironie: Du hast Vibe Coding gewählt, um schnell ein Ergebnis zu bekommen. Die KI generiert ein Next.js-Projekt. Es kompiliert. Du bist begeistert. Dann willst du es deployen und stellst fest: Next.js auf einem VPS ist ein zweites Projekt. Du musst die Deployment-Interna lernen, um zu reparieren, was die KI falsch gemacht hat.

Die KI-generierten Fehler sind systematisch:

• next/image löst sharp-CPU-Last oder einen Native-Module-Build-Fehler in Docker aus
• ISR und Route-Caching liefern veraltete Daten, sobald eine zweite Instanz läuft
• Edge-Middleware-Annahmen produzieren ein anderes Latenz- und Execution-Modell als der Code erwartet
• App Router und Pages Router sind vermischt, und die Laufzeitfehler geben keinen Hinweis darauf, welches System den Fehler verursacht

Nuxt: Ein Pfad statt sechs

Nuxt ist das Vue-Fullstack-Framework. Sein Server-Engine Nitro wurde gebaut, um auf jedes Ziel zu deployen, ohne eine bevorzugte Plattform. nuxt build erzeugt einen .output-Ordner mit einem eigenständigen Server:

node .output/server/index.mjs

Keine Plattform-Annahmen. Kein Edge-Netzwerk-Requirement. Der Server läuft hinter nginx wie jede Node-App und liest Konfiguration aus Umgebungsvariablen.

Ein Rendering-Schalter statt sechs Modi. ssr: true (Standard) oder ssr: false für eine SPA. Einmal pro Projekt. Kein App-vs-Pages-Router-Split. KI-generierter Code zeigt in eine Richtung.

Caching explizit an einer Stelle. Die gesamte Caching-Policy lebt in routeRules in der nuxt.config.ts. Du liest die komplette Policy in einem Block, statt vier versteckte Layer zu reverse-engineeren:

export default defineNuxtConfig({
  routeRules: {
    '/':            { prerender: true },   // Build-Zeit statisch
    '/products/**': { swr: 600 },          // gecacht, revalidiert nach 10 Min
    '/admin/**':    { ssr: false }         // Client-only SPA
  }
})

Portabler Output. Nitro liefert Deployment-Presets, inklusive node-server, Docker und viele Provider. Derselbe Code zielt auf einen VPS ohne Rewrites. Der Default für Self-Hosting ist das node-server-Preset.

Vergleichstabelle

Die RAM-Werte sind Richtwerte aus Community-Reports und öffentlichen Diskussionen. Deine echten Werte hängen von App-Komplexität, Traffic und Middleware ab. Die Richtung ist konsistent: Eine vergleichbare kleine SSR-App fährt mit Nuxt ungefähr eine VPS-Stufe unter dem äquivalenten Next.js-Setup.

Was KI-generierter Nuxt-Code auf dem VPS kostet

Die RAM-Tabelle oben zeigt Richtwerte. In der Praxis bedeutet das: Ein Nuxt-SSR-Projekt mit moderatem Traffic läuft auf einem 2-GB-VPS ab ca. 4 Euro pro Monat. Das gleiche Projekt in Next.js braucht realistisch 4 GB, also ab ca. 5-8 Euro.

Der Unterschied klingt klein. Er wird relevant, wenn du mehrere Projekte auf demselben Server betreibst. Drei Nuxt-Apps auf einem 8-GB-Server laufen problemlos. Drei Next.js-Apps auf demselben Server werden eng, weil jede ihre eigenen Cache-Layer im Speicher hält.

Für den typischen Vibe-Coding-Anwendungsfall (eine App, ein Server, ein Entwickler) ist die Empfehlung: Nimm den günstigsten VPS mit 2 GB RAM für Nuxt oder 4 GB für Next.js. Wenn der Traffic wächst, skalierst du hoch. Wenn du nicht weißt, wie viel Traffic du bekommst (der Normalfall bei einem neuen Projekt), ist der 2-GB-Server die risikoärmere Wahl.

Nicht nur Nuxt: Andere Frameworks für Self-Hosting

Nuxt ist nicht die einzige Alternative. Je nach Projekttyp gibt es spezialisiertere Optionen:

Astro für Content-lastige Seiten (Blogs, Docs, Marketing). Null Client-JavaScript standardmäßig. SSR über den @astrojs/node-Adapter. Läuft auf einem 5-Euro-VPS mit PostgreSQL hinter nginx. Das leichteste Framework in der Liste.

SvelteKit für Performance-kritische Apps. SSR über adapter-node. Kleines, schnelles Runtime. Self-Hosting erfordert Konfiguration, die Vercel/Netlify automatisieren. Passt wenn Bundle-Größe und Laufzeit-Performance wichtiger sind als Ökosystem-Größe.

Remix (jetzt React Router v7) für SSR-fokussierte Apps. Einfacher als Next.js fürs Self-Hosting (keine RSC-Caching-Layer, keine Edge-Annahmen). Die Umbenennung hat allerdings Dokumentation und Trainingsdaten gesplittet, weshalb KI-generierter Code alte und neue Konventionen mischen kann.

Alle drei sind solide Optionen für Self-Hosting. Nuxt ist die Empfehlung für den allgemeinen Fullstack-Fall, weil es die breiteste Feature-Abdeckung mit der einfachsten Deployment-Story kombiniert.

Wann Next.js trotzdem die richtige Wahl ist

Dieser Artikel handelt von einer spezifischen Situation: Ein KI-generiertes Projekt, das du auf einem eigenen Server hosten willst.

Wenn du auf Vercel deployst und nicht vorhast wegzugehen, ist Next.js exzellent. Vercel löst die Caching-, ISR-, Edge- und Image-Probleme automatisch. Das Framework und die Plattform sind eine Einheit, und diese Einheit funktioniert.

Wenn dein Team Next.js kennt und bewusst die Architektur-Entscheidungen trifft (App Router, welche Caching-Strategie, wie ISR ohne Vercel), dann ist das eine informierte Wahl. Der Artikel richtet sich an Leute, die diese Entscheidungen nicht selbst treffen, weil die KI sie getroffen hat.

Fazit

Für KI-generierte Projekte auf einem eigenen Server hält Nuxt die KI auf einem Pfad und macht die Deployment-Story langweilig. Ein Rendering-Modell, ein Caching-Block, ein portabler Output. Die KI kann weniger falsch machen, und du verbringst weniger Zeit damit, Framework-Interna zu debuggen.

Next.js ist das mächtigere Framework. Aber Macht, die du nicht kontrollierst, ist Komplexität. Wenn du Vibe Coding nutzt, um schnell ein Ergebnis zu bekommen, willst du das Framework, das am wenigsten schiefgehen kann.

Welchen VPS du dafür brauchst, hängt von deinem Framework und Traffic ab. Unser Framework-Rechner berechnet die Anforderungen für dein Projekt, und der VPS-Vergleich zeigt dir die günstigsten Optionen.