Railway-Alternative 2026: Welcher Hoster passt zum Stack?

Der Anlass für die Suche nach einer Railway-Alternative: Am 21. Oktober 2026 teilte Railway mit, dass Unbefugte möglicherweise auf Umgebungsvariablen von Kunden zugegriffen hatten, darunter auch auf entschlüsselte Inhalte. Railway schrieb: „All deployments are paused while we investigate“ – während der Untersuchung seien also alle Deployments ausgesetzt – und empfahl, Umgebungsvariablen und Zugangsdaten zu rotieren. Railways Mitteilung

Für einen Stack aus Webdienst, Postgres, Worker und Cronjobs ist Render die erste Railway-Alternative, die einen genaueren Blick verdient. Northflank ist der engste Konkurrent für Teams, die mehr Kontrolle über ihre Deployments brauchen. Fly.io passt zu bewusst gewählten Infrastrukturanforderungen, Coolify setzt Bereitschaft zum eigenen Serverbetrieb voraus, und Netlify eignet sich für ein ausgelagertes Frontend mit serverlosen Funktionen.

Zunächst gilt es, Zugangsdaten bei den ausstellenden Anbietern zu erneuern und Zugriffsprotokolle zu prüfen. Ein Plattformwechsel ist eine eigene Entscheidung. Wer dieselben Schlüssel in ein neues Dashboard exportiert, hat sie damit noch nicht rotiert. Und wer ein zweites Deployment vorbereitet, muss den Kundenverkehr nicht schon heute umleiten.

Die folgenden Preise und Funktionen wurden am 22. Oktober 2026 anhand der aktuellen Anbieterseiten geprüft. Das Zitat aus der Sicherheitsmitteilung beschreibt Railways damalige Ankündigung; es trifft keine Aussage über den aktuellen Deployment-Status. Dieser Vergleich bewertet, welche Plattform zum Anwendungsfall passt und wie aufwendig der Umzug ist. Er ordnet Anbieter nicht nach ihrer vermeintlichen Sicherheit.

Welche Railway-Alternative passt? Der Überblick

Entscheidend ist die gesamte Anwendung. Ein Dienst bleibt als Prozess verfügbar, um Anfragen zu beantworten; ein Worker verarbeitet Hintergrundaufgaben; Cron startet Arbeit nach Zeitplan. Postgres speichert relationale Daten, ein Volume dagegen Dateien außerhalb eines austauschbaren Anwendungscontainers. Das sind unterschiedliche Aufgaben, auch wenn sie gemeinsam in einem Dashboard erscheinen.

Die Einstiegspreise sind Ausgangspunkte, keine Angebote für den vollständigen Stack. Kostenpflichtige Rechenressourcen, kostenlose Testumgebungen, Softwarelizenzen und Verbrauchspreise sind getrennt ausgewiesen. So wird ein kostenloses Frontend nicht mit kostenlosem Hosting für Datenbank und Worker verwechselt. Alle Beträge sind in USD angegeben; weitere Komponenten und zusätzlicher Verbrauch kosten extra.

Die Angaben zu Komponenten und Secrets beschreiben die dokumentierten Betriebsmodelle. Verschlüsselung gespeicherter Daten verhindert nicht, dass Anwendungscode mit Zugriff auf Zugangsdaten diese auch verwendet. Fly.io weist beispielsweise ausdrücklich darauf hin, dass Personen mit Deployment-Zugriff Code bereitstellen können, der Secrets zur Laufzeit ausliest. Secrets bei Fly.io

Nach welchen Kriterien wurden die Plattformen ausgewählt?

Die Rangfolge richtet sich an kleine, bestehende Anwendungen mit dauerhaft gespeicherten Daten und Hintergrundaufgaben. Eine statische Landingpage stellt andere Anforderungen. Ausschlaggebend ist, ob sich die bisherigen Prozesse sauber abbilden lassen, wer Postgres betreibt, wo persistente Dateien liegen, wie geplante Aufgaben ausgeführt werden und wie Zugangsdaten den laufenden Code erreichen.

Grundlage sind die dokumentierten Funktionen und aktuellen Preise der Anbieter. Für diesen Artikel wurden die Plattformen weder selbst bereitgestellt noch mit Benchmarks getestet. Aus Marketingaussagen wurden keine Bewertungen für Verfügbarkeit, Leistung oder Sicherheit abgeleitet.

Plattformen zur Verwaltung von Entwicklungsumgebungen oder Kubernetes-Landschaften können nützlich sein, bringen aber eine zusätzliche Abstraktion mit, die hier womöglich nicht gebraucht wird. Die Auswahl konzentriert sich auf Plattformen, auf denen die Anwendung tatsächlich laufen kann. Netlify ist als bewusst enger gefasste Frontend-Option dabei. Die Entscheidung kann anders ausfallen, wenn die App gemeinsamen Dateisystemzugriff, ein bestimmtes Scheduler-Verhalten oder einen Anbieter braucht, der die Wiederherstellung der Datenbank verantwortet.

Die Plattformen: Rangfolge für diesen Stack

1. Render: Der erste Kandidat für einen Probelauf auf einer verwalteten Plattform

Render ist eine verwaltete Anwendungsplattform. Webdienste, Hintergrund-Worker, Cronjobs und verwaltetes Postgres bilden diesen Railway-Stack unmittelbar ab. Wer als Gründer eine API für Abonnements, einen E-Mail-Worker und einen nächtlichen Abgleich betreibt, findet für jeden Prozess einen klar vorgesehenen Diensttyp. Das begrenzt die nötigen Umbauten vor dem ersten Probelauf. Die wichtigste Einschränkung betrifft persistente Datenträger: Ein Dienst mit angebundenem Datenträger lässt sich nicht auf mehrere Instanzen skalieren; außerdem verhindert der Datenträger Deployments ohne Ausfallzeit. Render passt, wenn die bestehende Anwendungsstruktur wichtiger ist als eine individuell zugeschnittene Infrastruktur. Diensttypen · Datenträgerbeschränkungen

