Coming from Render

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.yaml intent — web and worker services become Railyard process types; a preDeployCommand becomes 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

1. Point Railyard at a server in your DigitalOcean / Hetzner / AWS account, or attach one you already run.
2. Add your repo and pick the build method Render uses today — usually the Dockerfile.
3. Recreate your config. Paste env vars; attach Postgres and Redis so the URLs are wired in.
4. Deploy to the temporary URL and exercise the app, background jobs included.
5. Move your data. Take a pg_dump from Render and restore it into the managed addon.
6. Repoint DNS. Render keeps serving until the record flips — no downtime. Then suspend the Render services.

What’s genuinely 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.