Secrets Manager

The panel uses OpenBao for vault-backed AI keys, generated service secrets and recoverable customer API/MCP tokens. The panel mediates access through its permissions and customer association. The vault is trusted infrastructure, not a security boundary against a compromised panel or host.

Stored values and legacy mode

With the vault backend available, generated service tokens are materialized into vault entries and references in saved Compose configuration. Existing entries are reused on redeployment; redeploying is not a general-purpose rotation.

Older services, manually entered environment values and legacy AI-key fallback can still use encrypted database columns. A database backup must therefore be treated as sensitive; do not assume it contains no recoverable secret material. AI-key reads can use a legacy encrypted value only when one is available. A vault-only entry cannot be recovered by that fallback during an OpenBao outage.

Customer namespace creation and deletion run as background work. Inspect errors and reconcile failed cleanup rather than assuming it completed with the customer request. Image updates alone do not prove that an older install has the required OpenBao service, configuration and migrations in place.

View and manage secrets

Settings → Security → Secrets shows backend health and migration status. The separate Secrets page offers Services, AI and operator Platform views, subject to secrets.view and secrets.manage. Service Credentials cards expose the allowed generated values with audited reveal controls. A portal view is scoped to its customer and has no operator Platform selector.

A service's secrets are shown and readable only in the scope that owns the service now: its customer, or the operator Platform view for a service with no customer. After a service moves to another customer, the previous owner's Secrets page no longer shows it, even though the vault can still hold old entries for it there. If a move fails part-way, the copy it left in the other customer's vault space can't be listed, revealed or referenced by that customer. A request for a secret of a service you don't own gets the same "not found" answer as one for a service that doesn't exist. This check does not remove the leftover entries; an operator still has to reconcile a failed move.

Use secret references when another service needs a stored value. The reference is resolved at container creation; changing the vault does not change an already running container's environment.

Rotation and recovery

Rotate a Service Secret explains the available rotation classes. PostgreSQL and MySQL classes attempt a database password change; environment-only secrets get a vault update and container recreation. Application accounts not managed by that mechanism need their own procedure.

Rotation can fail after a value changes. If the apply step fails, the worker attempts to write the old value back as a new vault version. That rollback can also fail. A recreation failure can leave containers using an older value. Check the failure stage, actual application access and dependent services before retrying. A version restore uses the same process and failure boundaries.

Host access and backups

A user with root or Docker access on the host can inspect resolved container environments and access the panel's recovery material. Vault encryption does not protect against that level of host compromise. Restrict host access and protect backups together with their required encryption/unseal material.

See Backup and Restore for the service-backup limitations. The repository's docs/runbooks/openbao.md contains the operator procedure. Do not stop OpenBao on the assumption that all features will fall back to legacy storage.