A vault groups the secrets of one application or one domain: web, billing, infra. Each vault belongs to an organization and is encrypted under one key from the organization's key registry.

Inside a vault, environments separate the values of the same secret for each stage: production, staging, development. A new vault starts with a default environment, and you add others from the vault's Environments page. A secret named DATABASE_URL can then hold a different value in each environment.

Creating a vault

From the Vaults page, pick New vault and give it a name and a slug. The slug is how tools address the vault, in a token, a manifest or a CLI call, so keep it short and stable. Under Encryption key, keep the default to get a key for this vault alone, or pick a key from the registry to share it with other vaults.

Secrets and versions

Writing a secret never overwrites it. Each write creates a new version, and the previous ones stay readable from the secret's page, so a bad value can be rolled back by restoring an earlier version. Deleting a secret keeps its versions.

Every read of a value is recorded in the vault's audit log, together with version reads, restores, deletions and changes to the vault itself.

Sharing a vault

Access is granted per vault, to members of the organization, with one of three roles:

Role	Can
viewer	List secrets and read their values.
writer	Everything a viewer can, plus create, rotate and delete secrets.
admin	Everything a writer can, plus manage people, environments, tokens and the vault's encryption key.

Machines do not get a member role. They use a service-account token, bound to one environment of one vault.