managed Postgres that can be private to my app network (no public endpoint) and easy to attach to my app

If you’re deploying an app on Fly.io and you want Postgres that feels “managed enough,” stays completely private on your app’s network, and is dead simple to attach, you’re very much in the right neighborhood. You don’t need to bolt on a random cloud database or punch a hole in your VPC. You can keep Postgres close to your app, behind Fly Proxy, and only reachable over the private Fly WireGuard network.

Quick Answer: On Fly.io, the closest thing to “managed Postgres that can be private and easy to attach” is Fly Postgres (unmanaged): a Postgres app that runs on Fly Machines, lives on your Fly private network, has no public endpoint by default, and can be wired into your app with fly postgres attach and a couple of environment variables.

---

Quick Answer: A Postgres cluster you deploy and operate on Fly Machines with fly postgres, fully private on Fly’s network and easy to connect to your Fly apps using flyctl and built‑in helpers.

The Quick Overview

• What It Is:
  A Fly.io–hosted Postgres cluster (built from the open source fly-apps/postgres-flex image) that runs as its own Fly app, lives on your private Fly network, and ships with sugar for provisioning, replication, failover, metrics, and snapshots. It’s “unmanaged” in the sense that you own upgrades and tuning, but Fly gives you the scaffolding and wiring.

• Who It Is For:
  Teams who want:

  • Postgres close to their Fly apps (same regions, low latency)
  • No public Postgres endpoint on the internet
  • Simple attach/connection flows instead of DIY networking
  • Enough control to treat the database like part of their stack, not a black box

• Core Problem Solved:
  Running a secure, private, production‑grade Postgres that “just plugs in” to your Fly apps—without building your own cluster scripts or exposing Postgres to the whole world.

---

How It Works

Think of Fly Postgres (unmanaged) as a special Fly app whose only job is to run Postgres. It uses the same primitives as your other apps—Fly Machines, private networking, regional placement—but flyctl wraps the boring parts so you can create and attach a cluster in a few commands.

At a high level:

1. You provision a Postgres app with fly postgres create.
2. It comes up on your Fly private network, by default without a public endpoint.
3. You attach it to one or more apps; flyctl wires in credentials and internal hostnames for you.

Communication between your app and the database stays on Fly’s encrypted private network. No public IP is required unless you explicitly ask for one.

1. Provision: Create a Private Postgres Cluster

You kick things off with:

fly postgres create

flyctl walks you through:

• App name (e.g., my-app-db)
• Primary region (e.g., iad, lhr, syd)
• Volume size / VM size
• Whether you want HA (multiple Machines) and replicas

Under the hood, this creates:

• A Fly app running the Postgres image (from fly-apps/postgres-flex)
• Machines with attached volumes for durable storage
• A private service listening on your Fly internal network

By default, this database does not expose a public Postgres port. It’s reachable only from apps on the same Fly organization network (and anyone you explicitly wire in via WireGuard).

2. Attach: Wire the Database to Your App

Once the cluster exists, you attach it to your app:

fly postgres attach my-app-db -a my-app

This:

• Creates a database user and database scoped to your app
• Sets environment variables on your app, usually something like:
  • DATABASE_URL
  • PGHOST, PGDATABASE, PGUSER, PGPASSWORD
• Points those credentials at the internal hostname (e.g., my-app-db.internal), not a public IP

Your app talks to Postgres over the Fly private network. No external connection string, no firewall gymnastics.

You deploy or redeploy your app as usual:

fly deploy

Your app boots up with valid, private Postgres credentials already in place.

3. Operate: Scale, Replicate, and Snapshot

After attach, you use fly postgres and normal Fly tooling to operate the cluster:

• Add replicas in other regions for read latency and HA:

  fly postgres create --name my-app-db-replica --region lhr --replica my-app-db
  

• Check status and replication health:

  fly postgres status -a my-app-db
  

• Use daily snapshots for disaster recovery or environment cloning.

• Monitor metrics and logs from the Fly dashboard or fly logs -a my-app-db.

Fly Postgres is unmanaged in the sense that you steer upgrades and configuration, but you’re not building replication, snapshots, or failover from scratch. The cluster is also fully open source, so if you need something custom you can fork fly-apps/postgres-flex.

---

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Private Networking by Default	Runs Postgres on Fly’s internal WireGuard‑secured network with no public listener unless you explicitly configure one.	Keeps your database off the public internet while staying easy to reach from your Fly apps.
App Attach Sugar (fly postgres attach)	Automatically creates users/databases and injects DATABASE_URL and related vars into your app.	Removes manual credential wiring and tedious connection string management.
Cluster Scaffolding (Replication, Failover, Snapshots)	Bootstraps a Postgres cluster with replication, failover, metrics, monitoring, and daily snapshots built in.	Gives you “managed‑like” operational features without building your own automation.

Additional nice things that matter at 3 a.m.:

