Skip to main content
Databases are ordinary deployments made from a template, with a volume for their data. Mangrove has no separate managed-database layer.

Create one

In a project, Deploy from template and pick one: Choose a slug, such as blog-db. Generated passwords are shown once, right after install. Copy them then. They’re also stored as secret variables on the database’s service, which can be replaced but not read back. Apps that need a database, such as WordPress or Ghost, install their own alongside themselves. You don’t need to add one first.

Connect from an app

Database templates are internal only: nothing outside the box can reach them. Apps on the same box connect over Mangrove’s Docker network using the database service’s alias, mangrove-<slug>-app:
Set that as a secret variable on your app, then Redeploy the app so it picks it up. The database’s Overview tab shows its Internal address.

Reach it from your laptop

There’s no public port for a database. Use an SSH tunnel to the container’s address on the box:
The IP changes on every deploy of the database.

Run commands and migrations

The Run command card on the database’s Overview tab runs a one-off command inside its container:
It suits short commands. Output is returned when the command finishes. For an interactive shell, use mangrove-tui (see Logs and shell).

Backing up a database

Mangrove’s own backups cover its settings and secrets, not the data in your databases. Dump them yourself, on a schedule:
Use mysqldump, mongodump or Redis’s BGSAVE for the others. Copy the result off the box.

Good to know

  • Deleting the deployment deletes its data volume. Back it up first.
  • A database’s memory limit counts toward the memory budget like any other deployment.
  • Upgrading a major version (Postgres 16 to 17, say) is the database’s own dump-and-restore process. Mangrove doesn’t automate it.