Geeignet für: Gründer, die eine vertraute verwaltete Umgebung für den gesamten Stack suchen.
Besonderheit: Eigene Diensttypen für API, Worker und geplante Aufgaben.
Preise: Kostenpflichtiger Dienst ab $7/Monat; Datenbank, Worker, Cron und mögliche Workspace-Gebühren werden separat berechnet. Aktuelle Preise
Kostenlos testen: Kostenlose Rechenressourcen mit Einschränkungen sind verfügbar; sie eignen sich zur Evaluierung.

Konfiguration lässt sich in Dienstvariablen oder Umgebungsgruppen ablegen. Eine Gruppe bündelt gemeinsame Werte, etwa wenn API und Worker dieselbe Datenbankadresse brauchen. Für Zugangsdaten, die eine Anwendung von einem Datenträger lesen soll, gibt es außerdem Secret-Dateien. Dem laufenden Dienst stehen sie als Klartextdateien zur Verfügung. Jeder Prozess sollte nur die Konfiguration erhalten, die er braucht, statt überall die vollständige Sammlung produktiver Secrets einzubinden. Umgebungsvariablen und Secrets

Die Datenträgerbeschränkung betrifft auch kleine Anwendungen. Erstellt der Worker eine PDF-Datei, die später der Webdienst lesen soll, macht ein am Worker eingebundener Datenträger diese Datei nicht automatisch für den Webdienst zugänglich. Für die Übergabe braucht es Objektspeicher oder eine andere Zuordnung der Datei vor dem Wechsel. Ein unveränderter Pfadname belegt nicht, dass beide Prozesse darauf zugreifen können.

Den ersten Render-Dienst im Probelauf aufsetzen

1. 1

   Die Prozessaufteilung nachbilden

   Den Webdienst aus dem Anwendungsrepository oder Container erstellen, anschließend den Worker mit eigenem Startbefehl anlegen. Die geplante Aufgabe kommt als Cronjob hinzu. Der neue Worker und der Zeitplan bleiben für Produktivdaten inaktiv, bis der Datenprobelauf vorbereitet ist.

2. 2

   Eine leere Zieldatenbank anlegen

   Render Postgres bereitstellen und einen Testexport nach Renders Anleitung für die Railway-Migration wiederherstellen. Die Verbindungszeichenfolgen des Ziels konfigurieren, statt Railway-interne Hostnamen zu übernehmen.

3. 3

   Neue Zugangsdaten setzen und den gesamten Ablauf testen

   Die Variablen aus der geprüften Bestandsliste eintragen. Unter einer temporären Domain Anmeldung, Datenbankschreibzugriff, einen eingereihten Auftrag und dessen Ergebnis testen. Externe Aktionen dabei auf Testkonten umleiten.

Renders Anleitung zur Railway-Migration beschreibt die plattformspezifischen Schritte. Die spätere Checkliste behandelt das, was ein erfolgreiches Deployment allein nicht nachweist: ob auch Daten und geplante Aufgaben sauber umgezogen sind.

2. Northflank: Für Teams mit höheren Ansprüchen an die Deployment-Steuerung

Northflank ist eine Containerplattform mit Anwendungsdiensten, Datenbank-Add-ons, geplanten Jobs und persistentem Speicher. Ein kleines Team mit API, Queue-Consumer und wiederkehrenden Importen kann diese gemeinsam abbilden und zugleich klare Regeln für Deployment und Konfiguration festlegen. Vorlagen und Pipelines werden interessant, sobald dasselbe System Staging- und Produktionsumgebungen braucht. Dafür ist beim Umzug eine umfangreichere Steuerung zu erlernen. Northflank passt, wenn die neue Plattform zugleich den Betrieb mehrerer Dienste verbessern soll. Plattformfunktionen

Geeignet für: Teams, die wiederverwendbare Deployment-Definitionen und mehr Kontrolle über ihre Umgebungen suchen.
Besonderheit: Dienste, Jobs, Datenbanken und Volumes mit der Möglichkeit, später in der eigenen Cloud bereitzustellen.
Preise: Kostenlose Sandbox; kostenpflichtige CPU ab $0.01667/vCPU-Stunde, RAM, Speicher und Netzwerk werden separat berechnet. Aktuelle Preise
Kostenlos testen: Die Sandbox ist ein kostenloser Tarif mit begrenztem Ressourcenkontingent.

Secret-Gruppen können Build-Argumente, Laufzeitvariablen und verknüpfte Datenbankzugangsdaten enthalten. Die geprüften Variablen werden importiert und die Gruppe auf die Dienste oder Umgebungen beschränkt, die sie benötigen. Geänderte Werte lassen sich über die Aktion zum Neustart abhängiger Dienste übernehmen. Das hilft etwa, wenn Worker und API dieselben Datenbankzugangsdaten brauchen, das Frontend aber nicht. Secret-Gruppen

Bei automatisierten Migrationen ist ein Detail besonders folgenreich: Wird eine Secret-Gruppe über API oder CLI aktualisiert, ersetzt die übermittelte Variablen- oder Dateisammlung den bisherigen Bestand – auch bei einer PATCH-Anfrage. Ein Skript, das nur den geänderten Schlüssel sendet, kann die übrigen Einträge entfernen. Deshalb zuerst die Gruppe auslesen, die gewünschte Änderung einarbeiten und dann die vollständige Sammlung nach dem dokumentierten Verfahren übermitteln.

