Bestes Hosting für Next.js: Managed-Plattformen vs. VPS

Next.js ist ein React-Framework, das zwei sehr unterschiedliche Arten von Ausgabe erzeugen kann, und deine Hosting-Wahl folgt direkt daraus, welche du auslieferst. Eine rein statische Website ist nur eine Menge Dateien, die ein CDN ausliefert ; eine serverseitig gerenderte App ist ein langlebiger Node.js-Prozess, der am Leben bleiben muss. Verwechselst du beides, zahlst du für eine statische Website zu viel oder deployst eine dynamische App an einen Ort, der sie nicht ausführen kann. Dieser Leitfaden erklärt die Rendering-Modi und vergleicht dann ehrlich den Kompromiss zwischen einer Managed-Plattform und einem selbst gehosteten VPS.

Zuerst: entscheide, wie deine App rendert

Die wichtigste Frage ist, ob deine Anwendung statisch ist oder einen Server zum Anfragezeitpunkt braucht. Next.js unterstützt beides, und sie haben völlig unterschiedliche Hosting-Anforderungen.

• Statischer Export - mit output: 'export' baut Next.js reines HTML, CSS und JavaScript zur Build-Zeit. Es gibt keinen Server : das Ergebnis ist ein Ordner mit Dateien, den jeder statische Host oder jedes CDN ausliefern kann. Günstig und einfach, aber es schließt alles aus, was pro Anfrage läuft.
• Serverseitig gerendert (SSR / ISR / API-Routen) - Server-Side-Rendering, inkrementelle statische Regeneration, Route-Handler und Middleware führen alle Code aus, wenn eine Anfrage eintrifft. Das braucht eine Node.js-Laufzeit, die deinen Build ausführt und am Leben bleibt, um Anfragen zu beantworten.

Du kannst prüfen, was dein Projekt nutzt : wenn es auf getServerSideProps, Server-Komponenten mit Fetch zur Anfragezeit, API-Routen unter app/api oder pages/api oder ISR-Revalidierung setzt, ist es eine Server-App. Wenn jede Seite im Voraus generiert werden kann, kommt ein statischer Export infrage.

Option 1: ein statischer Export auf jedem statischen Host

Ist deine App vollständig statisch, ist das Hosting trivial und günstig. Setze die Ausgabe auf export, baue und deploye den erzeugten Ordner auf einen statischen Host oder ein CDN :

// next.config.js
module.exports = {
  output: 'export',
};

# der Build erzeugt einen statischen Ordner 'out/'
npm run build

# 'out/' enthaelt nun HTML, CSS und JS, das du ueberall hochladen kannst

Der Ordner out/ sind nur Dateien, er funktioniert also auf jedem statischen Host mit globalem CDN und kostenlosem HTTPS. Das ist dasselbe Modell wie in unserem Leitfaden zum Hosting statischer Websites. Der Haken : ein statischer Export kann kein Server-Side-Rendering, kein ISR, keine On-the-fly-Bildoptimierung und keine API-Routen - diese Funktionen existieren ohne Server schlicht nicht.

Option 2: eine Managed-Plattform

Managed-Plattformen bauen deine App aus einem Git-Push und betreiben den Server für dich, inklusive Skalierung, TLS und Build-Pipeline. Vercel ist hier am bemerkenswertesten, weil es das Unternehmen ist, das Next.js entwickelt, sodass seine Plattform neue Framework-Funktionen eng verfolgt. Andere Plattformen wie Netlify unterstützen Next.js ebenfalls über eigene Adapter.

Der Reiz ist echt : du machst git push und die Plattform führt den ganzen Ablauf aus, es gibt also keinen Server zu patchen und keinen Reverse-Proxy zu konfigurieren. Der Kompromiss ist Kontrolle und Kosten. Du arbeitest im Build- und Laufzeitmodell der Plattform, und eine nutzungsbasierte Abrechnung kann steigen, wenn Traffic, Funktionsausführung und Bandbreite wachsen. Für ein kleines Projekt sind die kostenlosen oder niedrigen Stufen großzügig ; für eine stark frequentierte App wächst die Rechnung mit der Nutzung - genau der Punkt, an dem Self-Hosting attraktiv wird.

Option 3: Self-Hosting auf einem VPS

Weil eine serverseitig gerenderte Next.js-App letztlich ein Node.js-Prozess ist, kannst du sie selbst auf einem VPS betreiben - genauso, wie du jede Node-App hosten würdest. Das ist die flexibelste und in der Regel bei Skalierung günstigste Option, im Tausch gegen die Betriebsarbeit, die du selbst erledigst. Der Build erzeugt einen Server, den du mit next start startest :

# auf dem Server: Abhaengigkeiten installieren und bauen
npm ci
npm run build

# den Produktionsserver starten (Standardport 3000)
npm run start

Wie bei jedem langlebigen Node-Prozess solltest du next start nicht von Hand in einer SSH-Sitzung starten. Nutze einen Prozessmanager wie PM2, um ihn am Leben zu halten und nach einem Absturz oder Neustart wieder zu starten, und setze einen Reverse-Proxy davor. Das ist genau das Muster aus unserem Leitfaden zum Hosten einer Node.js-App :

# den Next.js-Server mit PM2 am Leben halten
pm2 start "npm run start" --name next-app
pm2 startup
pm2 save

Richte dann Nginx auf den Node-Prozess, damit es TLS terminiert und öffentlichen Traffic an Port 3000 weiterleitet :

server {
  listen 80;
  server_name yourapp.com;

  location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}

Füge HTTPS mit einem kostenlosen automatisierten Zertifikat hinzu (Tools wie Certbot machen daraus einen Einzeiler). Für die Dimensionierung der Maschine gelten dieselben Kriterien wie bei jeder Web-App - zuerst der Arbeitsspeicher, dann die CPU - behandelt in unserem Leitfaden zur Wahl des besten VPS für ein Webprojekt. Anbieter mit starkem Ressourcen-zu-Preis-Verhältnis wie Contabo oder Hetzner bieten großzügigen RAM und vCPU zu geringen Monatskosten, was zu einem Node-Build und -Runtime gut passt.

Wie sich die Optionen vergleichen

Ansatz	Führt aus	Du verwaltest	Am besten wenn
Statischer Export	Dateien auf einem CDN (kein Server)	Nur Build und Upload	Jede Seite lässt sich vorab rendern
Managed-Plattform	SSR, ISR, API-Routen	Nur deinen Code und Env-Variablen	Du willst schnell ausliefern, wenig Betrieb
VPS (selbst gehostet)	SSR, ISR, API-Routen	OS, Node, PM2, Nginx, TLS	Du willst Kontrolle und planbare Kosten

Wie du entscheidest

Geh davon aus, wie deine App rendert, nicht vom Marketing eines Anbieters. Kann jede Seite im Voraus generiert werden, liefere einen statischen Export aus und hoste ihn günstig auf einem CDN. Brauchst du SSR, ISR oder API-Routen, brauchst du eine Node.js-Laufzeit - und dann läuft es auf einen bekannten Kompromiss hinaus : eine Managed-Plattform ist der schnellste Weg zur Auslieferung und die geringste Betriebsarbeit, während ein VPS bei Skalierung günstiger ist und dir volle Kontrolle gibt, im Tausch dafür, dass du Node, einen Prozessmanager, einen Reverse-Proxy und TLS selbst betreibst. Wähle die kleinste Option, die abdeckt, was deine App wirklich braucht, und steige erst dann auf, wenn Skalierung oder Betriebsaufwand zum eigentlichen Engpass werden.