I'm choosing where to deploy an MVP with an API, Redis, and SQL Server in three containers. Railway looks convenient, but would a managed VPS be a better choice for keeping costs down?
Railway or a managed VPS for a three-container API?
Asked by
5c!mugspindle_804
Answers
Railway is a reasonable pick if getting the MVP deployed quickly matters more than tuning the infrastructure. It's convenient for container deployments and saves you some setup work.
Check how the expected resource usage affects the bill, though. A low starting cost doesn't necessarily tell you what it will cost once the app gets traffic.
Reply to this answer
A VPS is worth comparing if you want a more predictable monthly bill. DigitalOcean and OVH are options to look at, and Hetzner with a deployment tool such as Coolify or Dokploy is another route.
Compare what the managed part actually covers, not just the server price. You'll still need a plan for running and maintaining the containers, storage, and backups.
Reply to this answer
I'd make SQL Server the deciding factor before picking either option. It needs enough predictable RAM and persistent storage, plus a backup and restore process you can test. Check the storage and backup arrangements and where the database will run before relying on a setup.
Keeping the API and database in separate containers is sensible without making the MVP more complicated than it needs to be. Just remember that a separate container isn't itself a backup.
Reply to this answer
Ease of deployment isn't the whole story. There are concerns about Railway outages as well as positive opinions about its convenience, so check whether its reliability is acceptable for your MVP. A cheaper or simpler setup won't help much if downtime is a problem for your users.
Reply to this answer
Add your answer
Answers are reviewed before publication.
5c!mugspindle_804:
What should I look at if usage starts growing?
w.471!ferrybracket:
Estimate the resource use of all three containers, especially SQL Server, and check how Railway charges as that usage grows. Revisit the estimate once you have actual usage data.