Docker Postgres on a single box is a legitimate production setup for a small team, not a local-dev shortcut that happens to also run in production. Get three things right and it holds up: the data volume actually persists across a restart, backups exist before you need them, and someone specific knows what breaks first as load grows. Get any of those wrong and it's indistinguishable from not having a database strategy at all.

The actual setup

A minimal, real docker-compose.yml for this:

services:
  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - pgdata:/var/lib/postgresql/data
    ports:
      - "5432:5432"
volumes:
  pgdata:

Two details here are where people get burned. First, pin a real version tag (postgres:16, not postgres:latest), so an unrelated docker compose pull doesn't silently jump you to a new major version. Second, the volume mount path depends on which Postgres version you're running: /var/lib/postgresql/data for Postgres 17 and earlier, /var/lib/postgresql for Postgres 18 and later, which moved to a version-specific internal layout. Mount at the wrong path for your version and the container starts fine, looks fine, and quietly doesn't persist anything across a restart.

POSTGRES_PASSWORD is the only required environment variable. Never set POSTGRES_HOST_AUTH_METHOD=trust outside a throwaway local container, it allows passwordless access even when a password is configured, which defeats the point of setting one.

What this handles vs. where it breaks

The honest line is ownership, not scale. Managed Postgres options exist for a reason: self-hosting on a single box is where databases quietly get lost the moment "someone owns backups and monitoring" stops being a specific person with that written down. Nobody watching causes that, not Docker being unreliable.

What it actually costs

A single box running both the application and Postgres is priced like any other small VPS or droplet. For how the egress line item specifically adds up once real traffic is moving data off that box, see our per-provider pricing breakdown. The Postgres side itself adds close to nothing beyond the box you're already paying for, that's the actual appeal of this setup. What it doesn't include is the cost of someone's time when a 3am disk-full alert has no one assigned to answer it.

The honest verdict: this setup is right for a small team that can name the specific person responsible for backups and would notice if a restore never got tested. It's the wrong call the moment that person is "whoever's around," not because Docker and Postgres can't handle real production traffic on one box, they can, but because the thing that actually fails here is ownership, not the technology.