Coming from Render
Render has a great developer experience, on Render's metal, at Render's prices. Move the same app to a server you own.
The fast way: paste a Render API token into the importer and Railyard brings over processes, environment variables, databases with their data, and domains. The steps below are what it does for you, and how to do it by hand.
Why teams leave Render
Render nailed the developer experience. The catch is the same one every managed platform has: it runs on infrastructure you do not control. Instance and bandwidth costs climb as you succeed, the region list is theirs, your data sits where they put it, and leaving is a real migration rather than a DNS change.
Railyard keeps the push-to-deploy experience and moves it onto a Linux server in your own cloud account: same workflow, your metal, your bill.
What comes with you
- Your repo. Railyard builds from a Dockerfile (the same one Render uses) or from buildpacks.
- Your
render.yamlintent: web and worker services become Railyard process types; apreDeployCommandbecomes a release task. - Your environment variables and environment groups.
- Render Postgres and Render Key Value / Redis map to managed Postgres and Redis addons with injected URLs.
- Custom domains with automatic TLS.
The move
- Point Railyard at a server in your DigitalOcean / Hetzner / AWS account, or attach one you already run.
- Add your repo and pick the build method Render uses today, usually the Dockerfile.
- Recreate your config. Paste env vars; attach Postgres and Redis so the URLs are wired in.
- Deploy to the temporary URL and exercise the app, background jobs included.
- Move your data. Take a
pg_dumpfrom Render and restore it into the managed addon. - Repoint DNS. Render keeps serving until the record flips, with no downtime. Then suspend the Render services.
What’s different
The machine is yours. No per-GB egress surprises, no waiting on a region to be added, and if you ever leave Railyard the containers keep running on the box you already own.