Bei den Preisen kommt es auf die Summe an. Ein CPU-Preis ist noch keine monatliche Anwendungsrechnung: Arbeitsspeicher, persistenter Speicher und ausgehender Datenverkehr zählen ebenfalls. Auf Basis der Bestandsaufnahme müssen alle dauerhaft laufenden Komponenten kalkuliert werden. Erst dann lässt sich beurteilen, ob die zusätzlichen Steuerungsmöglichkeiten den Einrichtungsaufwand rechtfertigen.

3. Fly.io: Für bewusst gewählte Laufzeitumgebungen und Regionen

Fly.io betreibt Anwendungen in Machines: schlanken virtuellen Maschinen, die für die jeweilige Aufgabe konfiguriert werden. Das passt zu technisch versierten Gründern, die den Standort von API und Worker selbst bestimmen und mehr Deployment-Details verantworten möchten. Prozessgruppen oder getrennte Apps erlauben den unabhängigen Betrieb von Webprozess und Worker. Getrennte Apps können über das private Netzwerk von Fly.io kommunizieren. Zeitsteuerung und Datenablage müssen allerdings ausdrücklich geplant werden. Fly.io lohnt sich für Kontrolle, die tatsächlich gebraucht wird; der niedrigste Rechenpreis allein sollte nicht entscheiden. Prozesskonfiguration

Geeignet für: Technisch versierte Betreiber, die mit Machines, Regionen und expliziter Prozesskonfiguration umgehen können.
Besonderheit: Frei wählbare Platzierung einzelner Anwendungen und eine konfigurierbare Laufzeitumgebung.
Preise: Kleinste dauerhaft laufende Machine $2.19 pro 30 Tage in Ashburn oder Secaucus mit 256 MB RAM; verwaltetes Postgres, Speicher und Datenverkehr kommen hinzu. Aktuelle Preise
Kostenlos testen: Ein begrenzter Test ist verfügbar; neue Organisationen erhalten keinen dauerhaften kostenlosen Tarif.

Zu den dokumentierten Möglichkeiten für geplante Aufgaben gehören Cron Manager, eine App, die dafür temporäre Machines startet, und Supercronic, ein Cron-Runner innerhalb eines Containers. Beides sind brauchbare Optionen, die aber als Teil des Systems bereitgestellt und betrieben werden müssen. Ein Scheduler darf nicht versehentlich in mehrere Kopien skaliert werden, die anschließend dieselbe Zahlungserinnerung versenden. Zeitsteuerung von Aufgaben

Fly speichert App-Secrets in einem verschlüsselten Tresor und bindet sie beim Start der Machines ein. Die Prozessgruppen einer App teilen sich diese Secrets; getrennte Apps brauchen eine eigene Konfiguration. Unterschiedliche Anforderungen an Zugangsdaten können daher ein Grund sein, Prozesse aufzuteilen. Die zusätzliche Konfiguration gehört dann in die Bestandsaufnahme.

Vor einem Regionswechsel sollte der Datenbankstandort feststehen. Eine API näher am Nutzer kann trotzdem langsam sein, wenn jede Anfrage mehrfach über Regionsgrenzen hinweg auf die Datenbank zugreift. Außerdem ist zwischen Fly.io Managed Postgres und einer selbst betriebenen Datenbank auf einer Machine mit Volume zu unterscheiden. Letzteres stellt einen Server bereit, überträgt aber die Verantwortung für den Datenbankbetrieb nicht auf einen verwalteten Dienst.

4. DigitalOcean App Platform: Für zustandslose Anwendungen bei DigitalOcean

DigitalOcean App Platform ist eine verwaltete Hostingplattform mit Webdiensten, Workern und Jobs. Ergänzend stehen DigitalOcean Managed Databases zur Verfügung. Sie passt zu Gründern, deren Anwendung hochgeladene Dateien bereits außerhalb ihrer Container speichert und die Anwendung und Datenbank bei einem Anbieter bündeln möchten. Native zeitgesteuerte Jobs sind inzwischen dokumentiert; ein externer Scheduler ist deshalb nicht automatisch nötig. Die entscheidende Grenze liegt beim Speicher: App Platform unterstützt keine Volumes. Sie eignet sich, wenn die Anwendung ihr lokales Dateisystem als temporär behandeln kann. Grenzen von App Platform

Geeignet für: Zustandslose APIs und Worker, besonders bei bestehenden DigitalOcean-Kunden.
Besonderheit: Verwaltete Anwendungskomponenten mit nativen zeitgesteuerten Jobs.
Preise: Kostenpflichtiger Container ab $5/Monat; Datenbanken, weitere Container und zusätzlicher Verbrauch werden separat berechnet. Aktuelle Preise
Kostenlos testen: Es gibt ein kostenloses Angebot für statische Websites; es deckt diesen vollständigen Backend-Stack nicht ab.

Umgebungsvariablen auf App- und Komponentenebene lassen sich auf Build oder Laufzeit beschränken. Für sensible Werte ist die Option Encrypt vorgesehen. Laut DigitalOcean blendet sie diese Werte in Build-, Deployment- und Anwendungsprotokollen aus. Ein Datenbankpasswort gehört nur dann in den Frontend-Build, wenn dieser tatsächlich Datenbankzugriff benötigt. Umgebungsvariablen

