Railway zu Coolify oder eigener Infrastruktur migrieren
Timo Wevelsiep•Aktualisiert: 30.08.2026Hinweis zum Inhalt: Versionen, Befehle und Preise können sich ändern. Bitte prüfen Sie kritische Schritte vor dem produktiven Einsatz eigenständig. Dieser Leitfaden ersetzt keine individuelle Beratung.
Sie möchten Railway ablösen, den Git-basierten Workflow aber behalten? WZ-IT übernimmt die PaaS-Migration ab 1.990 Euro netto auf Coolify, Docker oder eine andere kontrollierbare Zielarchitektur.
Eine Migration von Railway zu Coolify oder eigener Infrastruktur betrifft mehr als den Anwendungscontainer. Railway organisiert Projekte, Environments, Services, Variablen, Domains, Volumes und Datenprodukte als zusammenhängende Plattform. Für einen belastbaren Wechsel muss jede genutzte Funktion im Ziel bewusst abgebildet werden.
Railway-Ressourcen vollständig erfassen
Das Inventar beginnt nicht beim Repository, sondern beim produktiven Railway-Projekt:
- Projects und Environments wie Production oder Staging
- Services aus Git-Repositories oder Container-Images
- Build- und Startkommandos, Ports und Health Checks
- Variablen sowie Referenzen zwischen Services
- öffentliche und private Domains
- Volumes, Mountpfade und tatsächlicher Datenbestand
- PostgreSQL, MySQL, Redis und weitere Datenservices
- Worker, Cronjobs und gekoppelte Hintergrundprozesse
- Deployment-Trigger, Branches und Rollback-Verhalten
Railway kann Konfiguration außerhalb des Repositories halten. Eine lokal funktionierende Anwendung beweist deshalb noch nicht, dass alle produktiven Variablen, Service-Adressen und Plattformannahmen erfasst sind.
Railway-Variablen und Service-Verbindungen übertragen
Variablen werden getrennt nach Environment und Service aufgenommen. Besondere Aufmerksamkeit benötigen Referenzvariablen, die Werte anderer Railway-Services übernehmen. Im Ziel entstehen daraus beispielsweise:
- interne DNS-Namen innerhalb eines Docker-Netzes
- explizite Datenbank- oder Redis-Verbindungen
- über Coolify verwaltete Umgebungsvariablen
- Secrets aus einem separaten Secret Management
Sensible Werte werden nicht ungeprüft exportiert und wiederverwendet. API-Schlüssel, Datenbankpasswörter und Webhook-Secrets können beim Cutover rotiert werden. Anwendungen und externe Integrationen müssen dann zeitlich abgestimmt auf die neuen Werte wechseln.
Services auf Coolify oder Docker abbilden
Ein Railway-Service wird im Ziel als Anwendung, Worker, geplanter Job oder Datenservice eingeordnet. Dabei sind Build und Betrieb getrennt zu prüfen:
| Railway-Ebene | Mögliche Zielabbildung |
|---|---|
| Git Service | Coolify-Anwendung mit Git-Deployment |
| Container Image | imagebasierter Coolify- oder Docker-Service |
| Worker | eigener Prozess ohne öffentlichen Endpoint |
| Cronjob | Plattform-Scheduler oder kontrollierter System-Timer |
| Private Domain | interner Service-Name im Zielnetz |
| Public Domain | Reverse Proxy, DNS und TLS |
| Volume | persistentes Ziel-Volume mit Backupweg |
| Datenbank | verwaltete oder dedizierte Datenbankinstanz |
Coolify ist dabei die mögliche Plattformebene für Builds und Deployments. Der Server kann bei einem deutschen oder europäischen Anbieter, im Rechenzentrum des Kunden oder in einer anderen geeigneten Umgebung laufen.
Datenbanken und Volumes migrieren
Persistenz wird unabhängig vom Anwendungsdeployment geplant. Für relationale Datenbanken sind Dump und Restore, ein nativer Export oder bei größeren und schreibaktiven Systemen ein Replikationsverfahren geeigneter als eine Kopie des laufenden Datenverzeichnisses.
Bei Volumes werden vor dem Transfer geklärt:
- Welche Dateien sind fachlich relevant?
- Kann die Anwendung während des Exports schreiben?
- Welche Nutzer, Gruppen und Dateirechte erwartet sie?
- Wie werden Anzahl, Größe und Prüfsummen validiert?
- Wie wird das Ziel-Volume gesichert und wiederhergestellt?
Ein erstes Deployment kann mit einem älteren Datenstand getestet werden. Der finale Sync erfolgt erst im vereinbarten Cutover-Fenster.
Git-Deployment, Staging und Produktion erhalten
Nach dem Wechsel kann ein Push weiterhin einen Build und ein Deployment auslösen. Die Delivery-Strecke wird jedoch explizit definiert:
- Branch oder Tag für Produktion
- getrennte Variablen und Datenzugänge für Staging
- Build- und Startkommando aus versionierter Konfiguration
- Health Check und Abbruchkriterium
- Freigabe vor dem produktiven Rollout
- Rollback auf ein vorheriges Image oder Deployment
Preview-Umgebungen können ergänzt werden, benötigen aber Regeln für Secrets, Datenzugriff, Domains und automatische Bereinigung.
Testlauf und Cutover
Die Zielumgebung wird vor der Umschaltung unter einer Testdomain geprüft. Dazu gehören Login, zentrale Nutzerwege, Worker, Cronjobs, Uploads, E-Mail, Webhooks, Neustart, Logs, Monitoring und Backup. Erst danach werden der finale Datenstand und DNS übertragen.
Wenn Zielarchitektur, Plattformabhängigkeiten oder Migrationsreihenfolge noch unklar sind, liefert der PaaS Exit Review zunächst eine Abhängigkeitskarte, Zieloptionen und einen umsetzbaren Migrationsplan.
Quellen
Lieber betreiben lassen?
Sie möchten PaaS & Cloud Exit nicht selbst betreiben? WZ-IT übernimmt Einrichtung, Betrieb und Wartung - datenschutzorientiert aus Deutschland.
Anfrage
PaaS-Migration einordnen
Beschreiben Sie Quelle, Anwendung und gewünschtes Ziel. Wir prüfen den Migrationsweg für Runtime, Daten, Delivery und anschließenden Betrieb.
Häufig gestellte Fragen
Antworten auf die wichtigsten Fragen
Viele Git- oder Container-basierte Anwendungen lassen sich gut abbilden. Railway-spezifische Service-Referenzen, Volumes, Datenprodukte, private Domains und Skalierungsannahmen müssen jedoch einzeln auf die Zielarchitektur übertragen werden.
Variablen werden je Environment und Service erfasst. Referenzen auf andere Railway-Services werden im Ziel durch neue interne Adressen oder verwaltete Secrets ersetzt. Sensible Werte können beim Wechsel rotiert werden.
Volume-Daten benötigen einen kontrollierten Export und Transfer. Dateirechte, Eigentümer, Mountpfade, Konsistenz und Prüfsummen werden geprüft. Datenbanken sollten mit datenbankspezifischen Export- oder Replikationsverfahren migriert werden.
Die PaaS-Migration beginnt bei 1.990 Euro netto. Services, Daten, Volumes, notwendige Codeänderungen, Zielplattform, Umgebungen und Cutover-Anforderungen bestimmen das konkrete Angebot.
