Migrate

Migrate from Railway

Moving from Railway to Stackap means splitting a multi-service project into one Stackap project per web app, and removing any dependence on private networking between services.

Who this is for

No team has migrated from Railway to Stackap yet. This guide maps concepts and lays out the steps, and it is not a record of a tested run.

A Railway project can hold several services that reach each other privately. A Stackap project is one app with its own database, so the work is deciding which of your services are web apps, which are data, and which need rethinking.

Take inventory first

Every service in the Railway project, and which of them speak HTTP.
The variables on each service, including those that reference another service.
Any volume attached to a service.
Databases other than Postgres, and who connects to them.
Cron schedules and what each one calls.

What does not move automatically

Private networking: Apps cannot reach each other over a private network. They talk over their public addresses, or you combine them into one app.
Databases other than Postgres: Only Postgres is provided, so Redis or similar needs another home.
Volumes: Containers have no persistent volume. Use the database or object storage.
The database copy: There is no self-serve database import yet. The operator loads your dump into the project's database with you, and the row counts are compared table by table afterwards.

How to know it worked

Row counts match table by table.
Services that called each other privately now reach each other over public addresses and still work.
Scheduled calls run once.
No data was left on a Railway volume.

Going back

Keep the Railway project until the move is proven. Going back is one DNS record.

Steps

Dump Postgres. Use the database's connection string with pg_dump for a full dump.
Create a project per web app. Each Railway web service becomes a Stackap project, deployed from its repository.
Flatten the variables. Where one service's variable referenced another, write the real value or public address into stackap env set.
Replace what does not move. Find a home for non-Postgres data and volumes first.
Load the database. The operator restores the dump into the project database with you.
Deploy and compare. Push, read the build log, and compare pages with Railway.
Switch. Point your DNS record at Stackap and stop the Railway services.

Early-access scope

The database load is operator-assisted.
No private networking, volumes or databases other than Postgres.
A multi-service system becomes several projects, with more public calls between them.
No migration from Railway has been run yet.

Questions

What about a service that does not speak HTTP?

A queue worker or similar has no place in a Stackap project today. Keep it where it runs, or reshape it as a small web app with a health route.

Will latency change?

Stackap runs on a server in Germany today. If your Railway region was elsewhere, expect a different latency to your users and to any database you leave behind.

Can I keep the database on Railway?

Yes. The app can connect to it across the internet, with added latency to every query.

Do I need a Dockerfile?

Not for Next.js, static sites or Node apps with a start script.

Stackap is in early access. Tell us what you run and we will reply with a straight answer about whether it fits.

Ask for an invitation

Last updated 2026-10-03.