Skip to main content
Nerdit runs managed Postgres and Redis as supervised database services. It creates credentials and persistent storage, then injects connection URLs into applications that declare a binding. External databases can use the same binding pattern.

Create and bind a database

Wait for readiness before deploying an application that depends on the database. No password is printed.
nerdit.toml
The database name is required and must match an existing managed database. Deploy or restart the application after changing bindings:
The cache binding above provides NERDIT_DB_CACHE_URL; it does not become REDIS_URL because it is not named default.

Connect an external database

nerdit.toml
Use your actual password-free connection URL and a secret reference. The database must be reachable from the application container. Its availability, TLS policy, backups, and migrations remain your responsibility.

Credentials and network boundaries

Managed passwords are minted by the Engine and stored encrypted. List and diagnostic responses show password-free endpoints or secret names; complete credentials are injected only into bound applications.
Bound containers receive their database URL in the environment. A host administrator or someone with Docker access can inspect it. Any container on the default Docker bridge can attempt to connect to managed database ports; passwords provide the database gate. This is not isolation between mutually untrusted tenants.
Managed ports bind to loopback and the Docker bridge gateway, not every host interface. Do not publish them to the LAN as a troubleshooting shortcut. Model and database bindings share the [models].bridge_host reachability setting.

Operate a database

Stopping a database interrupts dependent applications. Check bindings and plan an appropriate maintenance window.

Choose a backup

See backup and recovery for archive custody, offline procedures, and recovery limitations.

Logical dumps and live restore

The following commands are implemented in the current merged source, whose package version is 0.6.0. They are not in the verified latest published release, v0.5.5. Check nerdit db --help; do not expect the installer or nerdit update to provide these commands until a release includes them.
The Engine runs pg_dump or redis-cli --rdb against a ready database. The request blocks during capture. Archives remain on the Engine machine; the API returns metadata, not their contents. If a client times out, list dumps before retrying because the capture may have completed. After stopping applications bound to the target, restore a listed dump basename, not a file path:
The command asks for typed confirmation. This is destructive. PostgreSQL restores the objects in the dump in a single transaction; objects created afterward remain, and conflicting dependencies can fail the transaction. Redis stops and restarts the database to replace its append-only base. A restore refuses active bound applications by default. --force bypasses that guard and can interrupt connections or wait on locks. Restoring to another database of the same engine supports cloning. Restore only trusted database content: PostgreSQL dump contents can execute routines with the managed database’s privileges. There is no MCP restore tool. Logical dump retention defaults to five per database in current source. Set [retention].dump_keep_last and restart to change it; zero disables automatic pruning. Copies outside the Engine’s storage remain your responsibility.

Remove a database

Take and verify a backup first. Database removal requires explicit data purge, and it also destroys the minted credential:
The CLI asks for confirmation. Check and remove dependent bindings first. A database still used by another application or busy with a protected operation can refuse deletion; do not add --force without understanding the interruption and data loss.