How to migrate from Fly.io to your own VPS

Your app is running on Fly.io, but now you want more control, clearer costs, or a setup you can understand without reading platform-specific docs every time something breaks.

Short version: to migrate from Fly.io to your own server, you need to recreate the same moving parts Fly.io handled for you: app runtime, database access, environment variables, domains, HTTPS, logs, backups, and deploys. The safest path is to build the new server beside the old Fly.io app, test it on a temporary address, then switch DNS only when you know the new setup serves real traffic correctly.

What changes when you leave Fly.io?

Fly.io is not just a place where your app runs. It also hides a lot of plumbing.

Think of it like moving out of a serviced apartment. On Fly.io, the lights, front desk, mailroom, and building security are already part of the deal. On your own server, you get the keys to the whole place, but you also decide where the fuse box is and who has a spare key.

The main change is responsibility. Your app may still be the same code, but the surrounding jobs move to you: starting the app after reboot, routing the domain, issuing HTTPS certificates, watching disk space, and keeping backups you can actually restore.

Here is the practical difference:

This is why a Fly.io migration is not only “copy the files.” It is more like copying the shop, the sign on the street, the cash register, and the keys to the back room.

What should you move first?

Start with an inventory. Before touching DNS, write down what the Fly.io app depends on.

That usually means the app code, the runtime version, environment variables, secrets, database connection strings, storage buckets, background workers, scheduled jobs, custom domains, and anything in fly.toml. If you use Docker — a way to package an app with the software it needs — note whether the existing image can run outside Fly.io or whether it assumes Fly-specific behavior. If Docker is still fuzzy, this plain-English guide helps: Docker on a server for beginners.

Then pick the right size server. Do not guess from pride; guess from evidence. Look at memory use, CPU spikes, database size, and traffic patterns. A tiny app with one background worker is different from an image-heavy service with a busy database. For sizing in plain language, see what size server do you need.

Move in this order:

1. Prepare the server and basic security.
2. Recreate the app runtime.
3. Add environment variables and secrets.
4. Connect or migrate the database.
5. Test the app on a temporary address.
6. Set up HTTPS.
7. Switch the domain.
8. Keep Fly.io running until you are confident.

That order matters because it keeps the old home open while the new one is being checked.

How do you avoid downtime during the migration?

Downtime usually happens when the domain is moved before the new server is ready.

A domain is like a street sign. DNS is the public address book that tells browsers where the sign points. If you change it too early, visitors arrive at an unfinished building.

Before switching DNS, test the new app directly. Confirm the homepage loads, login works, forms submit, background jobs run, emails send, file uploads behave, and the database contains what you expect. Also check the boring pages: password reset, billing webhooks, admin screens, health checks. Those are often where platform assumptions hide.

HTTPS needs its own check. HTTPS is the lock icon in the browser, backed by a certificate that proves the site is yours. A wrong or expired certificate can make a working app look broken to users. If you want the plain version of that step, read how to get free HTTPS on your own server.

For databases, be careful with writes. If users can change data during the migration, you need a plan for the final sync. For small apps, that might mean a short maintenance window. For busier apps, it may mean replication or an export/import process with a clear cutover time.

And keep Fly.io live for a little while after the switch. DNS changes spread gradually. Some visitors may still reach the old app while others reach the new one.

FAQ

Can I reuse my Fly.io Docker image? Often, yes, if the image does not depend on Fly.io-only behavior. Still test it on the new server before switching traffic.

Do I have to move the database too? Not always. You can move the app first and keep the database where it is, but latency and access rules may make that awkward.

Will my IP address change? Yes. Your domain will need to point to the new server’s address when you are ready.

What is the biggest migration risk? Data loss. Back up the database and files before the final move, and make sure you know how to restore them.

The shortcut

Server Manager helps by turning the migration into a visible setup instead of a pile of remembered steps. The outcome is that your domains, HTTPS, apps, and server layout stay easier to read after the move, not just on the day you set them up.

That matters for the exact problems Fly.io used to hide: a wrong certificate, a domain pointing at the wrong place, one project interfering with another, or nobody remembering how the app starts six months later. The real benefit is not skipping responsibility; it is making the responsibility legible enough that future-you can handle it calmly.

For a Fly.io migration, that means you can focus on proving the app works, protecting the data, and switching traffic at the right time instead of turning every surrounding task into a separate mystery.

What does a good migration feel like?

A good migration from Fly.io to your own server feels boring in the best way.

The old app keeps running while the new one is prepared. The new server is tested before the domain moves. HTTPS works, the database is backed up, and you know where the important pieces live.

That is the win: not just leaving Fly.io, but landing somewhere you understand well enough to maintain.