Keep Railway
- One service, small load, you do not want to see a server.
Railway detects the stack and starts. That is genuinely handy. It gets unhandy when three services plus a database run all day — then you pay consumption, not a box.

Railway feels like Heroku without the legacy. The surprise is the invoice when workers, database and staging share the same usage clock. Then you stop shopping for comfort and start shopping for a machine with a price.
This reflects the typical scope of both platforms. Details change over time, so check the current information from each provider when it matters.
| Criterion |
|
|
|---|---|---|
| Container deployments | Fully covered: Docker-based deployments through prepared pipelines | Fully covered: Core product, extremely quick to set up |
| Getting started and daily handling | Fully covered: A wizard for project setup, then work through Git and pipelines | Fully covered: Very direct interface, few steps to a first deployment |
| Databases in a few clicks | Fully covered: Databases are configured with backups during server setup | Fully covered: Managed databases in a few clicks, including scaling |
| Use your own servers | Fully covered: Your own server over SSH or a managed server from the platform | Not offered: Not supported, execution happens on Railway infrastructure |
| Server baseline with access | Fully covered: Docker, reverse proxy, SSL, firewall and backups on your own machine | Partly covered: Fully abstracted away, no access to the machine |
| Global edge network / CDN | Partly covered: Reverse proxy and SSL per server; no global edge network of its own | Partly covered: Several regions to choose from, delivery close to users |
| Cost model | Fully covered: Platform plus your own servers, which keeps the bill predictable | Partly covered: Usage-based, cheap at low load, harder to forecast as you grow |
| Building mobile apps | Fully covered: Flutter, Expo and native iOS and Android projects including build environments | Not offered: Not part of the product |
| Publishing to App Store and Play Store | Fully covered: Metadata, screenshots and versions through Fastlane from inside the platform | Not offered: Not part of the product |
| Remote development environments | Fully covered: Ubuntu workspaces with VS Code, JetBrains, RDP and VNC. iOS builds on the pipeline’s macOS machines | Not offered: Not part of the product |
| Where processing happens | Fully covered: Operated in the EU with a data processing agreement, servers freely selectable | Partly covered: US provider, regions selectable, processing under US law |
Green means fully covered, amber partly, grey not offered. Railway is very comfortable for container deployments – the difference lies in server access, predictability and reach beyond the web.
As of 9 September 2026. Based on the publicly documented feature scope of the providers named. Details can change; the provider’s current documentation takes precedence. Logos are trademarks of their owners and are used only to identify the product.
Railway bills usage. Current numbers are on the Railway pricing page.
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
Since both sides run containers, your application code usually stays as it is.
Attach your own server over SSH or book a managed one. Docker, databases, reverse proxy, SSL, firewall and backups get configured.
Set up your project in the wizard and pick the stack. The GitLab repository, project structure and CI/CD pipeline are created along with it.
Environment variables go into the project’s credential management, and linked services run as containers on your server.
Load a dump into the prepared database, verify everything on a staging environment, then point the DNS record over.
For container deployments it covers similar ground but takes a different path: servers with SSH access, plus mobile, store releases and dev environments. If you prefer a managed runtime without server access, Railway remains the better fit.
Usually not. Deployments run through Docker, so an existing Dockerfile carries over. What changes are platform-specific conveniences like auto-wired service variables, which you manage instead in the project credential store.
Railway bills by consumption, which gets harder to forecast as load grows. On the Application Platform you pay for the platform and your servers, so the monthly order of magnitude is known upfront.
Server setup configures databases, reverse proxy, SSL, firewall and backups automatically. You decide on version and maintenance windows yourself. You can store cluster access under Connections; deploying onto the cluster comes next. Full infrastructure monitoring is not available yet.
Not necessarily. If your product is a web service with a database and processing location does not matter, there is little reason to switch. It gets interesting once mobile apps, store releases, your own servers or EU operation enter the picture.
If Railway is still cheap, stay. If workers and staging share the same meter, a fixed server is the point.