GUIDES / FLY.IO → B2

How to back up Fly.io Postgres to Backblaze B2

RESTORE-TESTED · ENCRYPTED · IN A BUCKET YOU OWN

Fly.io keeps your database running, but its snapshots live in the same account and region as the database itself. An off-site copy in your own Backblaze B2 bucket protects you from the failures the platform can't: a bad migration, a locked account, or a compliance question you need a real answer to. Here's how to set it up in a few minutes — and, crucially, how to know the backup actually restores.

Step 1 — Get your Fly.io connection string

Fly Postgres connection string (fly postgres connect details), or the credentials you set when you created the cluster.

Fly Postgres is unmanaged Postgres running as a Fly app. Make sure the database is reachable over the public internet — either allocate a public IP for the Postgres app or expose it — since backups connect from outside your Fly private network.

A read-only role is all you need. The exact CREATE ROLE SQL is on the security page.

Step 2 — Create a Backblaze B2 bucket and access keys

  1. In Backblaze, create a B2 bucket (set it private).
  2. Create an Application Key limited to that bucket.
  3. Copy the keyID, applicationKey, and the S3-compatible endpoint shown for your bucket.

Create an Application Key scoped to the bucket. B2's S3-compatible API uses the keyID as the access key ID and the applicationKey as the secret. B2 is one of the cheapest durable stores available.

Endpoint: https://s3.<region>.backblazeb2.com
Region:   your bucket's region, e.g. us-west-004
Bucket:   your-backup-bucket

Step 3 — Connect it to OffsiteDB

Paste the Fly.io connection string, add Backblaze B2 as your destination with the bucket and keys from Step 2, and choose a schedule (hourly to daily). OffsiteDB tests the connection, then runs pg_dump, gzips and seals the artifact with AES-256-GCM, and ships it to your bucket. It's plain Postgres; a read-only role on your schemas captures everything.

Step 4 — Know it restores (the part everyone skips)

Every snapshot is restore-drilled: OffsiteDB restores it into a throwaway Postgres cluster and counts the rows before marking it sealed. When you need it back, every artifact is a standard custom-format dump:

gunzip -c fly-db_2026-06-09.dump.gz \
  | pg_restore -d "$NEW_DATABASE_URL" --clean --if-exists

You also get a monthly Restore Drill Report with tested restore times — the document you forward when someone asks “are your backups tested?”

Back up Fly.io nowHow the encryption works

Before your next migration

Scheduled snapshots cover the slow disasters; deploys are the fast ones. One step in CI seals a tagged, restore-drilled checkpoint seconds before each migration runs — so a bad ALTER TABLE costs you a revert, not a day of data. Here's how that Friday goes with and without one.

FAQ

Does this work with Fly.io's free tier?
Yes. OffsiteDB connects with any standard Fly.io connection string regardless of tier. Fly.io Postgres runs Postgres 16, which is fully supported.
What permissions does the backup need on Fly.io?
A read-only role is enough — OffsiteDB only ever runs pg_dump and never needs write access. It's plain Postgres; a read-only role on your schemas captures everything.
Where exactly does my data end up?
In your own Backblaze B2 bucket, encrypted with AES-256-GCM before it leaves the backup worker. OffsiteDB never holds the only copy — if you ever leave, your backups are standard pg_dump archives you can restore without us.
Can I just run pg_dump in a cron job instead?
You can — but a cron job doesn't prove the dump restores, alert you when it silently stops, or hand you a tested-restore report for a security review. OffsiteDB restore-drills every snapshot into a real Postgres cluster, which is the part that matters when you actually need it.

Related guides

Keep reading