What actually breaks moving off Render

Render didn’t do anything wrong. That’s what makes this migration different from a Heroku one: nobody’s leaving because the product is bad. They’re leaving because it’s Render’s infrastructure, Render’s regions, and Render’s bill, and all three get less comfortable the more an app actually grows.

What comes across cleanly

Railyard’s importer reads a Render account directly from an API token: repository and branch, environment variables, the start command, and custom domains all come over as-is. Background workers on Render become ordinary worker processes on Railyard — same job, different host.

If you’re moving by hand instead of using the importer, the same things map directly:

• Your Dockerfile, if you have one — the same one Render already builds from.
• A render.yaml’s intent: web and worker service definitions become Railyard process types, and a preDeployCommand becomes a release task that runs before the new version takes traffic.
• Environment variables and environment groups, pasted in as-is.
• Render Postgres and Render Key Value map to managed Postgres and Redis addons, with the connection URLs injected the same way Render injects them today.

What doesn’t come across automatically

Two things need a deliberate step, not a toggle:

• Secret file values. The importer brings over the names of anything Render stored as a secret file, not the contents — re-enter those by hand once.
• The actual data. A database migrates by streaming a pg_dump from Render’s DATABASE_URL straight into the new managed Postgres. Keep the old database running until the new one answers correctly, then move DNS — not before.

The move, in order

1. Point Railyard at a server in your own DigitalOcean, Hetzner or AWS account — or attach one you already run.
2. Add the repository and confirm the build method Render already uses (usually the Dockerfile).
3. Recreate the config: paste env vars, attach Postgres/Redis so the connection strings wire in automatically.
4. Deploy to the temporary URL and actually exercise the app, background jobs included, before touching DNS.
5. Stream the data over, verify it, then repoint DNS. Render keeps serving the whole time — there’s no window where the app is down.

What’s actually different afterward

The machine is yours. No per-GB egress surprise at the end of a good month, no waiting on a region Render hasn’t added yet, and if you ever decide to leave Railyard too, the containers keep running on a box you already own — nothing about the exit depends on us.

Full technical mapping: Migrating from Render, the Render comparison, and Import from Heroku, Render, Fly or Railway.