Node.js

• Start: npm start, wenn package.json ein Start-Skript hat; die App muss auf $PORT und 0.0.0.0 lauschen (HOST, BIND_ADDRESS und ähnliche dokumentierte Variablen werden für dich gesetzt).
• Packager: npm, pnpm, yarn oder bun, bestimmt anhand deiner Lockfile.
• Workers: ein npm run worker-Skript wird als Worker angeboten.
• Statische Frontends: nutze stattdessen eine statische Seite — kein Serverprozess nötig.
• Große Frontend-Builds werden automatisch an den Speicher des Build-Servers angepasst (Build-Methoden).

Build-Schritt

Das build-Skript in deiner package.json läuft vor start, ganz ohne Konfiguration von dir — bei Next.js, Nuxt, SvelteKit und ähnlichen serverseitig gerenderten Frameworks wird das direkt aus deinen Abhängigkeiten als next build/nuxt build/vite build erkannt, und der Server startet mit dem passenden Befehl für jedes (next start, node .output/server/index.mjs…). Eine App, die nur statische Ausgabe erzeugt (Gatsby, Create React App, eine reine Vite-SPA), wird als statischer Build ohne jeden Serverprozess ausgeliefert — siehe statische Seiten, um den Server ganz zu überspringen, statt einen nur zum Ausliefern von Dateien laufen zu lassen.

Workers sind ein zweiter Prozess, keine zweite App

web und worker sind dasselbe Image, nur mit einem anderen Skript gestartet — eine Codebasis und ein Build, mehrere Prozesstypen, jeder für sich skaliert. Ein npm run worker-Skript wird automatisch angeboten; weitere deklarierst du selbst:

web: npm start
worker: npm run worker

oder fügst eines im Workers-Tab der App hinzu, ohne das Repo zu ändern, und skalierst beides über die CLI:

railyard scale my-app worker=2

Node hat keine einheitliche Queue-Konvention, daher braucht ein BullMQ- oder ähnlicher Redis-basierter Job-Runner nur sein eigenes Skript — REDIS_URL wird automatisch injiziert, sobald ioredis, bullmq oder bull eine Abhängigkeit ist. Siehe Workers und geplante Jobs für Cron.

Konfiguration und Secrets

Alles, was process.env liest, ist eine einfache Variable: setze sie unter Variables, oder per railyard env:set my-app KEY=VALUE über die CLI, und derselbe Build läuft unverändert von Staging bis Produktion — Dev/Prod-Parität statt eines eigenen Bundles pro Umgebung. Verweise mit ${{redis.RAILYARD_PRIVATE_URL}} auf eine Datenbank oder ein Redis, das als eigener Service auf dem Canvas läuft — wird pro Umgebung aufgelöst. Siehe Variablen und Secrets.

Deployen

• Aus einem Repo: füge die Git-URL ein, oder wähle es aus der Liste, sobald GitHub verbunden ist — Railyard liest package.json, trägt Start-Befehl, Packager und jede in deinen Abhängigkeiten deklarierte Datenbank ein und deployt bei jedem Push.
• Über die CLI: railyard create my-app https://github.com/me/my-app --addons postgres,redis, oder railyard git:remote && git push railyard main im Repo.
• Mit einem Klick: füge den Deploy-Button zu deiner README hinzu, oder veröffentliche im Template-Katalog, damit jeder es mit bereits ausgefüllten Addons und Variablen starten kann.