Database-Eggs.
GitHub
Database-Eggs Docs · Egg PTDL_v2

Install an egg

The Multi Database egg deploys any of 50+ engines from one JSON definition and one Docker image. Works on Pterodactyl, Jexactyl, Pelican, Feather, Wisp and plain Docker.

Requirements

  • Any panel running a Wings-family daemon (Pterodactyl 1.x, Pelican, Feather, Wisp) or a plain Docker host.
  • The container image ghcr.io/potenfyr-studios/database-eggs:latest (pulled automatically on first start).
  • One allocated port for the database (the primary allocation).
  • Outbound internet on first boot: engines outside the base image are downloaded, SHA-verified and cached under bin/.

Import the egg

Download the exported egg JSON (egg-database-multi.json) from the repo (exported 2026-08-22):

bash
curl -fsSL https://raw.githubusercontent.com/PotenFYR-Studios/Database-Eggs/master/egg-database-multi.json -o egg-database-multi.json
  • Admin → Nests: create (or pick) a nest, then Import Egg and upload egg-database-multi.json.
  • Keep Associated Docker image = ghcr.io/potenfyr-studios/database-eggs.

Create a server & set variables

Create a server on the egg and allocate its primary port. The two variables that matter first:

startup variables
DATABASE_TYPE=postgresql    # any of the 50 engines (see catalog)
DB_VERSION=18              # latest | 18 | 11.4 | 8.0.45 | https://...

Everything else can stay at its default. The core credential variables (all exported by the egg):

VariableDefaultEditableDescription
DATABASE_TYPEmariadbuserEngine to run (installed isolated inside the container on demand).
DB_VERSIONlatestuserVersion to run. 'latest' auto-resolves upstream newest. Series like 18 or 11.4 resolve to the latest patch automatically; full versions (8.0.45) are used as-is. Switching majors never deletes old data - a fresh data/<engine>/<version> instance is created and the old one is preserved.
STRICT_VERSION1user1 = refuse to start if the exact requested version cannot be provided (no silent downgrades). 0 = warn and fall back to best available binary.
DB_NAMEdatabaseuserThe default database/schema to create on startup.
DB_USERNAMES(empty)userComma-separated database users to create/manage (no limit; e.g. 'alice,bob,carol'). Each user owns their private database '<user>_db' with full rights and also gets access to the shared database below. Adding or removing names applies on the next start: new users are created, removed users are deleted with their credentials (their database is preserved). Invalid/reserved names are skipped with a warning. Leave empty for the legacy single user 'dbuser'.
DB_PASSWORDSautouserComma-separated passwords positionally matched to Database Usernames (e.g. 'S3cretA,S3cretB'). An empty slot generates a fresh random password for that user. Passwords apply exactly once, at user creation: existing users' credentials are never changed by restarts or edits. Generated/stored passwords are recorded in .env and .db-users/credentials (mode 600).
DB_ROOT_PASSWORD(empty)userPassword for Root, Superuser, Admin, or Master Key. Leave EMPTY (or 'auto') to auto-generate an ultra-strong random secret. If you set a password, it is used for the root account and rotates an existing root credential on the next start.

The full list of all 28 exported variables (version switching, git sync, host tuning, console theming) is in the egg catalog.

First boot & credentials

On start the runtime resolves your DB_VERSION, verifies the binary, applies hardware-aware tuning, provisions users, and prints a connection card. With AUTO_GENERATE_CREDENTIALS=1 (default), empty or auto password fields get cryptographically random secrets.

Credentials are persisted to /home/container/.env (mode 600) when SAVE_TO_ENV=1:

.env file
DB_CONNECTION=postgresql
DB_HOST=127.0.0.1
DB_PORT=5432
DB_DATABASE=database
DB_USERNAME=dbuser
DB_PASSWORD="<auto-generated>"
DB_ROOT_PASSWORD="<auto-generated>"
DB_VERSION=18

Inside the server console, db-cli connects with the stored credentials for SQL engines. Set DB_USERNAMES=alice,bob to provision multiple users, each with a private <user>_db database plus access to the shared one.

Updating the egg

  • In-place (self-update): the egg ships with AUTO_UPDATE_EGG=1 and checks EGG_UPDATE_URL (https://raw.githubusercontent.com/PotenFYR-Studios/Database-Eggs/master/egg-database-multi.json) on startup, refreshing the launcher when upstream changed.
  • Panel-side: re-import the updated JSON over the existing egg (Pterodactyl: Nests → egg → Update; Pelican: Eggs → Import). Existing servers pick up new variables on next start; a panel Reinstall refreshes the runtime scripts without touching data/.
  • Version switching (DB_VERSION) never deletes data: each engine/major keeps its own data/<engine>/<series> instance, and ARCHIVE_ON_SWITCH=1 snapshots the old datadir into ./archive/ first.

Troubleshooting

  • logs/startup_error.log: crash reports and environment snapshots.
  • logs/installer.log: download traces and HTTP probe responses when a version fails to resolve.
  • logs/<engine>.log: engine daemon output (e.g. mongod.log, mariadb.log).

Strict version check failed? Check logs/installer.log for the upstream probe result, or set STRICT_VERSION=0 to warn-and-proceed.

Next →
Egg catalog