Environment variables and secrets

Environment configuration begins in the analysed blueprint, not in a separate secrets screen. Source analysis identifies environment keys from the project and produces an .env template together with structured variable metadata. The project page exposes the template as an editable text file. During deployment, Deploy Bridge resolves platform values, saved template entries, agent-supplied values and provisioned database connection details, then writes .env beside docker-compose.yml in the remote project directory. The deployment log reports variable names or a count where appropriate; it is not intended to print generated credential values as ordinary build output.

Use the template as a controlled input

Open a project after analysis and select the .env Template tab under Deployment Blueprint. The parser recognises non-empty, non-comment lines containing a key followed by an equals sign. The key is the text before the first equals sign and the remaining text is its value. Blank lines and comments do not become environment variables. The editor saves the complete template with the other blueprint files. There is no documented interpolation language or separate configuration-file format beyond these saved KEY=value lines, so values should be entered in the literal form expected by the application and Compose configuration.

Understand precedence before overriding values

The runner begins with APP_NAME, derived from the project name and identifier, and HOST_PORT, the stable loopback port assigned to that project. It then merges the parsed template and any structured values held by the blueprint. Finally, ready databases provisioned for the project on the target server contribute their connection strings. Database-derived values take precedence because only the provisioner has the current generated password and container address. For PostgreSQL and MySQL, the environment also receives DB_HOST, DB_PORT, DB_NAME, DB_USER and DB_PASSWORD alongside DATABASE_URL. MongoDB and Redis use MONGODB_URI and REDIS_URL respectively.

Distinguish storage from display

Database passwords are generated by the server, encrypted in the Deploy Bridge database and materialised into the remote .env file for the application container. Agent-proposed values whose key resembles a secret, token, key, password or credential are stored in structured blueprint data as secret values. The human-editable template retains only a comment noting that the agent set such a key, preventing the API response and later AI diagnosis context from repeating the value. This behaviour does not claim that every arbitrary template value is a managed secret; a value typed directly into the template remains part of that editable blueprint representation.

Treat agent changes as persistent configuration

When a failed deployment leads the agent to propose a set_env remediation, each key and value is validated. Variable names must be plain identifiers, values may not span lines, and names that configure shells, interpreters, Git, Docker, Compose or build tooling are held for approval rather than accepted as ordinary application settings. Accepted entries are merged into the blueprint and the remote .env file is rewritten. The blueprint is marked as agent-generated, which means the proposed correction survives a retry and later deployment instead of existing only in the process memory of the failed run.

Check configuration at the application boundary

Deploy Bridge writes the resolved .env before Docker Compose builds and starts the application. A successful Configure step proves that the file was written, not that every value is semantically correct for the application. Missing paid API keys, invalid external credentials and application-specific configuration can still cause build or startup failure. The agent is instructed to stop when a required secret has not been supplied rather than invent one. Read the failing step and terminal output, correct the blueprint template where the value is account-controlled, save it, and start another deployment.

Limit the audience of deployment configuration

Project blueprint edits require a team administrator through the API, while project and deployment reads are available to authenticated team members. The remote .env file exists on the account holder's server beside the Compose configuration, so server access remains part of the security boundary. Deploy Bridge encrypts stored Git tokens, SSH credentials, Cloudflare tokens and generated database passwords, but it does not turn an unrestricted server account into a secret-isolation mechanism. Apply ordinary SSH access control and avoid copying environment values into support messages, screenshots or source commits when diagnosing a deployment.