Migrate from Fly.io Postgres to Layerbase
Fly Managed Postgres starts at $38 a month and bills storage by the provisioned gigabyte. A Layerbase Postgres is $0 on the Free tier and $5 a month on Solo. Push the data out of your Fly private network with one command, or point the wizard at a proxy: either way the copy is read-once and your cluster is never modified.
Still comparing? Fly.io alternatives
Why switch
Why teams leave Fly.io
A $38 floor becomes $0 or $5
The cheapest Fly Managed Postgres plan is $38 a month for a shared-2x with 1 GB of RAM. Layerbase Postgres is $0 on the Free tier, $5 a month on Solo, and $15 on Pro, and that price is the whole database bill.
No per-gigabyte storage anxiety
Fly charges $0.28 per provisioned GB per month on top of the plan, so you size your volume against a bill instead of against your data. Layerbase plans include their storage, so growing a table is not a pricing decision.
Reachable from anywhere, not just your private network
A Fly MPG cluster is only reachable inside your Fly organization, so a CI job, a Vercel function, a laptop, or a Postgres GUI needs a WireGuard tunnel or a proxy app you deploy and maintain. A Layerbase Postgres is a TLS connection string that works from any of them, with IP restrictions and mTLS available when you want the door narrower.
A database with a dashboard
Daily backups, point-in-time recovery on Pro, copy-on-write branching, a web SQL console, and a real Postgres you can point psql at. Every other engine we host, Redis and Valkey through search and analytics, sits in the same account when one database is not enough.
How it works
Four steps, one pass
- 1
Create a free account or sign in
Sign in with Google or GitHub. No credit card is needed to start, and the migration wizard opens with this platform already selected.
- 2
Paste your connection string
Fly Managed Postgres runs inside your Fly private network, so there is no string you can paste that we can dial: the usual path is to push the data out from inside Fly with one pg_dump command. If you already run the Fly MPG proxy, take the direct connection string from fly mpg status, swap in the proxy hostname, and add ?sslmode=disable on the end: postgresql://fly-user:password@mpg-proxy-something.fly.dev:5432/fly-db?sslmode=disable. Both paths, with the traps that break them, are written out on /migrate/fly.
- 3
Pick what to migrate and name it
Choose what to bring over, give the new Layerbase database a name, and start the migration. Progress streams live in the dashboard.
- 4
We copy it in one pass
The migration reads from Fly.io once and never writes to it. Credentials are used for the copy and never stored. When it finishes, you land in your new database with a live TLS connection string.
Step by step
Two ways out of the Fly private network
A Fly Managed Postgres cluster only answers inside your Fly organization private network, so either push the data out from inside Fly (steps 1 and 2), or give the cluster a public front door and use the wizard (steps 3 to 6). The proxy path is the one with traps, and all three below were hit live on 2026-09-01.
- 1
Path A. Create the Layerbase Postgres first and copy its connection string, then open a shell on a machine that is already on your Fly network.
fly ssh console -a <your-app> - 2
Pipe the dump straight across from inside that shell. The Layerbase side is publicly reachable, so the data flows out of the private network in one command with nothing else to deploy. Use the direct. hostname rather than the pgbouncer. one: pg_dump cannot run through a transaction-mode pool.
pg_dump "$DATABASE_URL" --no-owner --no-privileges \ | psql "<layerbase-connection-string>" - 3
Path B. If you would rather use the guided wizard, deploy Fly own MPG proxy app so the cluster has a public front door.
fly launch --from=https://github.com/fly-apps/fly-mpg-proxy \ --secret CLUSTER_ID=<your-cluster-id> - 4
Restore the repository fly.toml before you deploy. fly launch --from regenerates fly.toml with HTTP defaults, which silently breaks the proxy: the app deploys and looks healthy, and nothing ever answers on the Postgres port. Put the repository [[services]] stanza back, then redeploy.
fly deploy - 5
Allocate a dedicated IPv4, then RELEASE the shared one. Allocating does not remove the shared address the app already had, so DNS keeps both records and connections fail intermittently depending on which one resolves. List the addresses, then release the shared entry by hand.
fly ips list fly ips allocate-v4 fly ips release <shared-ip> - 6
Paste the proxied string with ?sslmode=disable on the end. Take the direct. string from fly mpg status, swap in the proxy hostname, keep port 5432, and add the parameter: the direct endpoint speaks no TLS through the proxy, so libpq default handshake dies without it. Lock ip-whitelist.txt down or delete the proxy app once the copy finishes, because it ships allowing every address.
postgresql://fly-user:password@mpg-proxy-something.fly.dev:5432/fly-db?sslmode=disable
FAQ
Common Fly.io migration questions
Can I just paste my Fly connection string?
Not directly, and we would rather say so up front. Fly documents that an MPG cluster runs inside your organization private network and is not accessible over the public internet, and the copy runs from our servers. fly proxy and fly mpg connect forward a port to your own machine, which we cannot reach. Use one of the two paths below instead.
What is the simplest way to move the data?
Push it out from inside Fly. Create the Layerbase Postgres first and copy its connection string, then run fly ssh console -a <your-app> and pipe the dump straight across: pg_dump "$DATABASE_URL" --no-owner --no-privileges | psql "<layerbase-connection-string>". The Layerbase side is publicly reachable, so the data flows out of the private network in one command with no extra infrastructure. Use the direct. connection string rather than the pgbouncer. one, because pg_dump cannot run through a transaction-mode pool.
Can I use the guided wizard instead?
Yes, if you give the cluster a public front door first, and there are three traps in doing so. Fly publishes an MPG proxy app: fly launch --from=https://github.com/fly-apps/fly-mpg-proxy --secret CLUSTER_ID=<your-cluster-id>. That command regenerates fly.toml with HTTP defaults, which silently breaks the proxy, so restore the repository [[services]] stanza before you deploy. After fly ips allocate-v4, release the shared IPv4 the app already had, or DNS keeps both records and connections fail intermittently. Then take your direct.<cluster>.flympg.net string, swap in the proxy hostname, keep port 5432, and add ?sslmode=disable, because the direct endpoint speaks no TLS through the proxy. The proxy ships allowing every address, so restrict ip-whitelist.txt or delete the app once the copy finishes. The step-by-step version is on this page.
What about my Redis on Fly?
Redis on Fly is Upstash, and that is already covered: an Upstash database hands out a normal rediss:// endpoint reachable from anywhere. Create a Layerbase Redis or Valkey, open its Migrate tab, pick Upstash, and paste the TLS endpoint. Every key, type, and TTL comes across.
Will my Fly cluster be modified?
No. Both paths read only: pg_dump reads and writes to the Layerbase side, and the proxied wizard path connects, copies the schema and data, and disconnects. Your Fly cluster keeps serving traffic throughout, and there is no ongoing sync afterwards, so plan a cutover.
Does my app have to leave Fly?
No. This migrates the database. Your app keeps running on Fly: set DATABASE_URL to your Layerbase connection string with fly secrets set and redeploy. Fly apps reach the public internet normally, so nothing else changes.
Ready to leave Fly.io?
Sign in, and the migration wizard opens with Fly.io already selected. Your source is read once and never modified, so there is nothing to undo if you change your mind.