• Region‑aligned compute: Run Postgres in the same regions as your apps for minimal latency.
• Open source image: fly-apps/postgres-flex is public; you can fork and adjust if you have custom Postgres needs.
• Per‑app isolation: It’s trivial to spin up separate clusters for staging, review apps, or noisy tenants.

---

Ideal Use Cases

• Best for production apps that need private Postgres:
  Because it runs entirely on Fly’s private network and is created as a dedicated Fly app, you keep blast radius small and avoid exposing Postgres publicly.

• Best for teams who want “managed‑ish” without giving up control:
  Because you get replication, failover, metrics, and snapshots out of the box, but still control Postgres versions, extensions, and tuning like any other VM‑based database.

---

Limitations & Considerations

• Not a fully managed service:
  Fly Postgres is unmanaged. You (or your ops folks) are responsible for:

  • Upgrades and version jumps
  • Extension choices
  • Query tuning and schema design It ships with helpful defaults and automation, but it is not “click a button and forget Postgres exists.” Read why Fly Postgres is not the same thing as a managed database service before betting a company on it.

• Tied to Fly’s platform model:
  The cluster is a Fly app. That’s great for proximity and isolation, but:

  • You manage it with flyctl and Fly primitives (Machines, volumes, regions).

  • If you fork the fly-apps/postgres-flex image for heavy customization, you lose the fly postgres sugar and manage it as a regular app:

    One caveat is that once you fork, you won’t be able to use fly postgres commands to administer your app.

  Forking is powerful, but it pushes you further into “run your own Postgres automation” territory.

---

Pricing & Plans

There isn’t a separate “Fly Postgres plan” tax. Your cost comes from the underlying Fly primitives:

• The Machines that run Postgres (CPU, RAM)
• The volumes (NVMe) attached to those Machines
• Any additional replicas you create

The knobs you can turn:

• Choose smaller Machines and volumes for dev/staging.
• Scale up CPU/RAM and disk as your production workload grows.
• Add or remove replicas to match your read and HA requirements.

A pragmatic way to think about “plans”:

• Lean Cluster:
  Best for small teams, side projects, and early‑stage products that need a private Postgres but don’t push huge traffic.

  • 1 primary in your main region
  • Modest volume (e.g., 10–20 GB)
  • Possibly one small replica if you care about HA

• Production Cluster with HA + Replicas:
  Best for teams with real load and uptime expectations who want low‑latency reads in multiple regions.

  • 1 primary with more generous CPU/RAM and volume
  • 1–2 replicas in nearby or business‑critical regions
  • Daily snapshots plus your own backup strategy layered on top

You can always change the shape over time; you’re billed down to the second for CPU and memory use.

---

Frequently Asked Questions

Can I run Postgres with no public endpoint and still connect my app easily?

Short Answer: Yes. A Fly Postgres app can be fully private on Fly’s network, and you wire your app to it with fly postgres attach.

Details:
When you create a Postgres cluster with fly postgres create, it lives on Fly’s private WireGuard‑backed network by default. No public IPv4 or IPv6 is required. Your application app, running in the same Fly organization, reaches Postgres over the internal network and internal hostnames like my-app-db.internal.

Running:

fly postgres attach my-app-db -a my-app

• Creates a dedicated user + database for my-app.
• Injects the correct internal DATABASE_URL (and friends) into my-app’s environment.
• Leaves Postgres inaccessible from the public internet unless you explicitly expose it.

This gives you the “private database” behavior you’d usually get from a VPC or peering setup, but with a handful of commands.

---

Is Fly Postgres the same as a fully managed database service?

Short Answer: No. It’s closer to “batteries‑included Postgres you operate yourself” than to a black‑box managed database.

Details:
Fly Postgres (unmanaged) is:

• A regular Fly app running Postgres, with:
  • Replication
  • Failover
  • Metrics and monitoring
  • Daily snapshots
• Wrapped by fly postgres commands that make common workflows easy.

But it is not:

• A vendor‑managed, hands‑off Postgres where Fly’s SREs patch and tune the database for you.
• A service that hides WAL, extensions, and vacuum from your life.

You’re still responsible for:

• Planning versions and migrations
• Query performance
• Capacity planning

The upside is control: you can fork fly-apps/postgres-flex, add extensions, and roll your own image. The downside is: you own the database in the same way you’d own it on VMs—just with better tooling and network ergonomics.

---

Summary

If you’re looking for managed Postgres that can be private to your app network, with no public endpoint, and is easy to attach, Fly.io’s answer is Fly Postgres (unmanaged):

• It runs as a dedicated Fly app on Machines and volumes you control.
• It stays on Fly’s private, encrypted network unless you opt into a public listener.
• You attach it to your app with fly postgres attach, get DATABASE_URL wired automatically, and let the platform handle replication scaffolding and snapshots.

It is opinionated scaffolding, not a black‑box managed database—but for most teams deploying on Fly, it hits the sweet spot: private, close to your app, easy to plug in, and transparent enough to debug when things get weird.

---

Next Step

Get Started