Railway

Deine Anwendung läuft irgendwo. Bei uns ist dieses Irgendwo Railway.

Was das ist

Eine Plattform, die aus einem Repository eine laufende Anwendung macht. Du hinterlegst, wie sie gebaut wird — bei uns ein Dockerfile je Dienst — und bekommst eine erreichbare Adresse. Kein Server, den jemand einrichtet, kein Betriebssystem, das jemand aktuell hält.

Warum Railway

Weil der Weg vom Repository zur laufenden Anwendung kurz ist. Repository verbinden — und das Ding ist live. Bei jedem Push auf den festgelegten Zweig neu, ohne dass jemand etwas anstößt.

Der Vergleich macht den Wert sichtbar. Dasselbe auf einer eigenen Maschine heißt: die passende GitHub Action schreiben, die den Docker-Deploy auslöst, Zugangsdaten dafür hinterlegen, das Zurückrollen selbst vorsehen, Logs zugänglich machen und Variablen je Umgebung von Hand pflegen. Nichts davon ist schwer. Es ist nur jedes Mal wieder ein Tag Arbeit, und danach pflegt es jemand.

Was du dir damit sparst:

• Umgebungen nebeneinander, jede mit eigenen Variablen — und die, die überall gelten, werden geteilt statt kopiert.
• Build-, Deploy- und Zugriffsprotokolle je Dienst als laufender Strom, dazu Prozessorlast, Speicher, Netz und Anfragen.
• Waagerechte Skalierung über mehrere Instanzen mit Lastverteilung, senkrechte über Prozessor und Speicher.
• Eine Veröffentlichungshistorie, die sich nicht mehr ändert, und Zurückrollen per Klick.
• Ein privates Netz zwischen deinen Diensten, nach außen eine Adresse mit Verschlüsselung ohne Zutun.
• Eine festlegbare Region, wenn Laufzeit oder Rechtslage es verlangen.

Weil Docker die Grenze ist, nicht die Plattform. Deine Anwendung wird als Container gebaut. Ein Container läuft überall — bei einem anderen Anbieter, in einem Rechenzentrum, auf einer eigenen Maschine. Was dich an Railway bindet, ist die Konfiguration drumherum, nicht die Anwendung selbst.

Dazu kommt der pragmatische Teil: Es funktioniert vom ersten Tag an, und ein Projekt, das noch keine Nutzer hat, kostet entsprechend wenig.

Was du damit zu tun hast

Beim Bootstrap wird ein Deployment-Item gezogen, und danach ist dein Grundgerüst veröffentlicht. Ab da passiert das Ausrollen im Hintergrund.

Die Adresse kommt über Cloudflare, Dateien liegen in einem S3-kompatiblen Speicher. Beides musst du nicht einrichten.

Was dagegen spricht

Für Vorhaben mit besonderen Anforderungen — eigenes Rechenzentrum, Kubernetes, die Cloud eines Kunden — ist Railway nicht die Antwort. Solche Ziele sind legitim; sie sind nur nichts, worüber am ersten Tag entschieden wird.

Und wenn ich woanders hin will

Dann wird das ein eigenes Item auf deinem Board, und dein Grundgerüst läuft bis dahin lokal weiter. Der Bootstrap kennt diesen Fall und hält ihn ausdrücklich offen, statt dich in eine Entscheidung zu drängen, die du am ersten Tag nicht treffen kannst.

Der Grund für den Standardweg ist nicht, dass es keine Alternativen gäbe. Er ist, dass jede offene Entscheidung am Anfang eine ist, an der ein Projekt hängenbleiben kann — und dass die meisten Vorhaben mit der Hausvorgabe gut fahren.