Next.js oder Nuxt auf dem eigenen VPS: Was beim Self-Hosting zu beachten ist

Du beschreibst einem KI-Tool eine App-Idee. Kurz darauf hast du ein lauffähiges Projekt: Next.js, App Router, TypeScript, Tailwind. Jetzt willst du es auf deinen eigenen Server stellen, und dafür lohnt ein genauer Blick auf die Deployment-Seite.

Die React-Doku nennt Next.js (App Router) als erstes empfohlenes Full-Stack-Framework für neue React-Apps (laut react.dev, Stand: 08.11.2026). Für ein Projekt auf einem eigenen VPS bringt das eigene Aufgaben mit sich.

Dieser Artikel erklärt, welche das sind, und wie sich Nuxt beim Self-Hosting davon unterscheidet.

Zwei Router in einem Framework

Next.js hat zwei Routing-Systeme: den Pages Router und den App Router. Das app-Verzeichnis kann neben dem pages-Verzeichnis existieren. Der Pages Router nutzt getServerSideProps und getStaticProps für Daten; im app-Verzeichnis ersetzt eine neue Data-Fetching-API diese Funktionen (laut Next.js-Doku, Stand: 08.11.2026).

Für KI-generierten Code heißt das: Prüfe, ob im app-Verzeichnis noch getServerSideProps oder getStaticProps stehen. Dort gibt es diese Funktionen nicht mehr.

Wenn du Vibe Coding gewählt hast, um schnell zu sein, lohnt diese Prüfung gleich am Anfang.

React Server Components: Das unsichtbare mentale Modell

Der App Router baut auf React Server Components (RSC). Seiten im app-Verzeichnis sind standardmäßig Server Components; eine Client Component markierst du mit "use client" (laut react.dev, Stand: 08.11.2026). Das klingt einfach, hat in der Praxis aber Folgen.

Normale Funktionen kannst du nicht als Props an Client Components geben, Server Functions schon; Event-Handler gehören in Client Components (laut react.dev, Stand: 08.11.2026). Nutzt eine KI-generierte Server Component useState, meldet Next.js das mit einem eigenen Fehler und dem Hinweis auf 'use client' (laut Next.js-Doku, Stand: 08.11.2026).

Hilfe gibt es schon im Editor: Das Next.js-TypeScript-Plugin warnt bei falsch gesetztem 'use client' und bei Client-Hooks in Server Components (laut Next.js-Doku, Stand: 08.11.2026). Die Grenze zwischen Server und Browser musst du trotzdem im Kopf behalten.

Mehrere Rendering-Strategien pro Route

Next.js rendert Routen statisch oder dynamisch, mit ISR oder mit Partial Prerendering (PPR), und die Strategie kann je Route anders sein. Für erfahrene Teams ist das flexibel. Bei KI-generierten Projekten musst du als Reviewer herausfinden, welche Strategie gewählt wurde und ob sie zu deinem Deployment passt.

Auf einem VPS sieht das so aus (laut Next.js-Doku, Stand: 08.11.2026; Quellen im Absatz darunter):

Quellen: Self-Hosting-Guide, output, cacheComponents, Edge Runtime (alle laut Next.js-Doku, Stand: 08.11.2026).

Zwei Caching-Modelle

Next.js hat zwei Caching-Modelle: Cache Components mit 'use cache' und das bisherige Modell, das die Doku als „Previous Model“ führt (laut Next.js-Doku, Stand: 08.11.2026). Wer mit einem KI-Tool Code generiert, sollte ihn gegen die installierte Version und deren Doku prüfen.

Selbst gehostet liegt der Cache im lokalen Dateisystem jeder Next.js-Instanz. Startest du eine zweite Instanz, etwa für Redundanz, bedient jede ihren eigenen Cache, und ein revalidateTag wirkt nur auf einer. Abhilfe ist ein eigener cacheHandler mit einem gemeinsamen Speicher wie Redis; bei mehreren Instanzen setzt du außerdem NEXT_SERVER_ACTIONS_ENCRYPTION_KEY und deploymentId (laut Next.js-Doku, Stand: 08.11.2026). Auf Vercel läuft das Deployment ohne Konfiguration, ISR-Seiten werden dort dauerhaft gespeichert (laut Vercel-Doku, Stand: 08.11.2026).