Der Scheduler unterstützt wiederkehrende Jobs mit einem Mindestabstand von 15 Minuten. Für einen nächtlichen Bericht reicht das; eine Aufgabe, die häufiger starten soll, braucht eine andere Umsetzung oder Plattform. Vor der Einstufung als gleichwertiger Ersatz sind Zeitplan, Zeitzone und die längste beobachtete Laufzeit des Jobs zu prüfen. Geplante Jobs konfigurieren

Ein üblicher Weg für Dateien ist, das lokale Upload-Verzeichnis durch Objektspeicher zu ersetzen und die Objektkennungen in Postgres abzulegen. Das verändert die Anwendung und muss vor der Verkehrsumleitung getestet werden. Ein in das Container-Image kopiertes Verzeichnis macht künftige Nutzer-Uploads nicht dauerhaft. Ebenso muss die Managed Database für den Produktivbetrieb unabhängig von der Entwicklungsdatenbank bewertet werden, die auf der App-Preisseite erscheint.

5. Heroku: Für Teams, die das Dyno-Modell bereits kennen

Heroku ist eine verwaltete Anwendungsplattform auf Basis von Dynos: Containern für Webprozesse, Worker und einmalige Aufgaben. Sie ist ein praktikables Ziel, wenn das Team das Prozessmodell bereits kennt und verwaltetes Heroku Postgres nutzen möchte. Eine klassische Webanwendung mit separatem Queue-Consumer lässt sich gut abbilden. Die Grenzen liegen beim flüchtigen Dateisystem und beim Verhalten von Heroku Scheduler. Heroku passt, wenn das vertraute Betriebsmodell hilft und ein konkreter Plan für Dateien und kritische Zeitpläne vorliegt. Dyno-Dokumentation

Geeignet für: Teams, die mit Herokus Deployment- und Prozesskonventionen bereits vertraut sind.
Besonderheit: Web- und Worker-Dynos neben verwaltetem Postgres.
Preise: Dauerhaft laufender Basic-Dyno ab $7/Monat; Datenbank, Worker und Rechenleistung für geplante Aufgaben kommen hinzu. Aktuelle Preise
Kostenlos testen: Ein kostenloser Backend-Tarif sollte nicht eingeplant werden; die genannte dauerhaft laufende Option ist kostenpflichtig.

Heroku speichert Konfiguration dauerhaft als App-Konfigurationsvariablen und stellt sie als Umgebungsvariablen bereit. Jede Änderung an einer solchen Variable erzeugt ein Release und startet die Anwendung neu. Eine Rotation muss deshalb als Eingriff in den Anwendungsbetrieb geplant werden: neue Zugangsdaten prüfen, den Neustart beobachten und anschließend die bisherigen Zugangsdaten beim Aussteller entfernen. Konfigurationsvariablen

Laut Dokumentation von Heroku Scheduler ist die Ausführung von Jobs zu erwarten, aber nicht garantiert. Für kritische geplante Aufgaben empfiehlt sie einen eigenen Taktgeberprozess. Eine ausgefallene Cache-Bereinigung hat andere Folgen als ein ausgefallener Abrechnungsabgleich. Letzterer braucht ein überprüfbares Ausführungsprotokoll, Wiederholungsversuche und eine bewusste Wahl des Schedulers. Verhalten von Scheduler

Basic-Dynos unterstützen zudem keine horizontale Skalierung. Zusätzliche parallele Instanzen erfordern einen anderen Dyno-Tarif. Für einen Probelauf kann Basic völlig ausreichen; der Tarif, mit dem die App startet, ist aber nicht automatisch der richtige für Kundenverkehr. Dateien innerhalb eines Dynos verschwinden beim Stoppen oder Neustarten. Dauerhaft benötigte Uploads müssen deshalb vor dem Umzug ausgelagert werden.

6. Koyeb: Für Dienste ohne produktive Abhängigkeit von Volumes

Koyeb ist eine Anwendungsplattform für Webdienste, Worker und verwaltetes serverloses Postgres. Sie ist einen Blick wert, wenn API und Hintergrundverarbeitung bereits ohne lokale persistente Dateien auskommen. Das Dienstmodell akzeptiert Quellcode oder fertige Container und bietet damit einen unkomplizierten Ausgangspunkt für einen Deployment-Probelauf. Für Railway-Anwendungen, die stark von Volumes abhängen, benennt die Koyeb-Dokumentation ein klares Hindernis: Volumes befinden sich in der öffentlichen Vorschau und sind ausdrücklich nur für Tests vorgesehen. Koyeb gehört für zustandslose Teile des Stacks in die engere Auswahl; produktive Volumes ersetzt es nicht gleichwertig. Dienstmodell · Status der Volumes

Geeignet für: Webdienste und Worker, deren dauerhafte Daten bereits außerhalb von App-Volumes liegen.
Besonderheit: Separate Diensttypen für Web und Worker sowie verfügbares serverloses Postgres.
Preise: Ausgewiesener Pro-Einstieg $29/Monat zuzüglich Rechenleistung, einschließlich $10 für Rechenleistung; kein Gesamtpreis für den vollständigen Stack. Aktuelle Preise
Kostenlos testen: Einzelne kostenlose Ressourcenkontingente bedeuten nicht, dass der gesamte Stack kostenlos ist.

Koyeb Secrets sind Werte auf Organisationsebene, die serverseitig verschlüsselt und Diensten ausdrücklich zugewiesen werden. Ein Dienst kann ein Secret über eine Umgebungsvariable nutzen. Die Wiederverwendung vereinfacht etwa die Datenbankkonfiguration. Gerade wegen der organisationsweiten Verfügbarkeit muss aber bewusst entschieden werden, welcher Dienst welchen Wert erhält. Secrets-Dokumentation

Die Dienstreferenz von Koyeb definiert Webdienste und Worker. Für Cron ist ein Scheduler innerhalb eines Workers oder ein externer Auslöser einzuplanen und im Probelauf zu prüfen. Der Railway-Zeitplan geht nicht automatisch mit über; auch dieser Vergleich belegt keinen gleichwertigen nativen Cron-Dienst.

Für die Kostenplanung müssen Pro-Tarif und Ressourcenverbrauch von Diensten und Datenbank zusammen betrachtet werden. Durch die enthaltene Rechenleistung ist der Tarifpreis eine andere Vergleichsgröße als der kleinste App-Container eines anderen Anbieters. Welche Plattform günstiger ist, lässt sich erst anhand einer Kalkulation für die konkrete Anwendung entscheiden.

7. Coolify auf einem VPS: Wenn der Betrieb in eigener Verantwortung liegen kann

Coolify ist selbst gehostete Deployment-Software für Anwendungen und Datenbanken auf selbst kontrollierten Servern. Auf einem VPS, einem gemieteten virtuellen Server, lassen sich ein containerbasierter Webdienst, Worker, Postgres und geplante Aufgaben nachbilden, ohne für jede Komponente eine verwaltete Anwendungsplattform zu benötigen. Das ist für technisch versierte Gründer interessant, die die Betriebsumgebung selbst verantworten wollen. Genau dort liegt die Grenze: Ein komfortables Dashboard macht aus selbst betriebenem Postgres keine vom Anbieter verwaltete Datenbank. Coolify ist nur dann eine gute Wahl, wenn jemand für Serverwartung, Backups und Wiederherstellung verantwortlich ist. Coolify-Dokumentation

Geeignet für: Technisch versierte Betreiber, die Serverkontrolle wünschen und die Wartung übernehmen.
Besonderheit: Deployment-Abläufe für Anwendungen und Datenbanken auf eigener Infrastruktur.
Preise: Kostenlose Software zum Selbsthosting, zuzüglich VPS; ein beispielhafter DigitalOcean-Server mit 4 GiB und 2 vCPU kostet $24/Monat, ohne Backups und weitere Dienste. Coolify-Preise · VPS-Preise
Kostenlos testen: Die selbst gehostete Software ist kostenlos; ein Server ist darin nicht enthalten.

Dieser Server dient als Beispiel, nicht als Empfehlung zur Dimensionierung. Liegt alles auf einer Maschine, konkurrieren Builds, Datenbank und Kundenanfragen um dieselben Ressourcen. Ein speicherintensiver Build kann dadurch zum Problem für die Anwendung werden. Der Ressourcenbedarf muss gemessen, eine Reserve für den Betrieb eingeplant und entschieden werden, welche Komponenten anderswo laufen sollen.

Coolify verwaltet Anwendungsvariablen mit Einstellungen für Build und Laufzeit. Laut Backup-Dokumentation werden gespeicherte Zugangsdaten und private Schlüssel in der Datenbank mit dem APP_KEY der Instanz verschlüsselt. Dieser Schlüssel muss separat neben einem wiederherstellbaren Instanz-Backup gesichert werden. Erst im Ausfall festzustellen, dass zur wiederhergestellten Datenbank der Schlüssel fehlt, wäre ein schlechter Wiederherstellungsplan. Instanz-Backup und Verschlüsselungsschlüssel

Geplante Aufgaben führen Befehle in Anwendungs- oder Dienstcontainern aus und setzen voraus, dass Anwendung und Server verfügbar sind. Persistenter Speicher nutzt die Volumes und Einbindungen des Servers. Das sind nützliche Bausteine. Liegen Anwendung, Datenbank und einziges Backup jedoch auf demselben VPS, hängt alles von diesem Server ab. Material zur Wiederherstellung gehört an einen unabhängigen Ort; der Neuaufbau muss geprobt werden. Geplante Aufgaben · Persistenter Speicher

8. Netlify: Für Frontend und serverlose Funktionen

Netlify ist eine Deployment-Plattform für Frontends mit serverlosen Funktionen. Sie passt in diesen Vergleich, wenn sich dieser Teil vom dauerhaft laufenden Backend trennen lässt. Beispielsweise können Marketingwebsite und Frontend umziehen, während API und Queue-Worker auf Render oder Northflank laufen. Netlify bietet inzwischen über Netlify Database auch verwaltetes Postgres an. Die Aussage, Netlify habe kein verwaltetes Postgres, wäre daher falsch. Der verbleibende Unterschied liegt in der Ausführung: Zeitlich begrenzte Funktionen werden dadurch nicht zu dauerhaft laufenden Diensten oder Queue-Consumern. Netlify eignet sich für den Teil, der zu seinem Funktionsmodell passt. Dokumentation zu Netlify Database

Geeignet für: Ein getrenntes Frontend mit anfragegesteuerten oder zeitlich begrenzten Hintergrundfunktionen.
Besonderheit: Frontend-Deployments, Funktionen und eine integrierte Option für verwaltetes Postgres.
Preise: Kostenloser Einstieg; Personal ab $9/Monat, mit Credit-basierter Nutzung. Aktuelle Preise
Kostenlos testen: Ein kostenloser Tarif ist verfügbar; seine Grenzen gelten auch für bereitgestellte Anwendungen.

Netlify Background Functions haben eine maximale Ausführungsdauer von 15 Minuten. Sie können asynchrone Aufgaben erledigen, lassen sich wegen dieser Grenze aber nicht als unbegrenzt laufende Queue-Consumer einsetzen. Scheduled Functions können Aufgaben über Cron-Ausdrücke auslösen; es bleiben Funktionen mit Ausführungsgrenzen. Ein Prozess, der fortlaufend eine Queue abfragt, braucht eine andere Laufzeitumgebung oder einen bewussten Umbau in zeitlich begrenzte Aufrufe. Background Functions · Scheduled Functions

Sensible Werte gehören in Netlifys Benutzeroberfläche, CLI oder API statt in die Repository-Konfiguration. Die Dokumentation unterscheidet zwischen auf der Plattform gespeicherten Variablen und Werten in netlify.toml. Werte je Deployment-Kontext erlauben getrennte Zugangsdaten für Vorschauumgebungen. Kontrollen für Geltungsbereiche und Secret-Funktionen hängen vom Tarif ab. Ein Wert, der in Browser-JavaScript eingebettet wird, bleibt außerdem im Browser sichtbar – unabhängig davon, wo der Build ihn ursprünglich ausgelesen hat. Umgebungsvariablen

Netlify Database kann Postgres innerhalb seines unterstützten Ablaufs bereitstellen, migrieren und Datenbankzweige anlegen. Das belegt aber noch nicht, dass vorhandene Datenbankerweiterungen, Importanforderungen oder die Worker-Architektur unverändert passen. Netlify Blobs ist Objektspeicher, kein eingebundenes Anwendungsdateisystem. Das bisherige Backend sollte zunächst zusammenbleiben, wenn eine Aufteilung aus dem Umzugsprobelauf eine Neuentwicklung machen würde. Blobs-Dokumentation

Netlify ansehen, wenn Frontend und Funktionen genau den Teil bilden, der umziehen soll.

Welche Railway-Hosting-Alternative ist die richtige?

Render ist der erste Kandidat, wenn der Probelauf mit möglichst wenigen Änderungen an der Prozessaufteilung gelingen soll. Northflank sollte parallel geprüft werden, wenn wiederverwendbare Umgebungen, Pipelines oder ein späterer Wechsel in die eigene Cloud wichtige Anforderungen sind. Den direkten Vergleich behandelt Railway vs Render.

Fly.io passt, wenn sich der Bedarf an Kontrolle über Laufzeitumgebung oder Regionen konkret begründen lässt. DigitalOcean App Platform passt, wenn lokale Dateien bereits entbehrlich sind und die Zeitpläne unterstützt werden. Heroku ist sinnvoll, wenn das bekannte Betriebsmodell den Umzugsaufwand senkt; kritische Annahmen über Scheduler müssen dabei ausdrücklich durch eine geeignete Lösung ersetzt werden.

Koyeb gehört in die engere Auswahl für zustandslose Anwendungen, unter Beachtung des aktuellen Volume-Hinweises. Coolify kommt bei bewusst übernommener Betriebsverantwortung infrage, mit einer benannten zuständigen Person. Netlify gehört auf die Liste für Frontends und serverlose Funktionen, auch wenn es inzwischen ebenfalls eine verwaltete Datenbank anbietet.

Die entscheidende Regel lautet: Wenn eine erforderliche Funktion nur durch einen Umbau der Anwendung erhalten bleibt, ist dieser Hoster nicht das Ausweichziel mit dem geringsten Aufwand. Als dauerhaftes Ziel kann er dennoch richtig sein. Umbau und Probelauf gehören dann aber zur Kostenrechnung des Umzugs.

Migrationscheckliste: Von Railway zum erprobten Umstieg

Eine zweite Plattform ist einsatzbereit, wenn sich dort die Daten wiederherstellen lassen und die wichtigen Abläufe der Anwendung funktionieren. Ein erfolgreiches Deployment ist nur der erste Prüfpunkt. Dieselbe Checkliste hilft beim vollständigen Umzug und beim Vorbereiten eines Ziels, das erst später aktiviert werden soll.

1. 1

   Das laufende System erfassen

   Für jeden Dienst Quellcodestand oder Image, Build- und Startbefehle, Laufzeitversion, Zustandsprüfung, Ressourcenbedarf, Region und Abhängigkeiten dokumentieren. Dazu kommen Postgres-Datenbanken, Erweiterungen und Rollen, persistente Verzeichnisse, Queue- oder Cache-Dienste, Freigabelisten für ausgehende IP-Adressen, Domains sowie jede geplante Aufgabe mit ihrer Zeitzone. Für jeden Punkt eine verantwortliche Person benennen.

   Festhalten, welche Aufträge der Worker verarbeitet und wo der Bearbeitungsstand gespeichert wird. Eine als Web, Postgres, Worker und Cron beschriebene Anwendung kann zusätzlich von einem Queue-Dienst, einem Datei-Bucket oder einem E-Mail-Anbieter abhängen. Auch wenn diese nicht umziehen, muss das Ziel auf sie zugreifen können.

