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.js
Railway
Hosting
DevOps
Anleitung

Die App ist fertig. Es fehlt eine URL.

Lokales next dev ist nicht Produktion. Ein VPS bedeutet SSH, Process-Manager, TLS und eine Nacht mit nginx. Für viele Sideprojects reicht Git rein, HTTPS raus — der Heroku-artige PaaS-Job. Dieser Guide vergleicht diesen Weg (Beispiel: Railway) mit Vercel, Render und einem klassischen Droplet, damit Sie eine Next.js-App hosten, ohne Sysadmin zu werden.

Öffentliche HTTPS-URL ohne Linux-Box zu administrieren
Deploys aus Git statt manuellem scp und systemd
Klare Trennung: PaaS vs. Vercel vs. VPS
JS/CSS minifizieren und Dockerfiles im Browser linten vor dem Ship
Ehrliche Alternativen — Railway ist nicht das einzige PaaS

Wann ein VPS unnötige Arbeit ist

Was ein PaaS wirklich abnimmt

Die Plattform baut aus dem Repo, startet den Prozess, beendet TLS und startet nach einem Crash neu. Sie behalten Env-Vars, die Rechnung und die Reife der App. Sie patchen nicht Ubuntu.

Verbesserungen

Kein SSH-Schlüssel-Tanz für eine Wochenend-Demo
Preview-URLs pro Branch auf den meisten PaaS-Produkten
Nutzungsbasierte Rechnung statt eines vergessenen 6-Dollar-Droplets
Ein Projekt kann Next.js-App, Worker und kleine Datenbank halten
Was es nicht abnimmt

Assets minifizieren und komprimieren, Secrets aus Git halten, Core Web Vitals prüfen — das bleibt. Ein PaaS ersetzt nicht gzip und Brotli am Origin oder ein CDN. Sie schreiben nur nicht selbst die nginx-Strophe.

SEO-Vorteile

TTFB hängt weiter von App und Region ab, nicht vom Dashboard-Logo
Minifiziertes JS/CSS spart Transfer — das PaaS tree-shaket nicht magisch
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 erkennt Node (Nixpacks/Railpack). Eine Standard-Next.js-App mit Start-Skript reicht. GitHub statt Zip. Der Empfehlungslink oben gibt Ihnen aktuell 20 $ Guthaben bei der Anmeldung — das ist Railways Grant, kein FastMinify-Coupon, der Betrag kann sich ändern.

1. Repo, das ohne magische CI baut

package.json mit build und start (oder next start). Lockfile committed. Keine Secrets in Git-.env — Variablen in der Railway-UI.

2. Projekt von GitHub anlegen

Neues Railway-Projekt → Deploy from GitHub → Repo wählen. Der erste Deploy scheitert oft an einer fehlenden Env-Var; das ist normal. DATABASE_URL oder Keys setzen, neu deployen.

3. Generierte Domain, dann Ihre

Die URL *.up.railway.app zeigt, ob die App bootet. Eigene Domain danach. TLS wird für Sie ausgestellt.

4. Erste Rechnung lesen, nicht den Screenshot

Hobby enthält ein kleines Usage-Guthaben, Pro mehr. CPU, RAM und Egress über dem Plan werden pro Sekunde berechnet. Gestoppte Services kosten nichts. Railway-Preise lesen, bevor ein fetter Node-Prozess 24/7 läuft.

Checkliste

Start-Skript lokal mit NODE_ENV=production
Env-Vars am Service, nicht als Dockerfile-Defaults
Prozess lauscht auf den von Railway injizierten PORT
.env nicht committen — Syntax ggf. mit dem Online-.env-Checker prüfen
Wann ein Dockerfile nötig ist

Dockerfile, wenn Nixpacks falsch liegt, ein Systempaket fehlt oder das Image schon Source of Truth ist. Zuerst im Browser linten: Dockerfile-Linter online (Hadolint-artige DL-Regeln, kein Build). Dazu der Dockerfile-Formatter.

Basis-Image pinnen

Kein FROM node:latest (DL3007). Distro-Tag pinnen. Railway baut das Dockerfile, wenn es im Repo-Root liegt.

Auf PORT hören

3000 nicht hart kodieren, wenn die Plattform PORT setzt. Next.js respektiert das mit next start -p $PORT oder gleichwertig.

Fehler, die den ersten PaaS-Deploy verbrennen

Secrets im Image backen

ENV AWS_SECRET= im Dockerfile oder eine committete .env landet in Logs und Layern. Railway-Variablen halten das Image generisch.

Merken.env-Syntax mit dem FastMinify-Checker prüfen; niemals Live-Tokens in ein öffentliches Textfeld.

Vercel-Defaults auf einem anderen Host erwarten

Auf Vercel ist Next.js-Serverless vorgegeben. Auf Railway läuft meist next start als langer Node-Prozess. output: 'standalone' hilft. Reines Vercel-Edge-Middleware erscheint nicht von allein.

MerkenProduction-Build auf dem Laptop, bevor der erste PaaS-Push geht.

Fettes unminifiziertes Bundle lassen

Ein PaaS minifiziert Ihr Client-JS nicht. Next tut das für die App, nicht für widget.js in public/. Dafür der JavaScript-Minifizierer online.

MerkenTransfer auf der Railway-URL messen, nicht nur auf localhost.

Bevor Sie auf Deploy klicken

