Skip to main content

​
Secret vaults

Secret vaults organize sensitive workspace configuration without embedding values in product definitions. The API calls the container a namespace; the dashboard presents it as a Secret Vault.

​
Resource hierarchy

Vault and secret operations are scoped by org_id and workspace_id. Permissions can apply to the namespace collection or a specific namespace instance.
  1. Create a vault for one application, environment, or responsibility boundary.
  2. Grant only the identities that must manage or reference it.
  3. Create a secret with a descriptive name and purpose.
  4. Select the resulting secret reference from a VegaFlow connection form.
  5. Update or rotate the secret without copying its value into the QuickFlow definition.

​
Safety rules

  • Never place secret values in documentation, screenshots, Git, logs, issue comments, or connection descriptions.
  • Prefer a secret reference over pasting a credential into another resource.
  • Separate read/use access from secret-management access where permissions allow it.
  • Remove unused secrets and permissions after consumers migrate.
  • Treat IDs and metadata as sensitive when they reveal infrastructure structure.

​
Permissions

Collection permissions govern listing and creating vaults. Instance permissions govern access to a particular vault. A connection form may show only vaults and secrets visible to the current identity. If a reference selector is empty, verify organization/workspace scope, vault permission, and whether a secret exists before recreating anything.