← All migration guides
Coming from Supabase
Supabase bundles Postgres, auth, storage and edge functions on its own infrastructure. Railyard runs your actual application code on a server you own, with a managed Postgres addon alongside it.
Why teams leave Supabase
Supabase is a strong Postgres-plus-auth-plus-storage backend-as-a-service. The friction shows up when your app has its own server-side logic beyond edge functions: a worker, a scheduled job, or a framework like Rails, Django or Laravel that expects to run as a long-lived process.
Railyard deploys that application code to a server you own, with managed Postgres as an addon rather than the whole platform.
What comes with you
- Your repo, built from a Dockerfile, buildpacks, or a Procfile.
- Your environment variables and secrets.
- Your Postgres schema and data, dumped from Supabase and restored into Railyard’s managed Postgres addon.
- Auth and storage logic you’ll re-implement in your own app or with a library, since Railyard doesn’t bundle them as a managed service.
The move
- Attach a server: an existing one, or a new one Railyard provisions in your cloud account.
- Add your repo and attach a managed Postgres addon.
- Migrate your data with a dump and restore from Supabase’s Postgres.
- Deploy to a temporary URL. Run your release task and verify.
- Move DNS. Your Supabase project keeps serving until the cutover; there is no outage.
What’s different
A real server for your application code, with the database as a Railyard addon in your own cloud account instead of a shared, usage-billed platform.