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

Run PostgreSQL on your server

1. Open New Resource in the project and environment where the database should live, then pick PostgreSQL under Databases.
2. Choose the server and network. Pick the server that should run Postgres and the Docker network destination it should join. Build servers can't host databases.
3. Pick an image. At the time of writing the selector offers PostgreSQL 18, 17 and 16, plus Supabase PostgreSQL, PostGIS and PGVector extension images. PostgreSQL 18 (postgres:18-alpine) is the default.
4. Review the generated settings. Coolify creates the username postgres, the initial database postgres, a generated password and the connection URLs. Data lives on a named Docker volume, so recreating the container doesn't remove it.
5. Start it and wait until it's running and healthy. A health check is attached by default.
6. Copy the internal URL into the environment variables of your app:

The internal URL uses the database container name and works for apps on the same Coolify network. You can also add initialization scripts (they run only on an empty data directory) and your own postgresql.conf. The PostgreSQL docs page covers every setting.

Private by default, public when you need it

• Private: a new database gets no public endpoint. Apps on the same network connect with the internal URL.
• Public: if a client outside the server must connect, choose Public through TCP proxy and set a public port. Coolify then shows a public URL as well. A direct port mapping such as 15432:5432 is the other option.
• Lock it down: the docs advise keeping database ports private whenever possible. If you open one, restrict it with your server or provider firewall and use SSL.

Encrypt connections with SSL

Coolify can generate a server certificate for the database, signed by a CA for that server. Stop the database, set SSL to Enabled, pick an SSL mode and restart. PostgreSQL supports allow, prefer, require (the default), verify-ca and verify-full. The two verify modes need the connecting app to trust the Coolify CA certificate, which you mount from /data/coolify/ssl/coolify-ca.crt. Copy the updated URL into your app afterwards. See Database SSL.

Schedule backups

1. Add a schedule. Open the database, select Backups, then + Add. Enter a five-field cron expression or a named schedule: hourly, daily, weekly, monthly and others.
2. Choose what to back up. Pick specific databases or all of them. For specific databases Coolify runs pg_dump --format=custom. That archive keeps object owners and privileges. For all databases it runs pg_dumpall and gzips the output.
3. Set retention. Local copies are written under /data/coolify/backups on the database's server. You can limit backups to keep, days to keep and maximum storage in GB (0 means no limit). A backup is deleted when any limit is reached, and the most recent ones are kept first.
4. Send a copy off the server. Add and validate an S3-compatible storage, then enable it on the schedule. You can delete the local copy after a successful upload. S3 retention uses the same three limits and is set separately from local retention.
5. Run it once by hand. Select Back up now and check the execution: status Success, the right databases, a file size above zero and, if enabled, a successful S3 upload.

Good to know:

• Storage providers. The docs have setup guides for Amazon S3, Cloudflare R2, Neon Object Storage and Supabase Storage, and list DigitalOcean Spaces, MinIO, Backblaze B2, Scaleway Object Storage, Hetzner S3 Storage, Wasabi Hot Cloud Storage, Vultr, CloudPe Object Storage and IDrive e2 as supported. The bucket must exist before you validate it.
• Timing. A schedule runs in the server's timezone (or the Coolify instance timezone if the server has none). A backup runs only while the database is running. If it's stopped when the schedule fires, that run is skipped. The job timeout defaults to 3600 seconds.
• Alerts. Coolify can send Backup Success and Backup Failure notifications by email, Discord, Telegram, Slack, Pushover or webhook. A failed S3 upload after a good local backup is reported through Backup Failure.
• Postgres inside a one-click service can be backed up too. Coolify reads POSTGRES_PASSWORD, POSTGRES_USER and POSTGRES_DB from the container.

Full reference: Database backups.

Restore a backup

1. Stop application writes and take a separate backup of the target database.
2. Open Import Backup on the running database and choose a source: a file from your computer, an absolute path on the server, or a file in your S3 storage.
3. Review the detected format and the read-only Import command. Coolify picks pg_restore or psql to match the dump. It accepts SQL dumps, custom archives, tar archives and all-database dumps, compressed with gzip, bz2, xz or zip.
4. Start the restore and follow the output. PostgreSQL restores run in one transaction. Replacing existing objects and keeping owners and privileges are both off by default.
5. Check schemas and a few real records with a client, then turn writes back on and take a fresh backup.

Imports are also available through the API. See Restore a database.

What you still own

Coolify automates the database and its backups. It doesn't take the operator job off your plate:

• Server security. OS updates, firewall rules and SSH access are yours, whether you self-host Coolify or use Coolify Cloud. Coolify can notify you when a patch check finds OS updates.
• Testing restores. In the docs' words: "A successful backup only proves that Coolify created a file." Restore a copy into a disposable database and check that your app can read it.
• Off-server copies. Local backups live on the same server as the database. Turn on S3 so a lost server doesn't take the backups with it.
• Monitoring. With Sentinel metrics enabled, Coolify shows CPU and memory history for the standalone database container, and it can warn you when server disk usage crosses a threshold. Query performance and slow queries are up to you.
• Major version upgrades. Don't switch a production database image to a new major version without following PostgreSQL's upgrade procedure and taking a verified backup first.
• The Coolify instance itself. Coolify's instance backup saves projects and settings, not the data in your databases. Database backups are a separate job.

When to use something else

• You need point-in-time recovery. Coolify's scheduled backups are dumps, so you can restore to the moment a dump ran. PostgreSQL documents point-in-time recovery as part of continuous WAL archiving, which you'd set up separately.
• You need a cluster or several database nodes. The one-click database is a single container. For multiple nodes or a custom topology, Coolify's docs point to a Docker Compose service or an external database provider.
• You don't want to run a server at all. With both self-hosted Coolify and Coolify Cloud, your databases run on your own servers. If you'd rather not own server updates, firewalls and restore tests, a managed Postgres provider is the trade.
• You only need one database and like the terminal. Plain pg_dump on a cron job works. PostgreSQL's docs note that its dumps are internally consistent and don't block other operations while they run. Coolify uses the same tool and adds the schedule UI, retention, S3 upload, alerts and a restore screen.

Comparing self-hosted platforms? See Coolify vs Dokploy vs CapRover vs Dokku vs Kamal.

FAQ