Self-Hosting und Vercel

Next.js wird von Vercel gepflegt (laut Vercel-Doku, Stand: 08.11.2026). Bildoptimierung, Proxy und ISR laufen mit next start ohne zusätzliche Konfiguration; einzelne Funktionen brauchen beim Self-Hosting eigene Einstellungen (laut Next.js-Doku, Stand: 08.11.2026).

next/image optimiert Bilder auf deinem Server. Auf glibc-Linux kann zusätzliche Konfiguration gegen hohen Speicherverbrauch nötig sein; Alternativen sind ein eigener Loader oder unoptimized (laut Next.js-Doku, Stand: 08.11.2026). Bei output: 'standalone' prüfst du, ob sharp im Output liegt; die Doku zeigt dafür outputFileTracingIncludes (laut Next.js-Doku, Stand: 08.11.2026).

ISR hinter einem CDN: Wer ein CDN vorschaltet, muss prüfen, ob es die Cache-Control-Angaben von Next.js beachtet (laut Next.js-Doku, Stand: 08.11.2026). Cloudflare etwa unterstützt stale-while-revalidate (laut Cloudflare-Doku, Stand: 08.11.2026).

Proxy (früher Middleware) läuft seit Version 16 standardmäßig in der Node.js-Runtime und funktioniert mit einem Node.js-Server und Docker (laut Next.js-Doku, Stand: 08.11.2026).

Keiner dieser Punkte ist ein Fehler in Next.js. Einige Funktionen brauchen beim Self-Hosting eigene Einstellungen, etwa ein Cache-Handler bei mehreren Instanzen oder Streaming hinter nginx.

Was das für KI-generierte Projekte bedeutet

Du hast Vibe Coding gewählt, um schnell ein Ergebnis zu bekommen. Die KI generiert ein Next.js-Projekt, es kompiliert. Vor dem Deployment lohnt ein Abgleich mit der Self-Hosting-Doku von Next.js.

Prüfpunkte vor dem Deployment (Quellen wie in den Abschnitten oben):

• sharp liegt im Build-Output, wenn du output: 'standalone' nutzt
• bei mehreren Instanzen ein gemeinsamer Cache-Handler
• keine runtime = 'edge'-Exports, die du auf dem VPS nicht brauchst
• keine Pages-Router-Funktionen im app-Verzeichnis
• Buffering in nginx für Streaming abgeschaltet

Nuxt: Ein Node-Server als Standard

Nuxt ist ein Full-Stack-Framework für Vue. Seine Server-Engine Nitro erzeugt aus derselben Codebasis Ausgaben für verschiedene Hosting-Anbieter; Standard für Produktions-Builds ist ein Node.js-Server (laut Nitro-Doku, Stand: 08.11.2026). nuxt build erzeugt einen .output-Ordner, den du so startest (laut Nuxt-Doku, Stand: 08.11.2026):

NODE_ENV=production node .output/server/index.mjs

Der Server läuft hinter nginx wie jede Node-App und liest Port und Host aus PORT und HOST; für mehrere Kerne nennt die Doku PM2 oder das Preset node_cluster (laut Nuxt-Doku, Stand: 08.11.2026).

Rendering je Route an einer Stelle. Standard ist Universal Rendering; abweichende Strategien wie SPA, Prerendering, swr oder isr legst du pro Route zentral in routeRules fest (laut Nuxt-Doku, Stand: 08.11.2026).

Routen-Caching gebündelt. Die Regeln stehen in einem Block in der nuxt.config.ts. Der Nitro-Cache liegt standardmäßig im Speicher des Prozesses; für mehrere Instanzen brauchst du einen gemeinsamen Speicher wie Redis (laut Nitro-Doku, Stand: 08.11.2026):

