Next.js ohne VPS deployen: Railway, Render oder Droplet

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.

18.09.2026
7 Min. Lektüre
Teilen Sie diesen Artikel:
Next.jsRailwayHostingDevOpsAnleitung

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.

Eine öffentliche HTTPS-URL, ohne einen Linux-Server zu verwalten
Deployments aus Git statt manuellem scp und systemd
Klare Abgrenzung zwischen PaaS, Vercel und VPS
JS und CSS minifizieren und Dockerfiles im Browser mit einem Linter prüfen, bevor Sie veröffentlichen
Alternativen zu Railway, das nicht das einzige PaaS ist

Wann ein VPS unnötige Arbeit ist

Was ein PaaS wirklich abnimmt

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

Kein SSH-Schlüssel-Tanz für eine Wochenend-Demo
Vorschau-URLs pro Branch bei den meisten PaaS-Produkten
Nutzungsbasierte Abrechnung statt eines vergessenen Droplets, das jeden Monat weiterläuft
Ein Projekt kann Next.js-App, Worker und eine kleine Datenbank bündeln
Was es nicht abnimmt

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

TTFB hängt weiter von App und Region ab, nicht vom Logo im Dashboard
Minifiziertes JS und CSS verringert weiterhin die Übertragungsmenge, und ein PaaS führt für Sie kein Tree Shaking durch
Ein billiger VPS kann einen trägen Serverless-Cold-Start schlagen; messen, nicht annehmen

Next.js auf Railway aus Git ausliefern

Minimaler Weg (ohne Dockerfile)

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

Das Startskript läuft lokal mit NODE_ENV=production
Umgebungsvariablen sind am Service gesetzt, nicht als Vorgaben im Dockerfile
Der Prozess nutzt die von Railway gesetzte Variable PORT
Die .env nicht in Git ablegen; Syntax bei Bedarf mit dem Online-.env-Validator prüfen
Wann ein Dockerfile nötig ist

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

Secrets ins Image einbauen

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-Standardeinstellungen auf einem anderen Host voraussetzen

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 großes, unminifiziertes Bundle stehen lassen

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

Assets und Konfigurationen im Browser

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.

JS/CSS minifizieren, das nicht durch next build geht
Das Dockerfile mit den DL-Regeln prüfen, bevor Railway das Image baut
docker-compose.yml prüfen, wenn ein lokaler Stack bleibt
Keine Produktions-Secrets in Git oder in Online-Tools
Kosten und vergessene Services

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.

Eine Ausgabenwarnung im Railway-Konto einrichten
Preview-Umgebungen abschalten, die Sie nicht nutzen
Keine Scraper oder CI-Browser auf demselben Service wie die Next.js-App

PaaS vs. Vercel vs. VPS

Nach Aufgabe wählen, nicht nach Hype

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

Frontend:Next.js-Frontend, Vorschauen, Edge
Komplette App:App + Worker + kleine Datenbank, eine Rechnung
Volle Kontrolle:Root-SSH, eigenes nginx, Mailserver, GPU

Starten Sie mit

Frontend:Vercel (oder eine vergleichbare Frontend-Cloud)
Komplette App:Railway oder Render
Volle Kontrolle:DigitalOcean-Droplet / anderer VPS

Railway ist nicht die einzige Antwort

Gleiches Problem, andere Kompromisse

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:
Next.js-Standardeinstellungen, Vorschau-URLs, Analytics-Erweiterungen
Das Modell aus der Next.js-Dokumentation gilt direkt
Nachteile:
Multi-Service-Apps brauchen weitere Produkte
Kosten für Bandbreite und Funktionsaufrufe können überraschen

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:
Bewährte Kombination aus Web Service und Datenbank
Statische Sites und Cron-Jobs im selben Konto
Nachteile:
Kostenlose Web Services werden nach 15 Minuten ohne Datenverkehr heruntergefahren, die nächste Anfrage wartet dann auf einen Kaltstart
Nicht auf Next.js zugeschnitten, den Startbefehl liefern Sie selbst mit

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:
Planbarer VM-Preis, wenn die App winzig bleibt
Volle Kontrolle über Prozessmanager und Reverse Proxy
Nachteile:
Sie aktualisieren das Betriebssystem und debuggen TLS selbst
Overkill für eine Next.js-Demo mit zwei Routen

FastMinify vor der ersten Produktions-URL

Minifizieren, was Next.js nicht sieht

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.

JS/CSS von einem CDN oder einem älteren Theme minifizieren
Eine minifizierte Produktionsdatei lesbar machen, wenn keine Source Maps vorliegen
Läuft im Browser, der Hoster sieht nicht, was Sie einfügen
Docker und .env neben der App

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.

Dockerfile-Prüfung im Stil von Hadolint (Teil der DL-Regeln, kein docker build)
Prüfung der Compose-Struktur, nicht der vollständigen Spezifikation
Prüft .env-Syntax, doppelte Schlüssel und Schlüsselnamen, die nach Secrets aussehen; kein Secret-Scanner

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

Vercel für reine Next.js-Frontends, Railway oder Render für App, Worker und Datenbank, ein VPS für SSH
Keine Secrets in Git, dafür gibt es die Variablen-Oberfläche des PaaS
Dateien in public/ minifizieren, denn Next.js minifiziert das App-Bundle bereits
Docker-Basis-Images auf eine Version festlegen, wenn ein Dockerfile mitgeht
Die Preisseite des Hosters lesen, denn Guthaben und Abrechnung ändern sich
Teilen Sie diesen Artikel
Teilen Sie diesen Artikel: