Databases and provisioning

Database provisioning is part of the deployment runner rather than a separate database dashboard. Source analysis looks for supported dependencies and connection schemes, then records required engines in the project blueprint. The implemented engines are PostgreSQL, MySQL, MongoDB and Redis. During deployment, each detected engine is started as a sibling Docker container on a project-specific network before the application configuration is written. The application receives a server-local connection string through its environment, avoiding a public database port or a manually copied password in the ordinary deployment path.

Let analysis declare the dependency

Connect and analyse the project before deployment. Detection examines package dependencies and environment values for recognised database schemes. The resulting blueprint carries an engine list used by the Provision databases step. The project console does not currently expose a separate engine selector, so the documented procedure depends on the analysed declaration. An agent can also propose provisioning a supported engine after a connection failure and, when accepted by the risk gate, persists that engine into the blueprint for later runs. Unsupported databases and multi-node topologies are not inferred into this provisioning path.

Understand the container boundary

Each engine has a fixed image and internal port in the server implementation: PostgreSQL 16 Alpine on 5432, MySQL 8 on 3306, MongoDB 7 on 27017 and Redis 7 Alpine on 6379. Container, volume and network names are derived from the unique project slug rather than supplied by source or model output. The database is attached to the project's Docker network, and the application Compose file is joined to that external network when databases are present. Connection strings therefore use the database container name as the host, not localhost and not the server's public address.

Credentials belong to one project and server

On first provisioning, Deploy Bridge generates a password, uses the application username and derives a database name from the project slug. It encrypts the stored password and records the database against the project, target server and engine. Deploying the same project to another server provisions a separate database because a container name and volume on one machine cannot serve another. Ready connection details are merged into the application's .env file. PostgreSQL and MySQL provide DATABASE_URL plus component DB_ variables; MongoDB supplies MONGODB_URI, while Redis supplies REDIS_URL.

Named volumes preserve database state

The provisioner creates a named Docker volume and mounts it at the engine's data directory. If the container is already running, it is retained and reconnected to the project network where necessary. If a recorded database container is stopped, the implementation may remove and recreate that container with the same volume and credentials; the volume itself is not removed by that operation. Later runs reuse the stored database record. This is persistence across application redeployments, not a backup or failover claim. The server and its Docker volume remain the only implemented location of that database state.

Read readiness separately from application health

After starting an engine, Deploy Bridge runs its native readiness command until it accepts queries or the provisioning wait expires. The database record becomes ready only after that probe succeeds; otherwise it records an error and the deployment step fails. The Configure step then writes database connection details before the application's first boot. A ready database can still be incompatible with application migrations, schema expectations or driver settings. Those failures appear later in build, start or verification output and must be diagnosed at the application boundary rather than by recreating a volume that may hold data.

Treat replacement as destructive

The agent risk classifier treats provisioning a new supported engine as safe when that engine does not already exist for the project on the selected server. A proposal to provision an engine that is already recorded is held for approval because replacement could affect stored data. Commands that remove or prune Docker volumes, or bring Compose down with volume deletion, are also classified as destructive. Approval is not a backup. Before approving any change that could replace a database resource, inspect the proposal, establish the state of the named volume and arrange recovery independently of the deployment run.