Assets und Configs im Browser

FastMinify bleibt im Tab — nützlich, wenn das Repo auf dieser Maschine nicht geklont ist. Rest-CSS minifizieren, Dockerfile linten, Compose prüfen, falls Docker lokal noch läuft.

JS/CSS minifizieren, das nicht durch next build geht
Dockerfile-DL-Regeln linten, bevor Railway das Image baut
docker-compose.yml prüfen, wenn ein lokaler Stack bleibt
Prod-Secrets weder in Git noch in Online-Tools
Kosten und Vergessen

Railway rechnet Usage über Plan-Credits ab. Ein vergessener Service mit 2-GB-Node-Heap wird zur Überraschungsrechnung. Ungenutzte Services stoppen. Dieselbe Fehlerklasse wie ein nie gelöschtes Droplet — anderes Dashboard.

Spend-Alert im Railway-Konto
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 Job wählen, nicht nach Tweet

Vercel ist der kürzeste Weg für ein Next.js-Frontend. Ein VPS gewinnt bei Custom-Kernel, Mail, SSH. Railway liegt dazwischen: Git-Deploy, Usage-Billing, Platz für Worker und DB neben der App.

Wenn Sie brauchen

format:Next.js-Frontend, Previews, Edge
validate:App + Worker + kleine DB, eine Rechnung
minify:Root-SSH, eigenes nginx, Mail, GPU

Starten Sie mit

format:Vercel (oder vergleichbare Frontend-Cloud)
validate:Railway oder Render
minify:DigitalOcean-Droplet / anderer VPS

Railway ist nicht die einzige Antwort

Gleiches Problem, andere Trade-offs

Eine Karte, kein Ranking. Preise und Free Tiers ändern sich — Vendor-Seite lesen.

Vercel

Vom Next.js-Team. Beste DX für App Router, Previews, Edge. Schwächer, wenn Sie einen langlebigen Worker oder eine klassische DB im selben Projekt ohne Extra-Vendor brauchen.

Vorteile:
Next.js-Defaults, Preview-URLs, Analytics-Add-ons
Das mentale Modell der Next-Docs gilt
Nachteile:
Multi-Service-Apps brauchen weitere Produkte
Bandwidth- und Invocation-Kosten können überraschen

Render

Git-Deploys, Web Services, Postgres, Worker. Cousin von Railway. Nehmen Sie das Dashboard, auf dem Sie schon ein Konto haben.

Vorteile:
Vertrautes Web-Service-plus-DB-Paar
Static Sites und Crons im selben Konto
Nachteile:
Historische Cold Starts auf manchen niedrigen Tiers
Nicht Next.js-spezifisch — Sie bringen den Start-Befehl

DigitalOcean-Droplet (oder App Platform)

Ein Droplet ist ein VPS: Sie installieren Node, Caddy oder nginx, certbot, die Box gehört Ihnen. App Platform ist DigitalOceans PaaS. Besser, wenn Sie in SSH denken und eine eigene IPv4 wollen.

Vorteile:
Planbarer VM-Preis, wenn die App winzig bleibt
Volle Kontrolle über Process-Manager und Reverse Proxy
Nachteile:
Sie patchen das OS und debuggen TLS
Overkill für eine Next.js-Demo mit zwei Routen

FastMinify vor der ersten Prod-URL

Minifizieren, was Next.js nicht sieht

Next.js-Production-Builds minifizieren App-JS. Nicht ein widget.js in public/ und nicht ein CMS-Snippet. Nutzen Sie den JavaScript-Minifizierer online und den CSS-Minifizierer online. Vendor-Datei unlesbar: JavaScript-Unminifier online.

JS/CSS von CDN oder Legacy-Theme minifizieren
Prod-Stack ohne Source Maps unminifizieren
100 % Browser — der Deploy-Host sieht den Paste nicht
Docker und Env neben der App

Baut Railway (oder jemand anderes) ein Dockerfile, zuerst linten. Compose lokal: Docker Compose online validieren. .env-Dateien auf doppelte Keys prüfen, bevor Namen in die PaaS-UI wandern. Alles im Hub DevOps-Tools online.

Hadolint-artiges Dockerfile-Lint (DL-Subset, kein docker build)
Compose-Strukturchecks — nicht die volle Spec
Nur .env-Syntax — kein Secret-Scanner

URL shippen, VPS für später behalten

Ist der Job ein Next.js-Sideproject plus vielleicht ein Worker, kostet ein PaaS weniger Abende als ein Droplet. Railway ist das durchgespielte Beispiel (Affiliate-Link). Vercel bleibt Default für reines Next.js-Frontend. Ein VPS bleibt die richtige störrische Wahl, wenn Sie SSH wollen. Reste minifizieren und Dockerfiles linten in FastMinify sowieso — kostenlos und lokal.

Assets vorbereiten, dann dort deployen, wo Sie sich entschieden haben

Vercel für Next-only, Railway/Render für App+Worker+DB, VPS für SSH
Keine Secrets in Git; die PaaS-Env-UI existiert dafür
public/-Reste minifizieren; Next minifiziert das App-Bundle bereits
Docker-Bases pinnen, wenn ein Dockerfile mitgeht
Host-Preisseite lesen — Credits und Idle-Billing ändern sich
Teilen Sie diesen Artikel
Teilen Sie diesen Artikel: