> ## Documentation Index > Fetch the complete documentation index at: https://docs.nerdit.ai/llms.txt > Use this file to discover all available pages before exploring further. # Manage Postgres and Redis > Provision a database, bind an application, and choose an appropriate backup. 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 ```bash theme={null} nerdit db create postgres --name main-db --wait nerdit db create redis --name cache --wait nerdit db list ``` Wait for readiness before deploying an application that depends on the database. No password is printed. ```toml nerdit.toml theme={null} [db.default] provider = "managed" database = "main-db" [db.cache] provider = "managed" database = "cache" ``` The database name is required and must match an existing managed database. Deploy or restart the application after changing bindings: ```bash theme={null} nerdit deploy ./my-app --dry-run nerdit deploy ./my-app --wait ``` | Binding | Application environment | | ------------------------ | ----------------------- | | Any named binding | `NERDIT_DB__URL` | | Default Postgres binding | Also `DATABASE_URL` | | Default Redis binding | Also `REDIS_URL` | 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 ```toml nerdit.toml theme={null} [db.default] provider = "external" url = "postgresql://app@db.example.com:5432/app" password = "${secrets.DB_PASSWORD}" ``` Use your actual password-free connection URL and a [secret reference](/engine/security#application-secrets). 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 ```bash theme={null} nerdit diagnose main-db nerdit logs main-db nerdit services stop main-db nerdit services restart main-db nerdit services wait main-db --timeout 300 ``` Stopping a database interrupts dependent applications. Check bindings and plan an appropriate maintenance window. ## Choose a backup | Need | Operation | Limitation | | -------------------------------------------- | -------------------------------- | --------------------------------------------------------- | | Restore Engine metadata and encryption keys | `nerdit backup` | Does not contain database data. | | Preserve a managed database's data directory | `nerdit backup --volume main-db` | File-level capture; stop the database for a clean copy. | | Obtain an engine-consistent logical capture | `nerdit db dump main-db` | Current merged source only; absent from published v0.5.5. | See [backup and recovery](/engine/backup-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. ```bash theme={null} nerdit db dump main-db nerdit db dumps main-db ``` 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: ```bash theme={null} nerdit db restore main-db DUMP_BASENAME_FROM_LIST ``` 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: ```bash theme={null} nerdit services rm main-db --purge data ``` 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.