Coming from Hatchbox.io

Why teams look past Hatchbox

Hatchbox got the important thing right: deploy to servers you own, no compute markup. If that is working for you, there is no urgent reason to move.

Where people start looking: Hatchbox is a thin layer over a fairly manual setup — you are close to the Nginx config and the server internals — and the managed surface stops early. There is no verify-then-swap release with a health-checked cutover, no preview environment per pull request, no roles / 2FA / audit trail, and backups are yours to arrange. It is also a single-maintainer product with a quiet roadmap.

Railyard is the same “your servers” bet with more of day two handled for you.

What comes with you

• Your repo and your Dockerfile — or Railyard’s Nixpacks / buildpacks path if you deploy without one today.
• Your Procfile process types.
• Your environment variables.
• Your database. Hatchbox’s managed Postgres / MySQL / Redis map to Railyard addons with injected connection strings.
• Your servers, if you want to keep them — attach an existing machine over SSH instead of provisioning a new one.

The move

1. Attach a server. Point Railyard at one of your current Hatchbox servers, or a fresh one in your cloud account.
2. Add your repo and confirm the build method. A Dockerfile deploys as-is.
3. Bring your env and attach the datastores you need.
4. Deploy to a temporary URL and check it end to end — including a release task if you run migrations.
5. Move your data with a standard dump and restore into the managed addon.
6. Repoint DNS. The old app serves until the record flips; nothing goes dark. Then wind down the Hatchbox app.

What’s genuinely different

You get a health-checked, zero-downtime cutover on every deploy, one-click rollback with the commit and author recorded, a preview deploy for every PR, real roles and an audit log, and backups that are tested to restore — on top of the ownership you already had.