Databases
Coolify deploys standalone databases as containers on the server and network you select. Each database resource includes generated credentials, a persistent data volume, an internal connection URL, and controls for networking, health checks, storage, and resource limits.
Use the one-click database list when you want Coolify to create the container configuration for a supported engine. You can also deploy a database with Docker Compose when you need an engine or topology that is not in this list.
If you are new to Coolify databases, start with What is a database, How databases work, and Choose a database. Then follow Deploy your first database.
Choose a database
| Database | Best suited for | Built-in scheduled backups | Default internal port |
|---|---|---|---|
| PostgreSQL | Relational data, extensions, and transactional workloads | Yes | 5432 |
| MySQL | Relational applications and broad ecosystem support | Yes | 3306 |
| MariaDB | MySQL-compatible relational workloads | Yes | 3306 |
| MongoDB | Document-oriented data and flexible schemas | Yes | 27017 |
| Redis | Caching, queues, streams, and key-value data | No | 6379 |
| Dragonfly | Redis-compatible workloads on a multithreaded datastore | No | 6379 |
| KeyDB | Redis-compatible workloads with multithreading | No | 6379 |
| ClickHouse | Analytical and column-oriented workloads | Yes | 9000 |
Scheduled backup support means that Coolify can run an engine-specific dump job from the database's Backups page. Redis, Dragonfly, and KeyDB still have persistent storage, but they do not expose Coolify's scheduled database backup workflow.
Deploy a database
- Open a project and select Create New Resource.
- Select a database from the database list.
- Select the server and destination where the database should run.
- Review the generated credentials and settings under Configuration > General.
- 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:
| Method | What it does | When to use it |
|---|---|---|
| Ports Mappings | Adds a Docker host-to-container port mapping to the database container. | A fixed host port or a client that connects directly to the server. |
| Make it publicly available | Runs a separate Nginx TCP proxy on the selected Public Port. | A public connection that you want to change without changing the database container's port mappings. |
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 (seconds) 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.
A public database port exposes a database protocol to the network. Use private networking whenever possible. If an external client must connect, restrict the port with your server or provider firewall and use SSL where the engine supports it.
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.
| Database | Container data path |
|---|---|
| PostgreSQL before version 18 | /var/lib/postgresql/data |
| PostgreSQL 18 and later | /var/lib/postgresql |
| MySQL and MariaDB | /var/lib/mysql |
| MongoDB | /data/db and /data/configdb |
| Redis, Dragonfly, and KeyDB | /data |
| ClickHouse | /var/lib/clickhouse |
Persistent storage is not a database-aware backup. Use database backups for supported engines and test restoring a database before relying on it.
Open Configuration > 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 Configuration > Healthcheck to configure:
- Interval (s): time between checks; minimum
1. - Timeout (s): maximum time for one check; minimum
1. - Retries: failed checks before Docker marks the container unhealthy; minimum
1. - Start Period (s): 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:
| Area | Use it to | Guide |
|---|---|---|
| General | Change engine credentials, image, ports, proxy, and engine-specific configuration. | General settings |
| Environment Variables | Manage runtime variables passed to the database container. | Environment variables |
| Servers | Review or change the selected server and destination. | Configure multi-server deployments |
| Persistent Storage | Manage the named volumes and mounts that keep database data across container recreation. | Persistent storage |
| Import Backup | Restore a supported PostgreSQL, MySQL, MariaDB, or MongoDB backup while the database is running. | Restore a database |
| Webhooks | Create authenticated requests for database operations from external automation. | Deploy webhooks |
| Healthcheck | Configure the Docker readiness and liveness probe. | Health checks |
| Resource Limits | Set CPU and memory limits for the database container. | Resource limits |
| Resource Operations | Clone the database to another destination or move it between projects and environments. | Clone or move a database |
| Metrics | View CPU and memory usage for the database container. | Monitor resource metrics |
| Tags | Organize the resource and use it with tag-based automation. | Organize resources with tags |
| Danger Zone | Delete the database resource and choose which related Docker resources to remove. | Delete a database |