Databases

Supported Engines

DeployKit runs the official image of each engine. The version is fixed per engine:

Creating a Database

From your project page, open New Database, pick a name, a type and the target server. For MongoDB you can tick Enable Replica Set. Creating a database requires the Operator or Admin role on the project.

• The container is named dk-<name> and its data lives in the Docker volume dk-<name>-data
• The user is admin with a generated password, stored encrypted (AES-256-GCM); the initial database is named after the database
• Redis is created without a password — it is only reachable from inside the Docker network
• MongoDB replica sets get a keyfile and rs.initiate() automatically, so transactions and change streams work
• Each database has Connection, Backups, Monitoring, Logs and Tasks tabs — metrics, persistent logs and alert rules work exactly as for applications

Connecting from Your Apps

Databases are not exposed to the internet: they get no domain, no Traefik route and no published host port. They live on the deploykit-network Docker network and are reached by the internal hostname dk-<name> from applications running on the same server. Copy the connection string from the Connection tab into an environment variable of your app:

# PostgreSQL
postgresql://admin:<password>@dk-mydb:5432/mydb

# MySQL / MariaDB
mysql://admin:<password>@dk-mydb:3306/mydb

# MongoDB (replicaSet=rs0 is added when the replica set is enabled)
mongodb://admin:<password>@dk-mydb:27017/mydb?authSource=admin

# Redis
redis://dk-mydb:6379

Only project Operators and Admins can see the connection string and password; Viewers see a restricted notice instead. There is no option to publish a database port. For ad-hoc work (a VACUUM, a one-off query) use the database's Tasks tab: commands run in the engine's client image with DK_DB_HOST, DK_DB_USER and the password already injected.

Scheduled Backups

In the Backups tab, switch on automatic backups, choose a schedule (daily at 2:00 AM, every 6 or 12 hours, weekly or monthly) and a retention period, then click Save Config. The schedule takes effect immediately — no restart needed. Backup Now queues a manual backup at any time.

• Files are written to /var/backups/deploykit/<database-name>/ on the host (bind-mounted into the API container)
• Retention is in days (1–365, default 7): after each successful backup, files older than the retention period are deleted
• Schedules run on the API container's clock, which is UTC by default
• Each backup fires a backup.completed or backup.failed notification, and manual backups and config changes are recorded in the audit log

Restoring a Backup

The Backups tab lists every file with its size and age. Use the restore button next to a backup and confirm; delete removes the file permanently. Restoring and deleting backups require the Operator or Admin role on the project.

• PostgreSQL and MySQL/MariaDB replay the SQL dump into the existing database — objects that already exist can conflict, so restore into an empty database when in doubt
• MongoDB restores with --drop, replacing the collections contained in the archive
• Redis backups are listed and kept on disk, but the dashboard offers no restore button for them

Stopping and Deleting

Operators can stop and start a database. Deleting it requires the Admin role on the project and removes the container and its backup schedule; the data volume dk-<name>-data and the backup files on disk are kept. A database imported from a configuration manifest has no container yet: the first Start provisions it with the stored password, so existing connection strings keep working.