Secrets Manager
Secrets Manager is a place to keep the values your applications need but your git history should never see — database URLs, API keys, signing certificates. It stores them encrypted, keeps every version, records who read what, and hands them to your applications and pipelines without a human ever copying and pasting one.
If you are keeping secrets in 1Password or Bitwarden today, you do not have to move everything at once: you can import them in one shot, or keep them in sync.
How it fits together
Section titled “How it fits together”A secret project is a named container — usually one per app per environment, like payments-production. Inside it, each secret is a key and a value.
Every write creates a new version rather than overwriting. Rolling back is picking an old version, not restoring a backup, and nothing is destroyed on the way.
Grants control who and what can read a project. A grant names a principal — a person, a role, an automation key, or an application — and gives it read on one project. Access is per project, never global, and a principal with no grant sees nothing.
Three things consume secrets, and none of them require a human to handle a value:
| Consumer | How it reads | Guide |
|---|---|---|
| A pipeline | reoclo run injects values into a command | Injecting secrets into CI |
| An application | environment variables reference a secret, resolved at deploy | Environment variable references |
| A person | Reveal in the dashboard, or reoclo secrets get | Quickstart |
Who can do what
Section titled “Who can do what”Two levels of permission, mapped to your existing roles:
| Action | Required role |
|---|---|
| Create projects; create, edit, and roll back secrets; reveal values you are granted | Developer |
| Grant and revoke access to a project | Admin |
Developers manage secrets; admins decide who else can see them. A developer cannot widen access.
Revealing is deliberately awkward, because it should be. A revealed value hides itself again after 30 seconds, and the reveal is written to the audit log before the value is returned to you — so a read is recorded even if the response never arrives.
Granting access
Section titled “Granting access”Grants are added from a project’s Access tab, and the principal type decides what you are authorizing.
People and roles. Grant a specific user or a whole tenant_role. Role grants are inclusive of the roles above them: granting developer also covers admins and owners, so you do not have to grant each level separately. Human grants are read-only by design — developers can already manage secrets through their role; a grant only settles whether they may see the values.
Automation keys. Grant an automation_api_key to let a pipeline resolve the project with reoclo run. This is the only thing that matters for CI access: a key locked down to no servers and no operations still resolves secrets if it holds a grant, which is exactly what makes a dedicated, otherwise-powerless CI key safe.
Applications. You do not create these by hand. When an app’s environment references a secret, the grant is reconciled for you and removed when the reference goes away. See Environment variable references.
How values are protected
Section titled “How values are protected”Values are encrypted at rest with AES-256-GCM envelope encryption; each secret is sealed with its own key. Decryption happens behind a single internal boundary, so the number of places a plaintext value can exist is small and auditable.
The read paths are built to fail closed. Resolution that cannot be authorized does not fall back to an empty value — reoclo run refuses to start your command, and a deploy whose references cannot be resolved fails rather than launching a container with variables silently missing.
Two behaviours are worth knowing because they are load-bearing:
- A denied project and a nonexistent one look identical. Both report that no accessible project matched. A key cannot be used to discover which projects exist.
- Injected values are not masked by your CI provider. Platforms only mask strings you registered with them. A value that arrives from Reoclo is unknown to them, so anything that prints one puts it in the log in the clear.
Audit trail
Section titled “Audit trail”Every meaningful action is recorded: projects created, secrets written and rolled back, grants added and removed, values revealed, and every resolve a pipeline performs. Resolve entries list the key names that were handed over, never the values, and carry the workflow run and commit when a CI system supplies them.
The Activity tab on a project shows its history; the org-wide audit log shows everything.
Next Steps
Section titled “Next Steps”- Quickstart — create a project and your first secret
- Injecting secrets into CI — hand secrets to a pipeline
- Environment variable references — wire a secret into an application
- Importing and syncing secrets — bring in 1Password or Bitwarden
reoclo secrets— manage secrets from the command line