Coming from Cloud 66
Cloud 66 pioneered the BYO-server control plane. Railyard is the lighter, cheaper take on the same model — here's how to move.
Why teams leave Cloud 66
Cloud 66 proved the model years ago: a control plane over servers you own, on any cloud. The friction now is weight and price. The interface carries a decade of features most small teams never touch, the pricing starts well above a solo or small-team budget, and it is a closed product — you configure it, you do not run it.
Railyard is a deliberately small take on the same idea: connect a server, push your code, get the day-two essentials, at a price that does not scale with your headcount.
What comes with you
- Your repo, built from a Dockerfile, buildpacks, or a Procfile.
- Your environment variables and secrets.
- ActiveDeploy-style zero-downtime releases carry over as Railyard’s verify-then-swap cutover.
- Managed Postgres / MySQL / Redis map directly to Railyard addons.
- Your existing servers — attach them over SSH rather than rebuilding the fleet.
The move
- Attach a server — an existing Cloud 66 server, or a new one Railyard provisions in your cloud account.
- Add your repo and select the build method that matches how Cloud 66 builds it today.
- Bring your config and attach the datastores your app expects.
- Deploy to a temporary URL. Run your release task and verify.
- Migrate data with a dump and restore into the managed addon.
- Move DNS. The Cloud 66 stack serves until the cutover; there is no outage. Then decommission it.
What’s genuinely different
Less surface, less cost, and a workflow you can hold in your head: one dashboard, one clear action per screen, and nothing you are paying for that you are not using.