Databases
Run PostgreSQL, MySQL, MongoDB, Redis and more, and connect them to your applications.
DockBoard runs your databases as containers inside a project, on the same private network as the applications that use them. There is no public port to open and no connection to secure across the internet — the database is simply not reachable from outside.
Creating a database
From Databases → New database, pick an engine:
- PostgreSQL
- MySQL / MariaDB
- MongoDB
- Redis / KeyDB / Dragonfly
- ClickHouse
DockBoard creates a container named dockboard-db-<slug> on the project network, generates a username and password, and stores them. You never have to invent credentials.
Connecting an application
The Service Mesh tab hands you the connection string already filled in. For PostgreSQL it looks like this:
DATABASE_URL=postgres://<user>:<password>@dockboard-db-<slug>:5432/<slug>Paste it into the application’s environment variables. The hostname is the container name, resolved by Docker’s internal DNS — which is why no firewall rule and no published port are involved.
Persistent volumes
A container’s filesystem is ephemeral: every redeploy re-clones and rebuilds it, so anything written inside — an upload directory, a SQLite file, a cache — is gone. A managed database gets its data volume automatically. For an application that writes files, declare one yourself on the application page, in the Persistent volumes card:
| Field | Meaning | Example |
|---|---|---|
| Volume name | A named Docker volume — letters, digits, _ . -. Not a host path. | uploads |
| Container path | The absolute path inside the container to mount it at. | /app/uploads |
Add as many as you need, then Apply — which triggers a redeploy. The volume is created as dockboard-<slug>_<name> and re-attached on every subsequent redeploy, so its contents survive. Because it follows the platform’s naming convention, it is also picked up automatically by backups.
/var/run/docker.sock, /etc, ../data, ~) is rejected, by the same filter that guards imported Compose files. This holds identically for local deployments and remote servers.storage/, Symfony var/) still get their runtime volumes automatically; anything you declare is merged alongside. An application that ships its own docker-compose.yml is authoritative — declare volumes there, the platform does not inject into it.Backups and moving
A database is backed up like anything else in the project — scheduled dumps, off-site copies, and a restore that is verified rather than assumed. See backups and restores. When a project moves to another server, its database volumes travel with it: moving and exporting projects.