How to migrate an application from Railway to a VPS without losing data
Published on 2026-10-26 by frfrand
Migrating from Railway to a VPS with backups, PostgreSQL, and DNS
Moving an API from Railway to a VPS seems simple until someone saves a reservation right while you're copying PostgreSQL. The key change is coordinating the data, not just copying code.
Let's get to the useful part: what would you use it for, how would you get it running, and what happens if it breaks? The first demo rarely reveals all of that.
What you need to know about Railway
Moving an API from Railway to a VPS seems simple until someone saves a reservation right while you're copying PostgreSQL. The key change is coordinating the data, not just copying code. This type of tool is best evaluated with a real project you already know: a booking API, a payment website, or an automation flow. Before installing, distinguish between infrastructure, panel, and services that your own team must maintain.
A real-world example
A tour platform could confirm a spot in the old database while the frontend already points to the new one. Without a cutover window or designed synchronization, you end up with reservations in two places.
How I would test it step by step
- Inventory the application, PostgreSQL, Redis, workers, cron, storage, and domains.
- Prepare in ArduMaker a VPS with runtime, Git, proxy, and database.
- Test a consistent PostgreSQL backup and restore it in a staging environment.
- Migrate volumes or user files and load secrets securely.
- Coordinate the write cutover and a final copy, test it, and only then change DNS.
The test does not end when the domain appears. Create a record, restart the service, and query it again. Check application and database logs. If there is a worker or a webhook, verify what happens when an external API stops responding.
The error to avoid
Do not close Railway before checking payments, emails, sessions, webhooks, and a real rollback procedure.
Also, do not leave credentials in repositories or open databases to facilitate connection from your computer. Prefer private networks, tunnels, and minimum permissions. For client applications, test a data restore: a backup that was never recovered is just a promise.
How would you do the same with ArduMaker?
ArduMaker can host APIs, PostgreSQL, workers, and domains on VPS with Git and operational tools, but it does not replace migration design and consistency.
A possible flow is to create a VPS, link GitHub, configure a service for the API, manage PostgreSQL, and publish HTTPS via domain. If you need background processes, separate a worker. If you work with multiple clients, organize resources and members by Company to avoid cross-access.
| Aspect | Railway | ArduMaker |
|---|---|---|
| Focus | Specialized tool or service | VPS with integrated management tools |
| Publishing | Based on repositories, panel, and runtime | Git, services, and domains from the VPS environment |
| Data | Must be backed up according to architecture | PostgreSQL or Redis with verifiable backups |
| Responsibility | Depends on the provider and configuration | The team maintains its app and controls its server |
The cost that doesn't appear on the first screen
Check the VPS fee, licenses, persistent disk, traffic, and backups. Add configuration and maintenance hours. If the provider offers a managed service, review exactly what it manages and what remains on your side. There are no perfect equivalences between hosting, a panel, and a VPS.
Which one is more convenient?
I wouldn't replace a tool that already works just to get another logo on the panel. I would consider a migration when it reduces repetitive operations, allows better permission organization, or solves a technical limitation you have already encountered. What matters is being able to repeat deploying, measuring, updating, and recovering.
Sources: Official documentation · Compare with ArduMaker · ArduMaker services.
In short: choose the tool you can actually maintain with your team and resources. An app that withstands updates and failures is worth more than a ten-second deploy.