Coming from Fly.io
Move a Fly app to a server you own. Use the image Fly already runs, bring over your env and secrets, copy Postgres and volumes, then switch DNS.
Why teams leave Fly
Fly makes it easy to run containers close to users. But usage-based billing is hard to forecast, the platform decides which regions and machine sizes you get, and “Fly Postgres” is a Postgres you manage on Fly machines.
Railyard gives you the same container-first workflow on a Linux server in your own cloud account (such as DigitalOcean, Hetzner, Vultr or AWS), or on any Ubuntu box you can SSH into. Your provider bills you directly, at their price, and Railyard manages Postgres, Redis and backups for you.
The fast way: the importer (beta)
Applications → New app → Import from Heroku / Render / Fly. Choose Fly.io, paste a token from fly tokens create org and enter your Fly organization (it defaults to personal). Pick an app, review what will be copied, then import and deploy. Railyard keeps your token only for this import and forgets it after 30 minutes.
What the importer brings from Fly’s Machines API:
- The exact image Fly is running, pulled with your token as the registry password, so nothing is rebuilt.
- Environment variables from the machine config, and the internal port.
- Secret names. Fly never reveals secret values, so the review page lists them for you to enter again.
What it only flags for you:
- Other process groups (a
worker, say) aren’t copied. Add them as workers. - Volumes start empty. Copy their files over yourself (see below).
- Postgres data is not copied by the Fly importer. Move it with a dump (see below).
- Domains are listed, not attached. Add them once the new app is live.
Beta: the importer is tested against Fly’s documented API responses, and on prod it reaches Fly’s API. It hasn’t yet been run end to end against a real Fly account. If something doesn’t come across, use the manual steps below and tell us.
The manual way
- Add a server. Railyard can create one in your cloud account, or you can connect one you already have. See Add a server.
- Create the app. If your repo has a
Dockerfile, as most Fly apps do, point Railyard at the repo and it builds from it. Or deploy the image you already push to a registry. See Deploy a Docker image. - Set the port. Use the
internal_portfrom yourfly.toml[http_service]or[[services]]section. - Bring your config. Copy the
[env]block fromfly.tomlinto Variables.fly secrets listshows the secret names; paste the values from wherever you keep them. - Add a database. Attach Postgres (and Redis if you use it). Railyard creates the database and sets
DATABASE_URL/REDIS_URL. - Deploy and check the app on its temporary
sslip.ioaddress. - Move the data. Open a tunnel with
fly proxy 15432:5432 -a <your-postgres-app>, runpg_dump -Fcagainstlocalhost:15432, then upload the dump with Resources → Import data on the Railyard app. The upload shows progress, and you can cancel it. For files on a Fly volume, usefly ssh sftp get(ortaroverfly ssh console) and restore them into the app’s volume or bucket. - Cut DNS over. Add your domain in Railyard, then point the record at your server. Fly keeps serving until the record changes, so nothing goes down. Then scale the Fly app to zero and delete it.
How Fly concepts map
| Fly | Railyard |
|---|---|
| Machines in several regions | One or more servers you own. An app’s web process can run on several servers behind the primary |
Process groups ([processes]) | Process types: web plus workers, from a Procfile or set by hand |
release_command | Release command, run once before the new version takes traffic |
| Health checks | A health path. The new version must pass it before traffic moves |
| Volumes | Volumes on the server, with backups |
| Fly Postgres / Managed Postgres | Managed Postgres on your server or on a database server, with verified backups and point-in-time restore |
fly deploy | git push, railyard deploy, or a push to GitHub |
fly logs / fly ssh console | railyard logs --follow / railyard run and the Console tab |
| Auto-stop machines | App sleep: idle stagings sleep and wake on the next request |
What’s different
Railyard doesn’t run an anycast edge. Your app is served from your server’s region, and there’s no automatic multi-region routing yet. In return, the bill is a flat server price you can predict, the machines are yours, and if you stop using Railyard your app keeps running.