Database Provisioning

Free: 3 databases. Pro: unlimited. Backups can only be taken of a provisioned, running database.

Supported Engines

• PostgreSQL (postgres:16-alpine)
• MySQL (mysql:8) — needs one extra Linux capability (DAC_OVERRIDE) its 8.4+ entrypoint requires at startup to fix permissions on /var/lib/mysql-files
• Redis (redis:7-alpine)
• MongoDB (mongo:7)
• ClickHouse (clickhouse/clickhouse-server:24-alpine) — gets a higher resource ceiling than the others (1GB memory, 2048 process/thread limit vs. the flat 512MB/512 default) and two extra Linux capabilities (CHOWN, KILL) its entrypoint needs at startup; every other engine keeps the tighter default
• DragonflyDB (docker.dragonflydb.io/dragonflydb/dragonfly:latest) — a Redis-protocol-compatible engine, so it's a drop-in alternative wherever you'd use Redis

Memory-Relative Tuning

PostgreSQL, MySQL, Redis, and DragonflyDB start with extra flags sized against the container's actual memory limit (512MB by default — the same ceiling Git Deployment apps get) instead of the stock image defaults meant for a full dedicated host with gigabytes of RAM to spare:

Engine	Tuned via	At the 512MB default
PostgreSQL	-c key=value flags	shared_buffers=128MB, effective_cache_size=384MB, max_connections=39, work_mem=4MB, maintenance_work_mem=32MB
MySQL	--flag=value args	innodb-buffer-pool-size=128M, innodb-buffer-pool-instances=1, max-connections=51, performance-schema=OFF
Redis	--flag value args	maxmemory set to 75% of the container's limit, maxmemory-policy allkeys-lru — evicts least-recently-used keys as the limit approaches instead of rejecting writes once full
DragonflyDB	--flag=value args	same maxmemory/eviction behavior as Redis (cache_mode=true), plus proactor_threads=1 — Dragonfly's own default shards across one thread per CPU core, which a single memory-capped container has no use for

MongoDB and ClickHouse aren't tuned this way — MongoDB has no clean CLI-flag equivalent for this, and ClickHouse's memory needs are already covered by its own higher resource ceiling above rather than flags.

Tuning is applied once, at provision time — an already-running database keeps whatever flags it started with. There's no retroactive re-tuning or automatic recreate; provisioning a fresh database is the only way to pick up a change here.

One Container Per Database

Every time you click New Database, DockPod provisions a brand-new, dedicated container — it does not share an existing container of the same engine and just add a logical database inside it. Each one gets:

• Its own named volume for persistence
• A randomly generated password (and, for MySQL, a separate root password)
• A host port auto-assigned starting from the engine's default port, checked against the Docker/Podman daemon's actual container port bindings (not a host-level socket probe — Docker Desktop's virtualized networking on macOS/Windows makes host-level checks unreliable) and skipping anything already taken
• A port binding of 127.0.0.1:<port> by default — see Accessible from Public below for the opt-in alternative

This trades some resource efficiency for isolation: stopping, deleting, or backing up one database never touches another.

Accessible from Public

By default every database is bound to 127.0.0.1 only — same reasoning as Paste & Deploy's DB presets. Checking Accessible from public at provision time binds it to 0.0.0.0 instead, reachable from outside the host. This is a create-time choice only — changing it later means deleting and re-provisioning.

On Docker, this bypasses your firewall, not just "opens a port." Docker inserts its own DNAT/FORWARD iptables rules for published container ports, and that traffic is not filtered by ufw/firewalld's default INPUT-chain rules — meaning a public database is reachable from the internet even with the installer's firewall setup active and default deny incoming in effect. Rootful Podman with netavark networking behaves the same way; rootless Podman's userspace port forwarding (slirp4netns/pasta) is a real listening socket instead, which is subject to normal INPUT-chain filtering — if you're on rootless Podman, verify your own firewall rules rather than assuming either way. Only enable this if you specifically need external access, and keep the generated password safe — it's the only thing standing between the internet and the database.

Connection String

Each provisioned database shows a ready-to-use connection string (postgres://user:[email protected]:port/db, etc). The password segment is masked by default — click the eye icon to reveal it, or use the copy button to grab the full string regardless of whether it's currently shown. That 127.0.0.1 address only resolves from the DockPod host itself, though — to reach a database from inside a deployed app's own container, see Linking a Database.

Backups

Click Backup on a running database to trigger a dump and download it straight to your browser — nothing is written to disk on the server. Under the hood:

Engine	Command
PostgreSQL	pg_dump
MySQL	mysqldump
Redis	redis-cli --rdb /dev/stdout
MongoDB	mongodump --archive
ClickHouse	loops every table, dumping each as a Native-format block (there's no single-command full-database dump tool like pg_dump)
DragonflyDB	SAVE then reads back the resulting snapshot file — redis-cli --rdb's replication-based streaming doesn't work against Dragonfly's server, confirmed during testing

The dump streams directly from the container's stdout to the HTTP response — it's never written to a file inside the container either. Every engine's backup can be downloaded raw or gzip-compressed — pick either from the download dialog.

Backups are download-only — there's no restore-from-backup feature. Restoring is a manual docker exec with the matching engine's own restore tool (psql, mysql, etc.) against the dump you downloaded.

Quick Stats

A database's detail page General tab shows a quick view of total storage size and an item count — tables for PostgreSQL/MySQL/ClickHouse, collections for MongoDB, keys for Redis/DragonflyDB. It's read directly from the engine (e.g. pg_database_size(), INFO memory + DBSIZE), not cached, so it always reflects current state.