Feature request: Environment-aware KV UX with copy/promote between environments

Is your feature request related to a problem? Please describe.

Application teams often manage the same logical secret across multiple environments, such as dev, staging, prod, preview environments, customer-specific environments, or regional deployments.

Today, when using KV paths to model environments, those values are usually managed as separate secrets or separate paths. For example:

kv/app/dev/DATABASE_URL
kv/app/staging/DATABASE_URL
kv/app/prod/DATABASE_URL

This works technically, but it makes common workflows more cumbersome:

• Users have to navigate between environment paths manually.
• It is harder to see which environments have a value for the same logical key.
• Copying or promoting a secret value between environments is a manual read/write operation.
• The UI does not naturally reflect the way application developers often think about secrets: key first, environment second.
• It is easier to accidentally update the wrong environment or miss an environment entirely.

This is especially noticeable when comparing OpenBao’s UX with tools such as Infisical, where secret keys can be presented as top-level entries and environment-specific values are grouped beneath them.

Describe the solution you’d like

I would like OpenBao’s UI and/or KV workflow to support an environment-aware secrets experience.

A possible UX could be:

1. Select a secrets mount or project/application path.
2. View secrets as top-level keys, for example:

DATABASE_URL
REDIS_URL
STRIPE_SECRET_KEY
OPENAI_API_KEY

1. Open a key to see values by environment:

DATABASE_URL
  dev      ********
  staging  ********
  prod     ********

1. Edit the value for a specific environment.
2. Quickly copy or promote a value from one environment to another, for example:

Copy dev → staging
Copy staging → prod

This should respect existing OpenBao ACLs. For example, a user may be able to read from staging but not write to prod, or write to dev but only read from prod.

Copying or promoting values should also be explicit and auditable. Useful safeguards could include:

• Require read permission on the source secret.
• Require create/update permission on the destination secret.
• Show a confirmation step before overwriting an existing destination value.
• Clearly display the source and destination environments.
• Include the copy/promote action in audit logs.
• Optionally support a diff or metadata comparison before overwriting.
• Avoid exposing secret values unless the user already has permission to read them.

Describe alternatives you’ve considered

One alternative is to continue modelling environments manually with path conventions, such as:

secret/{{ app }}/{{ environment }}/{{ key }}

or:

secret/{{ environment }}/{{ app }}/{{ key }}

This works, but the UI still treats these as separate entries rather than related values for the same logical key.

Another option is to build this entirely outside OpenBao using scripts, Terraform/OpenTofu, CI/CD tooling, or a custom internal dashboard. That can solve the workflow for some teams, but it means duplicating functionality that is useful to many application teams and does not improve the default OpenBao UI experience.

A third option would be a first-class environment-aware KV model. However, a UI-level convention over existing KV paths may be enough to solve the main workflow without requiring a new secrets engine.

Explain any additional use-cases

This would be useful for teams that frequently need to promote configuration between environments, for example:

• Copying a known-good value from dev to staging.
• Promoting a rotated credential from staging to prod.
• Comparing whether a key exists across all required environments.
• Updating per-customer or per-region values without losing sight of the logical key.
• Managing preview or ephemeral environments alongside long-lived environments.
• Helping developers understand which environments have values for a given application secret.

It would also make OpenBao easier to evaluate against developer-focused secrets tools such as Infisical, where the environment-aware, key-centric UX is a major part of the day-to-day workflow.

Additional context

This is not intended to be a full namespace, cluster, or storage migration feature.

The closest related issue I found was #1569, which discusses cross-cluster namespace transfer. That appears to be focused on storage-level namespace transfer and migration, rather than day-to-day environment-aware KV management.

#1364 may also be relevant because it discusses Web UI modernization and prioritizing core secret/key management workflows.