Von Railway migrieren

Railway-Services mit Datenbank und Variablen umziehen.

Ein Railway-Projekt besteht aus Services, die sich über Variablen-Referenzen verbinden. Auf Nodion wird ein Service mit eigenem Code eine Application, Worker desselben Codes werden zusätzliche Prozesse dieser App, und Datenbanken werden Managed Databases, die du an die App hängst. railway.json oder railway.toml liest Nodion nicht; Railway selbst stellt Config as Code ein (harter Stichtag 2026-12-01), die Einstellungen ziehst du also von Hand um.

Was wozu wird

1. Projekt und Datenbank anlegen

Leg ein Projekt an und darin die Datenbanken, die dein Railway-Projekt nutzt, in der Region, in der die Apps laufen sollen. Für Postgres wählst du eine Version, die mindestens so neu ist wie auf Railway. Statt Redis bietet Nodion Valkey, das ebenfalls über REDIS_URL angehängt wird. Ein leerer Valkey reicht nur für Caches oder Queues, die du vorher leerlaufen lässt; brauchst du die Keys aus Redis, zieh sie um, bevor du das Railway-Projekt löschst. Mehr unter Datenbanken.

2. Datenbank kopieren

Railway-Datenbanken sind standardmäßig privat. Für den Dump erreichst du sie auf einem von zwei Wegen: Entweder schaltest du unter Settings, Networking den öffentlichen Zugang ein; Railway legt dann einen TCP-Proxy an und setzt DATABASE_PUBLIC_URL (Railway-Doku), und Traffic über den Proxy rechnet Railway als Egress ab. Oder du lässt die Datenbank privat und öffnest mit der Railway-CLI einen Tunnel, nachdem du das Projekt mit railway link verknüpft hast. Railways eingebaute Volume-Backups lassen sich nur ins selbe Projekt zurückspielen, für den Umzug brauchst du also pg_dump.

Stopp die Schreibzugriffe deiner Services und erstelle dann den Dump, wie Railway es in seiner Backup-Anleitung zeigt. Über den öffentlichen Zugang nimmst du den Wert von DATABASE_PUBLIC_URL aus den Variablen des Datenbank-Service:

bashpg_dump "postgresql://postgres:PASSWORD@PROXY_HOST:PROXY_PORT/railway" \
  --format=custom --no-owner --file=railway.dump

Über den Tunnel verknüpfst du zuerst das Projekt mit railway link, öffnest dann den Tunnel und dumpst in einem zweiten Terminal gegen localhost, mit dem Port, den die CLI anzeigt:

bashrailway link
railway connect postgres --tunnel-only

# second terminal
pg_dump "postgresql://postgres:PASSWORD@localhost:TUNNEL_PORT/railway" \
  --format=custom --no-owner --file=railway.dump

Öffne in Nodion die Datenbank, Tab Overview, und klick auf Enable public access. Sobald der Endpoint nicht mehr Provisioning zeigt, kopier die Connection URL (immer TLS) und trag unter Allowed sources deine eigene IP ein. Dann einspielen:

bashpg_restore --verbose --no-owner --no-acl \
  --dbname "postgresql://nodion:PASSWORD@HOST:PORT/DATABASE?sslmode=require" \
  railway.dump

Nimm ein pg_restore, das mindestens so neu ist wie der neuere der beiden Server. Prüf Zeilenzahlen im Tab Browse, schalte den öffentlichen Zugang danach wieder ab und deaktiviere ihn auch auf Railway.

3. Application und Prozesse anlegen

Leg pro Code-Service eine Application aus dem Git-Repository an. Hat Railway mit Railpack oder Nixpacks gebaut, nimm die Strategie Buildpacks (Buildpacks); hat es ein Dockerfile gefunden, nimm die Strategie Dockerfile. Anders als Railway wählt Nodion die Strategie nicht selbst, du legst sie fest.

Railway setzt PORT für deine Services. Nodion setzt PORT nur für den web-Prozess bei Buildpack-Apps; bei Dockerfile-Apps lauscht die App auf dem Port des web-Prozesses (sonst dem EXPOSE des Images, sonst 8080).

Lief ein zweiter Service aus demselben Repo nur mit anderem Start Command, etwa als Worker, leg ihn unter Processes, New process als weiteren Prozess derselben App an und trag dort den Start Command ein. Einen Pre-deploy Command übernimmst du als release:-Zeile im Procfile (Buildpacks) oder als Release Command der App (Settings, Karte Preview environments, wo das Feld erscheint, sobald Previews aktiviert sind, oder release_command über die API). Er läuft bei jedem Deploy einmal vor web; schlägt er fehl, bleibt das vorherige Release aktiv.

4. Variablen übernehmen

Gib die Variablen eines Service als KEY=wert-Zeilen aus (Railway CLI):

bashrailway variable list --kv > railway.env

Füg die Zeilen unter Environment, Add many ein. Sealed Variables gibt die Railway-CLI nicht aus (Railway-Doku), die setzt du von Hand, als Secret mit nodion env set KEY=wert --secret. Prüf Werte mit Anführungszeichen, und setz mehrzeilige Werte per CLI oder API.

Referenzen wie ${{shared.KEY}} oder ${{andererService.KEY}} kennt Nodion nicht. Prüf jede importierte Variable: Sie muss den tatsächlichen Wert enthalten, nicht den Referenztext. Zeigte eine Referenz auf einen anderen Service, setz stattdessen dessen internen Hostnamen auf Nodion (<app>.app.internal) oder hänge die Datenbank an.

Variablen, die auf eine Railway-Datenbank zeigen (DATABASE_URL, REDIS_URL), löschst du wieder: Eine selbst gesetzte Variable überschreibt den Wert einer angehängten Datenbank. Häng die Datenbanken mit Attach database an. Intern läuft die Verbindung ohne TLS (sslmode=disable); erzwingt dein Code SSL, schalte das für diese URL ab.

5. Cron übernehmen

Auf Railway ist ein Cron-Job ein eigener Service, der läuft und sich beendet (Railway-Doku). Auf Nodion legst du ihn im Tab Cron der App an, deren Code er braucht: Zeitplan in UTC mit fünf Feldern, Befehl, Timeout bis 30 Minuten, bis zu 8 Jobs pro App. Er läuft mit dem aktiven Release und den Umgebungsvariablen der App.

6. Deployen, Domain umziehen, Railway abschalten

Deploye und prüf den Tab Logs. Trag dann die Domain im Tab Domains ein und setz die zwei Records, die Nodion anzeigt: TXT _nodion-challenge.deine-domain und einen CNAME (am Apex ein ALIAS) auf den Standard-Hostnamen der App. Das Zertifikat kommt, sobald der CNAME auf Nodion zeigt; rechne mit ein paar Minuten ohne gültiges Zertifikat und senk die TTL vorher. Läuft alles, lösch das Railway-Projekt; laut Railway ist das endgültig.

bashrailway delete --project my-project --yes

Was anders ist

• Es gibt keine Environments wie production und staging in einem Projekt; nimm dafür getrennte Apps oder Projekte.
• Es gibt keine Shared Variables und keine Referenzen; Datenbank-Werte kommen über das Anhängen.
• Cron Jobs laufen auf einer bestehenden App, nicht als eigener Service.
• Die CLI holt Logs, kann ihnen aber nicht folgen; live mitlesen kannst du im Tab Logs.

Weiter

Nodion und Railway im Vergleich, Preise, Applications und Datenbanken.