coolify-databases — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited coolify-databases (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Covers provisioning, backups, SSL, credential management, and operational patterns for Coolify v4 self-hosted database management.
Self-Hosted Only: All content assumes self-hosted Coolify v4.x. Database management differs on Coolify Cloud.
Coolify provides one-click provisioning for these databases:
| Engine | Versions Available | Backup Support | Notes |
|---|---|---|---|
| PostgreSQL | 13, 14, 15, 16, 17, 18 | Yes (pg_dump) | Most common choice; full backup/restore. PG18 + pgvector 18 added in beta.463 (Feb 2026). |
| MySQL | 5.7, 8.0, 8.4 | Yes (mysqldump) | Classic RDBMS |
| MariaDB | 10.x, 11.x | Yes (mariadb-dump) | MySQL-compatible alternative |
| MongoDB | 5.x, 6.x, 7.x | Yes (mongodump) | Document store |
| Redis | 6.x, 7.x | No built-in | In-memory store; use RDB/AOF persistence config |
| KeyDB | Latest | No built-in | Redis-compatible, multi-threaded |
| Dragonfly | Latest | No built-in | Redis-compatible, high-performance |
| ClickHouse | Latest | No built-in | Column-oriented analytics DB |
Version note: Coolify's docs don't always pin exact major versions on the overview page — verify in your running Coolify UI which versions are currently selectable. The overview above reflects what was current as of beta.474 (April 2026). When new major versions ship in upstream images, Coolify typically adds them within a few releases.
START: What database do you need?
│
├─ Relational data with complex queries?
│ ├─ Need MySQL compatibility? → MySQL or MariaDB
│ └─ Default choice / best ecosystem → PostgreSQL
│
├─ Document/JSON data?
│ └─ MongoDB
│
├─ Caching / sessions / queues?
│ ├─ Standard → Redis
│ ├─ Need multi-threading → KeyDB or Dragonfly
│ └─ Need Redis compatibility + lower memory → Dragonfly
│
├─ Analytics / time-series?
│ └─ ClickHouse
│
└─ None of the above?
└─ Deploy any database as a Docker Compose service or pre-built imageAll Coolify resources (apps and databases) on the same server share the coolify Docker network. Apps connect to databases using the internal hostname (container name):
postgresql://user:pass@<DB_CONTAINER_NAME>:5432/mydbTo connect external clients (TablePlus, DBeaver, pg_admin):
5432 or a custom port)<SERVER_IP>:<PORT>Security warning: Always use a non-default port, strong credentials, and firewall rules (UFW) to restrict access to trusted IPs only.
For multiple apps on the same server that share one database:
coolify network can reach each other by container nameMove the database to its own server when:
s3.amazonaws.com, nyc3.digitaloceanspaces.com, Minio URL)0 2 * * * for daily at 2 AM)| Engine | Tool Used | Output Format |
|---|---|---|
| PostgreSQL | pg_dump --format=custom | .dmp (custom binary format) |
| MySQL | mysqldump | SQL dump |
| MariaDB | mariadb-dump | SQL dump |
| MongoDB | mongodump --gzip --archive | Gzipped BSON archive |
Coolify uses cron expressions for scheduling:
| Schedule | Cron Expression |
|---|---|
| Every hour | 0 * * * * |
| Daily at 2 AM | 0 2 * * * |
| Every 6 hours | 0 */6 * * * |
| Weekly (Sunday 3 AM) | 0 3 * * 0 |
| Custom | Any valid cron expression |
Configure retention by number of backups kept. Older backups are automatically deleted when the limit is reached. Set this in the database backup settings.
From Coolify UI (when available):
Manual restore from S3 backup:
# PostgreSQL
# 1. Download the backup from S3
aws s3 cp s3://<BUCKET>/backups/<DB_NAME>/<TIMESTAMP>.sql.gz ./backup.sql.gz
# 2. Decompress
gunzip backup.sql.gz
# 3. Exec into the database container or connect remotely
docker exec -i <POSTGRES_CONTAINER> psql -U <USER> -d <DATABASE> < backup.sql
# MySQL/MariaDB
docker exec -i <MYSQL_CONTAINER> mysql -u <USER> -p<PASSWORD> <DATABASE> < backup.sql
# MongoDB
docker exec -i <MONGO_CONTAINER> mongorestore --archive < backup.archive| Scenario | SSL Required? |
|---|---|
| App → DB on same Coolify server (private network) | No — traffic stays on Docker bridge |
| App → DB on different server | Yes — traffic traverses network |
| External client → DB over internet | Yes — always encrypt in transit |
| Compliance requirements (PCI, HIPAA) | Yes — regardless of network topology |
| Mode | Behavior |
|---|---|
disable | No SSL |
require | SSL required, no certificate verification |
verify-ca | SSL required, verify server CA |
verify-full | SSL required, verify CA + hostname |
Set via connection string: postgresql://user:pass@host:5432/db?sslmode=require
Option 1 — Pre-deployment script (recommended): Configure a pre-deployment script in the app settings that runs migrations before the new container receives traffic.
Option 2 — Exec into app container:
docker exec -it <APP_CONTAINER> npx prisma migrate deploy
# or
docker exec -it <APP_CONTAINER> python manage.py migrateOption 3 — One-off container:
docker run --rm --network coolify \
-e DATABASE_URL="postgresql://user:pass@db-container:5432/mydb" \
<APP_IMAGE> npx prisma migrate deployufw allow from <YOUR_IP> to any port <DB_PORT><SERVER_IP>:<PORT>, database user, and passwordWarning: There is no built-in zero-downtime credential rotation. Plan a brief maintenance window or use connection poolers that support hot credential swaps.
Set CPU and memory limits in the database resource settings:
2.0 for 2 cores)When a database container hits its memory limit, Docker's OOM killer terminates it. Coolify's restart policy brings it back, but in-flight transactions are lost.
Coolify configures database containers with Docker restart policy unless-stopped. After a server reboot, Docker automatically restarts all database containers. Coolify's Sentinel agent verifies container health after boot.
| Anti-Pattern | Consequence |
|---|---|
| Exposing database port to 0.0.0.0 without firewall rules | Database accessible to the entire internet |
| No backup schedule configured | Data loss on disk failure or corruption |
| Storing backups on the same server as the database | Single point of failure; backup lost with the server |
| Using default credentials (postgres/postgres) | Trivially compromised |
| Not setting memory limits on database containers | OOM kills the database AND other containers on the server |
| Running migrations in Dockerfile build phase | Migrations run against wrong database or fail in CI |
| Sharing a small Redis between cache and queue workloads | Cache evictions delete queued jobs |
| Not testing backup restoration | Discover corrupt backups only during an emergency |
| Exposing ports and forgetting to close them | Permanent attack surface |
Using sslmode=disable for cross-server connections | Credentials sent in plaintext |
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.