2. 2

   Konfiguration exportieren und Zugangsdaten beim Aussteller rotieren

   Variablen in eine temporäre Bestandsliste mit eingeschränktem Zugriff exportieren. Nicht geheime Einstellungen von Datenbankzugangsdaten, API-Schlüsseln, Registry-Zugangsdaten, Signaturschlüsseln und vom Anbieter erzeugten Adressen trennen. Dokumentieren, welche Prozesse welchen Wert nutzen und ob sie ihn beim Build oder erst zur Laufzeit benötigen. Der Export gehört weder in die Versionsverwaltung noch in Tickets oder Chats.

   Bei den ausstellenden Anbietern neue Zugangsdaten mit den erforderlichen Berechtigungen und Geltungsbereichen erstellen. Diese am vorgesehenen Ziel und in allen weiterlaufenden Diensten der Ausgangsumgebung hinterlegen. Zugriff prüfen, abgelöste Zugangsdaten zügig widerrufen und Anbieterprotokolle kontrollieren. Falls die Hinweise zum konkreten Vorfall einen schnelleren Widerruf verlangen, haben sie Vorrang. Die Absicherung der Zugangsdaten darf nicht auf den Plattformwechsel warten.

   Für Datenbankpasswörter, Webhook-Signaturschlüssel und Datenverschlüsselungsschlüssel gelten unterschiedliche Rotationsverfahren. Wird ein Verschlüsselungsschlüssel ersetzt, ohne die Entschlüsselung bestehender Daten sicherzustellen, kann die Anwendung ausfallen. Das Verfahren muss für jeden Zugangsschlüssel dokumentiert werden, einschließlich der Nutzer außerhalb von Railway. Einen Schlüssel zu kopieren ist ein Export; den alten Schlüssel unbrauchbar zu machen ist Rotation.

3. 3

   Postgres-Export und Wiederherstellung proben

   Eine leere Zieldatenbank anlegen. Vor der Datenübertragung unterstützte Erweiterungen, Sortierreihenfolge, Zeichenkodierung, Rollen und Berechtigungen prüfen. Einen kompatiblen pg_dump-Client verwenden und ein Archiv im Custom-Format mit pg_restore wiederherstellen oder dem unterstützten Importverfahren des Zielanbieters folgen. Renders Railway-Anleitung beschreibt einen konkreten Ablauf für dieses Ziel.

   Ein logischer Dump ist eine Momentaufnahme der Datenbank, kein fortlaufender Replikationsstrom. Eine Testkopie wiederherstellen, Wiederherstellungsfehler prüfen, Datensatzanzahlen je Tabelle und repräsentative Geschäftsdaten vergleichen, Sequenzwerte kontrollieren und die Datenbankmigrationen der Anwendung gezielt ausführen. Lese- und Schreibzugriffe mit den Zugangsdaten des Ziels testen. Rollen, Berechtigungsvergaben und weitere Konfiguration auf Clusterebene müssen separat geprüft werden.

   Für die endgültige Übertragung schreibende Prozesse an der Quelle stoppen oder deren Schreibzugriff sperren und den finalen Export erstellen. Eine Ausnahme ist ein unterstütztes Replikationsverfahren mit zuvor erprobter abschließender Synchronisation. Kann das Unternehmen die gemessene Wiederherstellungsdauer nicht akzeptieren, muss dieses Replikationsverfahren vor der Terminwahl für den Wechsel geplant werden. Ein früher erfolgreich erstellter Dump enthält keine später eingegangenen Bestellungen.

4. 4

   Volumes übertragen und Dateizugriffe klären

   Für jeden persistenten Pfad feststellen, was darin liegt: Uploads, erzeugte Dokumente, Anwendungszustand oder eine Datenbank. Gewöhnliche Dateien in den Zielspeicher kopieren, erforderliche Eigentümerzuordnung und Berechtigungen erhalten und Anzahl, Größe oder Prüfsummen überprüfen. Nach dem Stoppen schreibender Prozesse abschließend synchronisieren.

   Für eine Datenbank deren unterstütztes Backup- oder Migrationsverfahren verwenden. Laufende Datenbankdateien dürfen nicht wie gewöhnliche Uploads kopiert werden. Bei gemeinsam genutzten Anwendungsdateien muss jeder lesende Prozess den neuen Speicherort erreichen können. Unterstützt das Ziel keine Volumes, ist der Wechsel zu Objektspeicher eine Migration von Code und Speicher, keine bloße Änderung des Einbindungspfads.

5. 5

   Privates Netzwerk und Domaineinstellungen nachbilden

   Railway-interne Hostnamen durch die internen Endpunkte des Ziels ersetzen. Prüfen, ob Webdienst, Worker und geplante Aufgaben Postgres und vorhandene Queues per Namensauflösung finden und erreichen können. TLS-Einstellungen der Datenbank abstimmen und bei Bedarf IP-Freigabelisten externer Anbieter aktualisieren. Eine private Datenbank darf nicht allein deshalb öffentlich erreichbar werden, um ein altes Verbindungsmuster beizubehalten.

   Für den Probelauf eine temporäre Domain am Ziel nutzen. Eigene Domains und Zertifikate vorbereiten, anschließend OAuth-Callbacks, Webhook-Ziele, erlaubte Origins, Cookie-Domains und die Basis-URL der Anwendung prüfen. Falls für den Wechsel hilfreich, die DNS-Cache-Dauer im Voraus verkürzen. Dabei Resolver berücksichtigen, die ältere Einträge weiter vorhalten.

6. 6

   Den Ablauf mit begrenzten externen Auswirkungen proben

   Einen Nutzerablauf mit Anmeldung, Schreibzugriff, Queue-Auftrag, geplanter Aufgabe und daraus entstehender Datei oder Benachrichtigung testen. Testkonten für Zahlungen und E-Mails verwenden oder externe Aktionen deaktivieren. Die Wiederherstellungsdauer und die beobachtbaren Kriterien dokumentieren, anhand derer das Ziel als bereit gilt.

   Cron und den Consumer der produktiven Queue am Ziel inaktiv lassen, solange die Quelle die Aufgaben bearbeitet. Eine Ausweichumgebung, die dieselben Rechnungen versendet oder dieselben Jobs verarbeitet, greift bereits in den Produktivbetrieb ein. Aufgaben müssen sicher wiederholbar sein; abgeschlossene Ausführungen dauerhaft protokollieren, damit sich Doppelverarbeitung erkennen lässt.

