Railway behalten
- Ein Dienst, kleine Last, du willst den Server nicht sehen.
Railway Alternative, wenn die Nutzung plötzlich die Rechnung schreibt
Railway erkennt den Stack und startet. Das ist ehrlich praktisch. Unpraktisch wird es, wenn drei Dienste plus Datenbank dauernd laufen – dann zahlst du Verbrauch, nicht eine Box.
- Ein fester Server (dein SSH oder unserer) statt Verbrauch pro Stunde
- iOS-Builds und Store-Uploads sitzen im selben Projekt, nicht in einem zweiten Tool
Verbrauch oder Miete
Eigene Maschinen
- Mehrere Container, planbare Kosten, oder SSH ist Pflicht.
Railway fühlt sich an wie Heroku ohne die Altlast. Die Überraschung kommt auf der Rechnung, wenn Worker, Datenbank und Staging dieselbe Nutzungsuhr teilen. Wer das kennt, sucht nicht mehr Komfort, sondern eine Maschine mit Preis.
Verbrauch gegen einen festen Server
Railway rechnet nach Last. Unsere Seite nach Plattform plus Box.
| Kriterium |
Application Platform
|
Railway
|
|---|---|---|
| Container-Deployments | Vollständig abgedeckt: Docker-basierte Deployments über vorbereitete Pipelines | Vollständig abgedeckt: Kernprodukt, sehr schnell eingerichtet |
| Bedienung und Einstieg | Vollständig abgedeckt: Assistent für das Projekt-Setup, danach Arbeit über Git und Pipelines | Vollständig abgedeckt: Sehr direkte Oberfläche, wenige Schritte bis zum ersten Deployment |
| Datenbanken per Klick | Vollständig abgedeckt: Datenbanken werden beim Server-Setup mit Backups eingerichtet | Vollständig abgedeckt: Verwaltete Datenbanken in wenigen Klicks, inklusive Skalierung |
| Eigene Server nutzen | Vollständig abgedeckt: Eigener Server per SSH oder Managed Server der Plattform | Nicht angeboten: Nicht vorgesehen, Ausführung in der Railway-Infrastruktur |
| Server-Grundsetup mit Zugriff | Vollständig abgedeckt: Docker, Reverse-Proxy, SSL, Firewall und Backups auf deinem Server | Teilweise abgedeckt: Von der Plattform gekapselt, kein Zugriff auf die Maschine |
| Globales Edge-Netzwerk / CDN | Teilweise abgedeckt: Reverse-Proxy und SSL pro Server; kein eigenes globales Edge-Netz | Teilweise abgedeckt: Mehrere Regionen wählbar, Auslieferung nah am Nutzer |
| Kostenmodell | Vollständig abgedeckt: Plattform plus eigene Server, dadurch planbar | Teilweise abgedeckt: Nutzungsbasiert, günstig bei kleiner Last, schwerer vorherzusagen |
| Mobile Apps bauen | Vollständig abgedeckt: Flutter, Expo sowie native iOS- und Android-Projekte inklusive Build-Umgebung | Nicht angeboten: Nicht Teil des Produkts |
| App Store und Play Store veröffentlichen | Vollständig abgedeckt: Metadaten, Screenshots und Versionen über Fastlane aus der Plattform heraus | Nicht angeboten: Nicht Teil des Produkts |
| Remote-Entwicklungsumgebungen | Vollständig abgedeckt: Ubuntu-Workspaces mit VS Code, JetBrains, RDP und VNC. iOS-Builds auf macOS-Geräten der Pipeline | Nicht angeboten: Nicht Teil des Produkts |
| Standort der Verarbeitung | Vollständig abgedeckt: Betrieb in der EU, Auftragsverarbeitungsvertrag, Server frei wählbar | Teilweise abgedeckt: US-Anbieter, Regionen wählbar, Verarbeitung nach US-Recht |
Grün bedeutet vollständig abgedeckt, gelb teilweise, grau nicht vorgesehen. Railway ist im Container-Deployment sehr komfortabel – der Unterschied liegt in Serverzugriff, Planbarkeit und Reichweite über das Web hinaus.
Stand: 9. September 2026. Grundlage sind die öffentlich dokumentierten Funktionsumfänge der genannten Anbieter. Angaben können sich ändern; maßgeblich ist die jeweils aktuelle Darstellung des Anbieters. Logos sind Marken der jeweiligen Rechteinhaber und dienen nur der Zuordnung.
Railway-Stärken
- Start in Minuten Railway erkennt den Stack und startet. Wer nur einen Dienst live braucht, ist dort schneller am Ziel.
Kostenmodell
Railway rechnet nach Verbrauch. Die jeweils gültigen Zahlen stehen auf der Railway-Preisseite.
configurations/prod/versions.yaml
application:
backend_configuration:
image_tag: 0.26.8-98
frontend_configurations:
customer-frontend:
image_tag: 0.15.6-80
admin-app:
image_tag: 0.12.1-42-
Kunden-App — -
Admin-App — -
Backend —
Von Railway zur Application Platform wechseln
Weil beide Seiten mit Containern arbeiten, bleibt der Anwendungscode in der Regel unverändert.
-
Server verbinden
Binde einen eigenen Server per SSH an oder buche einen Managed Server. Docker, Datenbanken, Reverse-Proxy, SSL, Firewall und Backups werden eingerichtet.
-
Projekt anlegen
Lege dein Projekt im Assistenten an und wähle den Stack. GitLab-Repository, Projektstruktur und CI/CD-Pipeline entstehen mit.
-
Variablen und Dienste übertragen
Umgebungsvariablen wandern in die Credentials-Verwaltung des Projekts, verknüpfte Dienste laufen als Container auf deinem Server.
-
Datenbank umziehen und umschalten
Spiele einen Dump in die eingerichtete Datenbank ein, prüfe alles auf einer Staging-Umgebung und stelle danach den DNS-Eintrag um.
Häufige Fragen
Ist die Application Platform ein direkter Railway-Ersatz?
Für Container-Deployments deckt sie einen ähnlichen Bereich ab, verfolgt aber einen anderen Ansatz: Server mit SSH-Zugang sowie mobile Apps, Store-Releases und Entwicklungsumgebungen. Wenn du eine verwaltete Runtime ohne Serverzugriff bevorzugst, bleibt Railway die bessere Wahl.
Muss ich meine Anwendung anpassen?
In der Regel nicht. Deployments laufen über Docker, sodass ein bestehendes Dockerfile übernommen werden kann. Ändern musst du plattformspezifische Komfortfunktionen wie automatisch verknüpfte Dienstvariablen, die du stattdessen in der Credentials-Verwaltung des Projekts pflegst.
Wie unterscheidet sich die Abrechnung?
Railway rechnet nach Verbrauch ab, was mit wachsender Last schwieriger vorherzusagen ist. Bei der Application Platform zahlst du für die Plattform und deine Server, sodass die monatliche Größenordnung im Voraus bekannt ist.
Was ist mit Datenbanken und Backups?
Beim Server-Setup richtet die Plattform Datenbanken, Reverse-Proxy, SSL, Firewall und Backups automatisch ein. Über Version und Wartungsfenster entscheidest du selbst. Den Cluster-Zugang kannst du unter Anbindungen hinterlegen; das Ausrollen auf den Cluster folgt. Monitoring im vollen Umfang steht noch aus.
Lohnt sich der Wechsel, wenn ich nur eine Web-App betreibe?
Nicht zwingend. Wenn dein Produkt aus einem Webdienst mit Datenbank besteht und der Verarbeitungsort keine Rolle spielt, gibt es wenig Grund für einen Wechsel. Interessant wird der Vergleich, sobald mobile Apps, Store-Releases, eigene Server oder der Betrieb in der EU dazukommen.
Rechnung anschauen, dann entscheiden
Wenn Railway noch billig ist, bleib. Wenn Worker und Staging dieselbe Uhr teilen, lohnt ein fester Server.