Railway hosting for apps with background workers and a database
Some apps are more than a website: a web server, a background worker, a database and a cache that all need to reach each other. Railway runs those pieces together in one project.
Reviewed by: Rahul Jaiswar, founder
The platform
Railway is a hosting platform that deploys services, workers and databases from a code repository or a Docker image. It groups them into projects with separate environments, a private network between services and usage-based billing.
Railway or Vercel?
The short answer: Vercel is built around websites and front ends, with server code in short functions. Railway is built around processes that keep running. If your app has background workers, bots or websocket servers, such as a job that pulls orders from a warehouse system every few minutes, those need a process that stays up, which points to Railway or a server of your own. Plenty of projects use both: the site on one, the workers on the other.
Where we use it
Microsive ATS, the recruitment software we built and run, is hosted on Railway.
What we check
A deploy sends what is on the machine, not what is committed, so we commit first and check the running version afterwards.
We also deploy and host client apps on Railway, and the account stays in your name. The region the app runs in is chosen with you; a US region is an option. Other projects run on a managed virtual private server instead, and which one suits yours is decided at the start.
Other reasons to look elsewhere
High, steady load can make a fixed-size server you manage cheaper, in exchange for doing the upkeep yourself. If a customer contract or an industry rule says where data must be stored, check it against the regions on offer before choosing.
Questions to ask a team hosting on Railway
- Whose account holds the project, and can you get admin access?
- Which region runs the app, and how far is it from your users?
- How is a release tested in staging and promoted to production?
- What sends an alert when a service crashes or usage jumps?
Railway pitfalls
- Sleeping services. Railway can put inactive services to sleep to save usage. Leave that setting off for workers and bots that must stay connected.
- A database treated as someone else’s problem. A platform database still needs a restore plan that has been tried; the PostgreSQL page covers it.
- Usage that grows quietly. Set usage alerts when the project starts, before the first surprising bill.
An app with workers and a database?
Tell us what it does and roughly how many people will use it. Software and web apps covers the build, and we deploy it to a Railway account you own.