Databases

The easiest way to self-host a database with backups is to install Coolify on a server you control, create a one-click database, and add a backup schedule that can upload to S3-compatible storage. PostgreSQL, MySQL, MariaDB, MongoDB, ClickHouse, and experimental SQLite can take scheduled backups; dashboard restore works for every one of those except ClickHouse. Redis, Dragonfly, and KeyDB do not support scheduled backups or dashboard restore, and you still own server security and regular restore tests.

Coolify deploys each standalone database as a container on the server and network you select. The resource includes generated credentials, a persistent data volume, an internal connection URL, and controls for networking, health checks, storage, and resource limits. Use a one-click database when the engine is in the list below. Use Docker Compose when you need an engine or topology that is not.

If you are new to Coolify databases, start with What is a database, How databases work, and Choose a database. The backup path is below. A first deployment that only needs a running container is Deploy your first database; that guide uses Redis, which does not have scheduled backups.

Supported engines

Scheduled backups means Coolify can run an engine-specific dump from the database's Backups page. Dashboard restore means Import Backup can load a backup while the database is running. Redis, Dragonfly, KeyDB, and ClickHouse still open an Import Backup page, and that page reports that restore is not supported. Redis, Dragonfly, and KeyDB do not show Backups. They still have persistent storage.

ClickHouse and SQLite schedules apply to the standalone database resource. A PostgreSQL, MySQL, MariaDB, or MongoDB database inside a Service can use the same scheduled backup workflow. See Back up a database inside a service.

Self-host a database with backups

1. Install Coolify if you do not already run it. Follow Start with self-hosted. Coolify Cloud hosts the Coolify instance only. In both cases the database runs on a server you provide.
2. Open a project and select Create New Resource, then choose an engine that has scheduled backups in the table above. Pick the server and Docker network. Build servers cannot be selected because they do not host running database resources. Image choices follow the current Coolify release; see Choose a database before you change a major version.
3. Review the generated credentials and persistent volume, then select Start. Wait until the database is running and healthy. Copy the Internal URL into applications on the same destination network. A new database has no public endpoint. Read Network access and Database SSL before you publish a port.
4. Open Backups, select + Add, and enter a five-field cron expression or one of these names: every_minute, hourly, daily, weekly, monthly, yearly. The schedule uses the server timezone, or the Coolify instance timezone when the server has none. If the database is stopped when the schedule fires, Coolify skips that run. Scope and per-engine dump commands are in Database backups.
5. Set retention. Backups to keep, Days to keep, and Maximum storage (GB) each use 0 for no limit. The limits work independently: Coolify deletes a backup when any configured limit is reached, keeping the most recent backups first. S3 retention uses the same three fields and is independent of the local limits. Local files are written under /data/coolify/backups on the database server.
6. Send a copy off the server. Add and validate an S3-compatible storage. The bucket must already exist. Coolify has setup guides for Amazon S3, Cloudflare R2, Neon Object Storage, and Supabase Storage, and also supports DigitalOcean Spaces, MinIO, Backblaze B2, Scaleway Object Storage, Hetzner S3 Storage, Wasabi Hot Cloud Storage, Vultr, CloudPe Object Storage, and IDrive e2. On the schedule, select the storage and Enable S3. Delete after S3 upload removes the local file only after the upload succeeds.
7. Select Back up now while the database is running. Confirm the execution status is Success, the database names match the scope you chose, the file size is greater than zero, and the S3 upload succeeded when S3 is enabled.
8. Restore a copy before you trust the backup. Import Backup accepts a file from your computer, an absolute path on the server, or an object in S3 storage for PostgreSQL, MySQL, MariaDB, MongoDB, and SQLite. Stop application writes and take a separate backup of the target first. ClickHouse has no built-in import; restore that archive with a ClickHouse client. Follow Restore a database.

What you still own

Coolify creates the database resource and the backup files. It does not take over the server or prove that a backup can be restored.

• Server security. Operating system updates, firewall rules, and SSH access stay with you, including when you use Coolify Cloud. Coolify can notify you when a patch check finds operating system updates. See Firewall and Notification events.
• Restore tests. A successful backup only proves that Coolify created a file. Restore a copy into a disposable database and check that the application can read it.
• Off-server copies. Local backups live on the same server as the database. Enable S3 so a lost server does not take the only copy with it.
• The Coolify instance backup. An instance backup saves Coolify's projects and settings. It does not back up data stored inside your databases.
• One container, not a cluster. A one-click database is a single container. Replication, failover, and multi-node topologies are not part of that resource. Use a Compose Service or an external database when you need them.
• Major version upgrades. Do not change a production database image to another major version without the engine's upgrade procedure and a verified backup.
• What metrics cover. Enable metrics on the server to collect CPU and memory samples through Sentinel. Those charts do not include query performance. See Metrics.

FAQ

Deploy a database

1. Open a project and select Create New Resource.
2. Select a database from the database list.
3. Select the server and destination where the database should run.
4. Review the generated credentials and settings under General.
5. Select Start.

Coolify creates the database container on the selected destination. The database does not receive a public network endpoint by default.

For a complete first-deployment walkthrough, read Deploy your first database.

Connect an application

When an application runs on the same Coolify destination network as the database, use the database's Internal URL. Coolify builds this URL with the database container name, internal port, credentials, and selected database.

Copy the URL from the database's General configuration and add it to the application's environment variables. Do not replace the container name with a server IP for an internal connection.

If the application runs on another server or network, use a public connection only when the database must accept external traffic. See Network access for the two public access methods.

Network access

Coolify provides two ways to expose a database port:

A port mapping uses the format host-port:container-port, for example 15432:5432. You can enter multiple comma-separated mappings. The database container is recreated when its generated configuration changes.

The public TCP proxy requires the database to be running and a Public port between 1 and 65535. Proxy timeout defaults to 3600 and must be at least 1. The proxy is separate from the database container, so changes to the public port or timeout update the proxy rather than the database process.

When a database is public, Coolify displays a Public URL next to the internal URL. Use that generated URL instead of assembling a connection string by hand.

Persistent data

Coolify creates a named Docker volume when it creates a standalone database. The volume remains separate from the database container so redeploying or recreating the container does not remove the database data.

Persistent storage is not a database-aware backup. Use database backups for supported engines and test restoring a database before relying on it.

Open Persistent Storage to add or change storage mounts. Changing or removing a mount can make existing data unavailable to the container, so verify the source and destination before saving.

Database health

Coolify can attach a Docker health check to every standalone database. Open Healthcheck to configure:

• Interval (seconds): time between checks; minimum 1.
• Timeout (seconds): maximum time for one check; minimum 1.
• Retries: failed checks before Docker marks the container unhealthy; minimum 1.
• Start period (seconds): startup time before failed checks count; minimum 0.

Health checks are enabled by default in current Coolify versions. Save the settings, enable or disable the check, then restart the database to apply the generated container configuration.

Database resource navigation

The database resource navigation separates configuration from day-to-day operations:

Continue with a database guide

Choose a database

Compare one-click engines, versions, backup support, and Services.

Configure backups

Schedule and retain engine-aware database backups.

Secure connections with SSL

Enable SSL and choose the verification mode supported by the engine.