
Next.js ohne VPS deployen: Railway, Render oder Droplet
Kein SSH und kein nginx für ein Next.js-Sideproject. Vergleich von Railway, Render, Vercel und einem VPS — dann aus Git deployen, nachdem Assets im Browser minifiziert wurden.
Die App ist fertig. Es fehlt eine URL.
Ein lokales next dev ersetzt keine Produktionsumgebung. Ein VPS bedeutet SSH, einen Prozessmanager, TLS und eine Nacht mit nginx. Für viele Nebenprojekte genügt Git als Eingang und HTTPS als Ausgang, also die Aufgabe eines PaaS im Stil von Heroku. Dieser Leitfaden vergleicht diesen Weg (durchgespieltes Beispiel: Railway) mit Vercel, Render und einem klassischen Droplet, damit Sie eine Next.js-App hosten, ohne zum Systemadministrator zu werden.
Wann ein VPS unnötige Arbeit ist
Die Plattform baut aus dem Repository, startet den Prozess, übernimmt TLS und startet nach einem Absturz neu. Sie behalten Umgebungsvariablen, die Rechnung und die Reife der App. Ubuntu müssen Sie nicht patchen.
Verbesserungen
Assets minifizieren und komprimieren, Secrets aus Git heraushalten, Core Web Vitals prüfen: Das bleibt Ihre Aufgabe. Mit next start komprimiert Next.js Antworten standardmäßig bereits mit gzip; für Brotli oder ein CDN lesen Sie unseren Leitfaden zu gzip und Brotli am Origin-Server. Ein PaaS erspart Ihnen nur den nginx-Block.
SEO-Vorteile
Next.js auf Railway aus Git ausliefern
Railway baut Ihr Repository standardmäßig mit Railpack (Nixpacks wird ebenfalls unterstützt) und führt das Startskript der package.json aus, sodass eine Standard-Next.js-App keine zusätzliche Konfiguration braucht. Am einfachsten verbinden Sie ein GitHub-Repository. Der Empfehlungslink oben bringt Ihnen aktuell 20 $ Guthaben bei der Anmeldung. Das ist ein Angebot von Railway und kein FastMinify-Gutschein, und der Betrag kann sich ändern.
1. Ein Repository, das von allein baut
Prüfen Sie, dass die package.json die Skripte build und start enthält (next build und next start bei einer Standard-App) und das Lockfile eingecheckt ist. Legen Sie keine Secrets in einer .env in Git ab, sondern setzen Sie die Variablen in der Railway-Oberfläche.
2. Projekt von GitHub anlegen
Legen Sie in Railway ein neues Projekt aus GitHub an und wählen Sie das Repository. Das erste Deployment scheitert oft an einer fehlenden Umgebungsvariable, das ist normal. Ergänzen Sie DATABASE_URL oder Ihre API-Schlüssel und starten Sie das Deployment erneut.
3. Generierte Domain, dann Ihre
Prüfen Sie über die generierte URL *.up.railway.app, ob die App startet. Binden Sie danach Ihre eigene Domain ein. Railway stellt das TLS-Zertifikat für Sie aus.
4. Erste Rechnung lesen, nicht den Screenshot
Zum Zeitpunkt der Erstellung kostet der Hobby-Tarif 5 $ im Monat und enthält 5 $ Nutzung, Pro kostet 20 $ und enthält 20 $. Was diesen Betrag übersteigt, wird nutzungsabhängig berechnet (CPU, RAM, ausgehender Netzwerkverkehr), und ein gestoppter Service belegt weder CPU noch RAM. Lesen Sie die Preisseite von Railway, bevor Sie einen schweren Node-Prozess rund um die Uhr laufen lassen.
Checkliste
Ein Dockerfile brauchen Sie, wenn Railpack falsch rät, ein Systempaket fehlt oder das Image bereits die maßgebliche Quelle ist. Prüfen Sie es vor dem ersten Deployment im Browser mit dem Dockerfile-Linter online, der einen Teil der DL-Regeln im Stil von Hadolint anwendet und kein Image baut. Dazu passt der Dockerfile-Formatter.
Basis-Image auf eine Version festlegen
Vermeiden Sie FROM node:latest (DL3007) und legen Sie ein konkretes Distributions-Tag fest. Railway baut dieses Dockerfile, wenn es im Stammverzeichnis des Repositorys liegt.
PORT verwenden
Legen Sie 3000 in der Produktion nicht fest, wenn die Plattform PORT setzt. next start liest die Variable PORT selbst (3000 ist nur der Standardwert), ebenso das server.js des Standalone-Modus, daher ist -p $PORT optional.
Fehler, die den ersten PaaS-Deploy scheitern lassen
Eine Zeile ENV AWS_SECRET= im Dockerfile oder eine eingecheckte .env gelangt in Logs und Image-Schichten. Die Variablen von Railway sorgen dafür, dass das Image generisch bleibt.
Merken — Prüfen Sie die .env-Syntax mit dem ENV-Validator von FastMinify und fügen Sie niemals echte Tokens in ein öffentliches Textfeld ein.
Vercel führt Next.js als Serverless-Funktionen aus und übernimmt das Routing. Auf Railway starten Sie meist next start als dauerhaft laufenden Node-Prozess, und output: 'standalone' erzeugt einen eigenständigen Serverordner. Funktionen, die an die Vercel-Plattform gebunden sind, etwa Edge Config oder Cron-Jobs, ziehen nicht mit zu einem anderen Hoster um.
Merken — Starten Sie auf Ihrem Rechner einen Produktions-Build, bevor der erste Push zum PaaS geht.
Ein PaaS minifiziert Ihr Client-JavaScript nicht. Next.js erledigt das für die App, nicht aber für eine Datei wie widget.js in public/. Für solche einzelnen Dateien nutzen Sie den JavaScript-Minifizierer online.
Merken — Messen Sie die Übertragung auf der Railway-URL und lokal.
Bevor Sie das Deployment starten
FastMinify arbeitet im Browser-Tab, was hilft, wenn das Repository auf diesem Rechner nicht geklont ist. Minifizieren Sie übrig gebliebenes CSS, prüfen Sie das Dockerfile mit dem Linter und kontrollieren Sie Compose, falls Docker lokal noch läuft.
Railway berechnet die Nutzung über das im Tarif enthaltene Guthaben hinaus. Ein vergessener Service, der 2 GB RAM belegt, macht aus einem Nebenprojekt schnell eine Überraschungsrechnung. Stoppen Sie ungenutzte Services oder aktivieren Sie Serverless, damit ein inaktiver Service in den Ruhezustand geht (ausgehender Datenverkehr, etwa eine offene Datenbankverbindung, hält ihn wach). Ein nie gelöschtes Droplet ist derselbe Fehler in einem anderen Dashboard.
PaaS vs. Vercel vs. VPS
Vercel ist der kürzeste Weg für ein Next.js-Frontend. Ein VPS gewinnt, wenn Sie einen eigenen Kernel, einen Mailserver oder SSH-Zugriff brauchen. Railway liegt dazwischen: Deployment aus Git, nutzungsabhängige Abrechnung und Platz für Worker und Datenbank neben der App.
Wenn Sie brauchen
Starten Sie mit
Railway ist nicht die einzige Antwort
Betrachten Sie dies als Landkarte, nicht als Rangliste. Preise und kostenlose Tarife ändern sich, lesen Sie daher die Seite des Anbieters, bevor Sie sich festlegen.
Vercel
Vom Team hinter Next.js entwickelt, mit der direktesten Unterstützung für App Router, Vorschauen und Edge. Weniger passend, wenn Sie im selben Projekt einen dauerhaft laufenden Worker oder eine klassische Datenbank ohne zusätzliche Anbieter brauchen.
Vorteile:
Nachteile:
Render
Deployments aus Git, Web Services, Postgres, Worker im Hintergrund. Enger Verwandter von Railway. Nehmen Sie die Plattform, auf der Sie schon ein Konto haben.
Vorteile:
Nachteile:
DigitalOcean-Droplet (oder App Platform)
Ein Droplet ist ein VPS: Sie installieren Node, Caddy oder nginx und certbot, und die Maschine gehört Ihnen. App Platform ist das PaaS von DigitalOcean. Ein Droplet passt, wenn Sie ohnehin mit SSH arbeiten und eine eigene öffentliche IPv4-Adresse wollen.
Vorteile:
Nachteile:
FastMinify vor der ersten Produktions-URL
Der Produktions-Build von Next.js minifiziert das JavaScript Ihrer App, nicht aber eine Datei wie widget.js in public/ oder ein CMS-Snippet. Für solche einzelnen Dateien nutzen Sie den JavaScript-Minifizierer online und den CSS-Minifizierer online. Wird eine Fremddatei in der Produktion unlesbar, macht der JavaScript-Unminifier online sie wieder lesbar.
Baut Railway oder ein anderer Hoster ein Dockerfile, prüfen Sie es zuerst. Falls Sie Compose noch lokal nutzen, können Sie Docker Compose online validieren. Suchen Sie in Ihren .env-Dateien nach doppelten Schlüsseln, bevor Sie die Namen in die Oberfläche des PaaS übertragen. Alle diese Werkzeuge finden Sie im Hub DevOps-Tools online.
URL veröffentlichen, VPS für später aufheben
Handelt es sich um ein Next.js-Nebenprojekt, vielleicht mit einem Worker, kostet ein PaaS weniger Abende als ein Droplet. Railway ist das durchgespielte Beispiel (Affiliate-Link). Vercel bleibt die Standardwahl für ein reines Next.js-Frontend, und ein VPS bleibt die richtige Wahl, wenn Sie SSH wollen. Minifizieren Sie übrig gebliebene Dateien und prüfen Sie Dockerfiles in jedem Fall mit FastMinify: Dieser Schritt ist kostenlos und läuft lokal.
Assets vorbereiten, dann dort deployen, wo Sie sich entschieden haben
Verwandte Artikel

Fügen Sie Token und JWKS ein und prüfen Sie eine RS256-, ES256- oder HS256-Signatur im Browser. Schlüsselwahl per kid, Fehler und zu prüfende Claims.

HTTP/2 und HTTP/3 ändern den Weg der Dateien, nicht ihre Größe. Messungen zu Größe, Kompilierzeit und Bundling zeigen, was Minifizierung noch bringt.

Rechnen Sie eine Unix-Epoche in ein lesbares Datum um und zurück, unterscheiden Sie Sekunden und Millisekunden und meiden Sie Zeitzonen-, JWT- und Zeitumstellungsfallen.