PostgreSQL, MariaDB and Redis on your own server

Each runs in a container of its own, with a volume for its files.

A database never gets a public port. Every app is on a network of its own and the firewall drops traffic between them. Linking a database to an app opens one way through, to the database’s one port, so the app reaches it by name. Game servers link the same way, and a game server’s Database tab shows the host, port, user and password for a plugin’s config file.

The password is sealed: the panel stores it but cannot read it. Having it shown needs a second login step from the last 15 minutes, and every time is logged.

• Every night at 3:00, kept for seven days, unless you change it.
• Compressed and encrypted with age before they touch the disk. A recovery file lets another server open them.
• Copies in any S3-compatible storage, kept for 30 days by default.
• A dump from elsewhere (.sql, .sql.gz, a Redis .rdb) can be uploaded to restore it.
• A restore first backs up what is there. If the restore fails, that backup goes back.

When a new patch release of the image is out, the panel offers it and backs up before it switches. Moving to a new major version, such as PostgreSQL 17 to 18, dumps the data, loads it into the new version on a new volume, and goes back to the old one if anything fails. The old volume stays until you delete it.

The Data tab shows tables, rows, filters by column, search, sorting and CSV export, and for Redis, keys and their values. Everything is read-only: the core builds each query itself and runs it in a read-only transaction with a time limit.

Tools like TablePlus or DBeaver connect through an SSH tunnel to a port only the server itself can reach, as a user of their own whose password is shown once.