7. 7

   Stufenweise umschalten und nur eine maßgebliche Schreibquelle zulassen

   Zeitpläne pausieren und Hintergrundaufgaben je nach Verhalten der Queue stoppen oder auslaufen lassen. Schreibzugriffe an der Quelle sperren, die abschließende Datenbankübertragung und Dateisynchronisation durchführen und das Ziel prüfen. Den Datenverkehr zur neuen Anwendung leiten, anschließend deren Worker und Zeitpläne bewusst aktivieren.

   Anwendungsfehler, Datenbankverbindungen, Wartezeiten in der Queue, Aufgabenabschlüsse und externe Auswirkungen beobachten. Die Ausgangsumgebung als kontrollierte Wiederherstellungsoption mit gesperrten Schreibzugriffen erhalten. Beide Umgebungen parallel mit auseinanderlaufenden Datenbanken aktiv zu lassen, schafft keine verlässliche Rückfallmöglichkeit.

   Vor dem Wechsel festlegen, was passiert, wenn das Ziel neue Schreibzugriffe annimmt und danach ausfällt. Bei einer DNS-Rückschaltung zur alten Datenbank würden der aktiven Anwendung diese neuen Änderungen fehlen. Für die Wiederherstellung kann es nötig sein, das Ziel zu reparieren, wiederherzustellen oder dessen neue Daten zurückzuübertragen. Die Entscheidungsregel dafür muss vor dem ersten Kundenverkehr stehen.

Das Datenbankverfahren orientiert sich an der Dump-Dokumentation von PostgreSQL und Renders Anleitung zur Railway-Migration. Die Reihenfolge oben ist eine Betriebsempfehlung. Sie muss an der eigenen Anwendung geprüft werden und ist keine Garantie für einen Wechsel ohne Ausfallzeit.

Für eine Ausweichumgebung die Bestandsaufnahme aktuell halten, die erforderliche Aktualität wiederhergestellter Daten festlegen und den Probelauf bei Änderungen an Anwendung oder Schema wiederholen. Ein veraltetes Deployment ohne getesteten Wiederherstellungsweg ist eine Repository-Kopie, kein einsatzbereiter Ersatz.

Welche Optionen für diesen Umzug nicht passen

Netlify eignet sich nicht als unverändertes Ziel für einen dauerhaft laufenden Queue-Worker. Sein Funktionsmodell sollte dort eingesetzt werden, wo es passt; andernfalls bleibt der Worker auf einer Dienstplattform. Verwaltetes Postgres ändert nichts an den Ausführungsgrenzen der Funktionen.

Koyeb-Volumes eignen sich nicht für diese produktive Migration, solange die Dokumentation sie ausschließlich für Tests vorsieht. Eine externe Datenbank oder ein Objektspeicher kann Koyeb passend machen, bedeutet aber eine andere Speicherarchitektur.

DigitalOcean App Platform und Heroku sind kein unverändertes Ziel für Anwendungen, die auf dauerhafte lokale Dateien angewiesen sind. Keines der beiden Laufzeitmodelle erhält solche Dateien wie ein eingebundenes Railway-Volume. Die Speicherabhängigkeit muss zuerst gelöst werden.

Coolify scheidet aus, wenn niemand den Serverbetrieb übernimmt. Die Software kann Deployments vereinfachen, beseitigt aber keine ungeklärte Betriebsverantwortung.

Schließlich sollte keine Plattform nur deshalb gewählt werden, weil ihre kleinste beworbene Ressource günstig ist. Eine funktionierende API ohne ihre Datenbank, Queue-Verarbeitung und Zeitpläne ist nicht das System, das wiederhergestellt werden muss.

Häufige Fragen zu Railway-Alternativen

Welche Railway-Alternative ist die beste?

Für diesen Stack aus Webdienst, Postgres, Worker und Cron empfiehlt sich zuerst Render, daneben Northflank. Fly.io ist stärker, wenn gezielte Kontrolle über die Laufzeitumgebung gefragt ist. Coolify passt zum eigenverantwortlichen Serverbetrieb, Netlify zum Frontend und zu zeitlich begrenzten Funktionen. Erforderliche Dateispeicherung oder bestimmtes Scheduler-Verhalten können die Reihenfolge verändern.

Welche Railway-Alternative ist kostenlos?

Northflank bietet eine begrenzte kostenlose Sandbox; Render und Netlify haben kostenlose Angebote, die unterschiedliche Teile einer Anwendung abdecken. Auch kostenloses, selbst gehostetes Coolify braucht einen Server. Keine dieser Bezeichnungen belegt, dass die gesamte produktive Anwendung einschließlich Backups und Betriebsanforderungen ohne Kosten auskommt.

Welche Open-Source-Alternative zu Railway kommt infrage?

Coolify ist in diesem Vergleich der Weg zum Selbsthosting. Es eignet sich, wenn Container und Datenbanken auf einem eigenen VPS laufen sollen und die Verantwortung für Updates, Kapazität und Wiederherstellung übernommen werden kann. Die Deployment-Oberfläche ersetzt es leichter als die Menschen, die Infrastruktur betreiben.

Railway oder Render: Was spricht für den Wechsel?

Render ist hier der erste Kandidat für einen Probelauf, weil Web-, Worker-, Cron- und verwaltete Postgres-Komponenten zum beschriebenen Stack passen. Die Beschränkungen persistenter Datenträger müssen trotzdem geprüft werden. Zugangsdaten sollten unabhängig von einem späteren Wechsel entsprechend Railways Hinweisen zum Vorfall rotiert werden.