What problem will this feature address?
Secrets Providers let you reference an external vault using ${{vault.<provider>.<ref>}} syntax. Per the docs, this works in every environment-variable editor: service env vars (including on databases), project-level shared variables, environment-level shared variables, and build args.
However, the root "password" (and other) field set when creating/managing a Postgres, MySQL, MariaDB, MongoDB, or Redis database (the "General" tab) does not appear to go through the same interpolation path, it looks like a plain, directly-stored credential field, separate from the environment-variable editor component.
This means the actual database password can't be vault-managed the same way application secrets can. To keep them in sync, you have to manually copy the vault value into that field (and again whenever it rotates).
Describe the solution you'd like
Allow the database's "password" (and ideally "user", and why not others) field to accept ${{vault.<provider>.<ref>}} references, resolved at deploy/container-creation time the same way service environment variables are - so the actual database credential can be sourced from and stay in sync with the vault.
Describe alternatives you've considered
- Manually setting the DB password to match a vault value, then referencing the vault only in consuming services' env vars
- Deploying the database via Docker Compose instead of Dokploy's "managed" database type
Additional context
Will you send a PR to implement it?
Yes
What problem will this feature address?
Secrets Providers let you reference an external vault using
${{vault.<provider>.<ref>}}syntax. Per the docs, this works in every environment-variable editor: service env vars (including on databases), project-level shared variables, environment-level shared variables, and build args.However, the root "password" (and other) field set when creating/managing a Postgres, MySQL, MariaDB, MongoDB, or Redis database (the "General" tab) does not appear to go through the same interpolation path, it looks like a plain, directly-stored credential field, separate from the environment-variable editor component.
This means the actual database password can't be vault-managed the same way application secrets can. To keep them in sync, you have to manually copy the vault value into that field (and again whenever it rotates).
Describe the solution you'd like
Allow the database's "password" (and ideally "user", and why not others) field to accept
${{vault.<provider>.<ref>}}references, resolved at deploy/container-creation time the same way service environment variables are - so the actual database credential can be sourced from and stay in sync with the vault.Describe alternatives you've considered
Additional context
show-internal-postgres-credentials.tsx,show-internal-mysql-credentials.tsx, etc.) renders through a plainToggleVisibilityInput, not the environment-variable component - see the diff in #4144 (password-update feature):Will you send a PR to implement it?
Yes