The secret vault

Secrets are encrypted, write-only, and bound to the hosts they may reach. Members use them by name and never see a value.

Add a secret

Admins add secrets per server, on the Secrets tab: a name (A-Z, 0-9, _), a value of at least 8 characters, and the hosts it may be sent to (host or host:port, port 443 when omitted). The value is encrypted with the master key and never shown again, not even to admins.

A spec uses it by name, and may narrow its hosts further, never widen them:

secrets:
  - name: ISSUES_TOKEN
    hosts: [api.issues.example.com]

Where a secret may go

The vault’s binding decides; a spec can only narrow it. Studio checks it three times: when a version is published, when the spec loads, and before every request and every redirect hop. A redirect to a host the secret may not reach is not followed. A secret never travels over plain http.

Rotate, rebind, delete

• Rotate: set a new value. The next call uses it; the old value stays redacted wherever the server saw it.
• Rebind: change the hosts. A narrower binding applies at the next call.
• Delete: if the published version uses the secret, Studio lists the tools that do and asks for confirmation. Afterwards those tools fail with “Secret X is not configured for host:port”, and nothing is sent.

Every change is in the audit log, with names and hosts, never values.