# Migrate from Fly.io Postgres to Layerbase

> Move a Fly Managed Postgres database to Layerbase. One pg_dump from inside Fly, or a proxied connection string. Flat $5 and $15 plans instead of a $38 floor.

Canonical: https://layerbase.com/migrate/fly
Generated from Layerbase source: 2026-11-13

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.

## Key facts

| Fact | Value |
| --- | --- |
| Source platform | Fly.io |
| Layerbase target engines | PostgreSQL |
| How you connect | Paste a connection string |
| Source modified | No: read-once copy, credentials never stored |

## Why switch from 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

Backups every 12 hours on paid plans, point-in-time recovery on Pro, branching (copy-on-write once turned on per database), 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 the migration works

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.

## 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.

```sh
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.

```sh
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.

```sh
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.

```sh
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.

```sh
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.

```sh
postgresql://fly-user:password@mpg-proxy-something.fly.dev:5432/fly-db?sslmode=disable
```

## 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.

### Which PostgreSQL version will my database run?

New Layerbase PostgreSQL databases run PostgreSQL 18, with the next major available as an opt-in beta. Older major versions cannot be chosen for new databases, but you do not need to upgrade before moving: the import is a dump and restore, which carries your schema and data forward from an older major version. Test your app against PostgreSQL 18 before you switch traffic, and check the import report, which names anything that did not come across.

## Links

- [Migrate from Fly.io](https://layerbase.com/migrate/fly)
- [PostgreSQL on Layerbase](https://layerbase.com/db/postgresql) (markdown: https://layerbase.com/db/postgresql.md)
- [Cloud migration guide](https://layerbase.com/docs/cloud/migrate)
- [Pricing](https://layerbase.com/pricing) (markdown: https://layerbase.com/pricing.md)
