Eine Next.js-App deployen, ohne einen Vercel-Account
Next.js ist dafür gebaut, auf Vercel zu laufen, was ein guter Standard ist — bis die Rechnung anfängt, Funktionsaufrufe und Edge-Requests statt einer flachen, vorhersehbaren Zahl zu verfolgen. Das Framework selbst erfordert das nicht — ein next build gefolgt von next start ist einfach ein Node-Prozess, läuft also überall dort gleich, wo ein Node-Prozess laufen kann, auch auf einem Server, den du selbst besitzt.
Was bei einem Push tatsächlich passiert
Es gibt keine Next.js-spezifische Konfiguration zu schreiben. Railyard liest package.json, erkennt das build-Skript und führt speziell bei einer Next.js-Abhängigkeit next build aus, bevor die App mit next start gestartet wird — dieselbe Erkennung, die auch Nuxt und SvelteKit abdeckt, da das Muster (Framework deklariert einen Build-Schritt, Framework liefert seinen eigenen Start-Befehl) bei allen drei gleich ist. Der Packager — npm, pnpm, yarn oder bun — wird anhand des Lockfiles bestimmt, das bereits im Repo liegt, nicht erraten.
railyard create my-app https://github.com/me/my-appoder füge dieselbe Git-URL ins Dashboard ein, sobald GitHub verbunden ist. In beiden Fällen baut und deployt jeder Push nach dem ersten automatisch neu — derselbe git push-Workflow, den Vercel populär gemacht hat, nur auf Infrastruktur, die nicht pro Request abgerechnet wird.
Die eine Entscheidung, die bewusst getroffen werden sollte: statisch oder Server
Eine Next.js-App, die output: "export" verwendet (oder nie ein serverseitiges Feature anfasst — keine API-Routen, keine Server Actions, kein ISR), erzeugt reine statische Ausgabe. Das ist etwas deutlich anderes und günstiger zu betreiben als eine serverseitig gerenderte App, und Railyard behandelt es auch so: Ein statischer Export wird ganz ohne Node-Prozess dahinter ausgeliefert, während alles mit Server-Side-Rendering, API-Routen oder Server Actions den vollen next start-Prozess am Leben hält. Zu wissen, welche Art von App tatsächlich geshippt wird — bevor man sich über Hosting-Kosten Sorgen macht — ist die nützliche erste Frage, kein Nachgedanke.
Umgebungsvariablen funktionieren genauso wie lokal
process.env.WHATEVER liest, was unter Variables gesetzt ist, oder via railyard env:set my-app KEY=VALUE über die CLI — derselbe Build-Artefakt läuft unverändert von einem Preview-Branch bis zur Produktion, sodass ein Staging-Deploy nie ein anderes Bundle läuft als das, was ausgeliefert wird. Ein Datenbank-Addon wird automatisch zu ${{postgres.RAILYARD_PRIVATE_URL}} aufgelöst, pro Umgebung sauber abgegrenzt.
Hintergrundarbeit braucht keine zweite App
Falls die App neben dem Web-Prozess einen Queue-Worker braucht — E-Mails, Webhooks, irgendetwas, das einen Request nicht blockieren sollte — ist das ein zweites Skript in derselben package.json, kein zweites Repo oder zweiter Deploy: npm run worker wird als eigener, skalierbarer Prozesstyp neben web erkannt und teilt sich einen Build.
Die vollständige Node.js-Referenz: Node.js-Docs, Deployen aus einem Repository.