export default defineNuxtConfig({
  routeRules: {
    '/':            { prerender: true },   // Build-Zeit statisch
    '/products/**': { swr: 600 },          // gecacht, nach 600 s im Hintergrund neu erzeugt
    '/admin/**':    { ssr: false }         // Client-only SPA
  }
})

Presets. Nitro bringt Presets für Node.js und zahlreiche Hosting-Anbieter mit; Standard ist der Node.js-Server (node_server), der auch im Docker-Container läuft (laut Nitro-Doku, Stand: 08.11.2026).

Vergleichstabelle

Stand der Tabelle: 08.11.2026, Quellen in den Abschnitten oben (Next.js-, Nuxt- und Nitro-Doku).

Die Angabe zu IPX stammt aus der Doku des Moduls (laut Nuxt-Image-Doku, Stand: 08.11.2026).

Welcher VPS zu deinem Projekt passt

Den Ressourcenbedarf deines Projekts schätzt der Framework-Rechner. Aktuelle Preise je RAM-Stufe zeigt der VPS-Vergleich.

Wer mehrere Apps auf einem Server betreibt, addiert deren Speicherbedarf. Jede App mit eigenem Cache im Speicher braucht dafür Platz.

Für den typischen Vibe-Coding-Fall (eine App, ein Server, ein Entwickler) gilt: Starte mit der RAM-Stufe, die der Framework-Rechner für dein Projekt nennt, und skaliere bei wachsendem Traffic hoch; Preise je Stufe im VPS-Vergleich.

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

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

Astro für Content-Seiten wie Blogs, Docs und Marketing: standardmäßig ohne Client-JavaScript (laut Astro-Doku, Stand: 08.11.2026), SSR über den Adapter @astrojs/node im Modus standalone oder middleware (laut Astro-Doku, Stand: 08.11.2026).

SvelteKit erzeugt mit adapter-node einen eigenständigen Node-Server, Start mit node build, Port und Host per PORT/HOST (laut SvelteKit-Doku, Stand: 08.11.2026).

React Router v7 ist das, was als Remix v3 geplant war (laut Remix-Blog, Stand: 08.11.2026), und steht in der React-Doku unter den empfohlenen Frameworks (laut react.dev, Stand: 08.11.2026).

Welches Framework passt, hängt vom Projekt ab; für Nuxt, SvelteKit und Astro beschreibt die jeweilige Doku einen eigenen Node-Server.

Wann Next.js trotzdem die richtige Wahl ist

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

Wenn du auf Vercel deployst und dort bleiben willst, ist Next.js eine naheliegende Wahl. Auf Vercel läuft Next.js ohne Konfiguration, die Bildoptimierung ebenso, und ISR-Seiten werden dauerhaft gespeichert (laut Vercel-Doku, Stand: 08.11.2026).

Wenn dein Team Next.js kennt und bewusst die Architektur-Entscheidungen trifft (App Router, welches Caching-Modell, wie ISR mit mehreren Instanzen), dann ist das eine informierte Wahl. Der Artikel richtet sich an Leute, die diese Entscheidungen nicht selbst getroffen haben, weil die KI sie getroffen hat.

Fazit

Nuxt bündelt Rendering- und Cache-Regeln je Route in routeRules und baut standardmäßig einen Node-Server. Bei Next.js hängt der Aufwand fürs Self-Hosting davon ab, welche Funktionen dein Code nutzt.

Prüfe vor der Wahl, welche Funktionen dein Projekt braucht und wie die jeweilige Doku sie beim Self-Hosting beschreibt.

Welchen VPS du dafür brauchst, hängt von Framework und Traffic ab. Der Framework-Rechner schätzt den Ressourcenbedarf, der VPS-Vergleich zeigt aktuelle Preise, sortiert nach Preis.