What's the easiest way to self-host a Postgres database with backups?

Add PostgreSQL

• Open New Resource and pick PostgreSQL. Choose the server and Docker network. Build servers cannot host databases.
• Images: PostgreSQL 18, 17, and 16, plus Supabase PostgreSQL, PostGIS, and PGVector. The default is postgres:18-alpine.
• Coolify sets user postgres, database postgres, a generated password, a persistent volume, and a health check. Start it, then copy the internal URL into your app.

Apps on the same network use this URL:

• A new database has no public endpoint. Use Public through TCP proxy or a port mapping only for an outside client, and restrict it with a firewall.
• Init scripts run only on an empty data directory. You can also supply postgresql.conf.
• For SSL, stop the database, set SSL to Enabled, and restart. require is the default. verify-ca and verify-full need the app to trust /data/coolify/ssl/coolify-ca.crt. Database SSL.

The PostgreSQL docs page lists every setting.

Schedule backups

• Open Backups, then + Add. Use cron, or a named schedule such as hourly, daily, weekly, or monthly.
• Specific databases: pg_dump --format=custom. All databases: pg_dumpall, gzipped.
• Local files go under /data/coolify/backups. You can limit the count, the days, and the GB. 0 means no limit. When any limit is reached, Coolify deletes older backups and keeps the newest. S3 retention uses the same three limits, set separately.
• Validate an S3-compatible bucket (it must already exist) and enable it on the schedule. You can delete the local copy after a successful upload. Guides cover Amazon S3, Cloudflare R2, Neon Object Storage, and Supabase Storage. S3 storage lists more providers, including Backblaze B2.
• The schedule uses the server timezone, or the instance timezone if the server has none. A stopped database skips that run. The job timeout defaults to 3600 seconds.
• Postgres in a one-click service works too. Coolify reads POSTGRES_PASSWORD, POSTGRES_USER, and POSTGRES_DB from the container.
• Run Back up now and check for Success, a file size above zero, and a successful upload.

The docs say: "A successful backup only proves that Coolify created a file." Full reference: Database backups.

Restore a backup

• Stop application writes and take a separate backup of the target first.
• Open Import Backup on the running database. The file can come from your computer, an absolute path on the server, or S3.
• Coolify picks pg_restore or psql and shows the command. It accepts SQL, custom, tar, and all-database dumps, compressed with gzip, bz2, xz, or zip. The restore runs in one transaction. Replacing existing objects, and keeping owners and privileges, are off by default.

You can also import through the API. See Restore a database.

What you still own

• OS updates, the firewall, and SSH, on self-hosted Coolify and on Coolify Cloud.
• Restore tests. A backup file does not prove your app can read the data.
• An off-server copy. Local backups sit on the same server as the database.
• Major upgrades. Follow PostgreSQL's upgrade steps, and take a verified backup first.
• Database data itself. A Coolify instance backup saves settings, not your database contents.

When a dump is the wrong tool

• You need point-in-time recovery. These backups are dumps, so you restore to the time a dump ran. PostgreSQL documents point-in-time recovery as continuous WAL archiving, which is a separate setup.
• You need several database nodes. The one-click database is a single container.
• You do not want to run a server. In both self-hosted Coolify and Coolify Cloud, the database runs on a server you provide. A managed Postgres provider is the alternative.

Deploying the app that uses this database: deploy apps on your own VPS. Comparing platforms: Coolify vs Dokploy vs CapRover vs Dokku vs Kamal. If you are replacing a hosted database, see free Heroku alternatives.

FAQ