Skip to content
Reoclo Reoclo Reoclo Docs

Secrets Manager quickstart

This walks through the whole lifecycle of a secret in the dashboard: create a project, store a value, read it back, change it, and undo the change. It takes about five minutes and leaves you with a project you can point a pipeline at afterwards.

You need the Developer role or above. Granting other people access needs Admin, which the last step covers.

  1. Open Secrets and create a project

    Click Secrets in the sidebar, then New project.

    Name it after one app in one environment — payments-production rather than secrets or team-stuff. Access is granted per project, so a project is the smallest thing you can hand to a pipeline. One big project means every pipeline reads everything.

    The description is optional and worth writing: it is what a teammate reads before deciding whether to put a secret in here or somewhere else.

  2. Store your first secret

    Open the project. On the Secrets tab, click New secret.

    • Key — the environment variable name your app expects, like DATABASE_URL. Uppercase with underscores; this is the name that gets injected verbatim.
    • Value — the secret itself. Multi-line values such as PEM certificates are fine and round-trip exactly.
    • Note — optional, for the next person: where the value came from, who rotates it.

    Save. The secret appears with Version 1.

  3. Reveal it

    Click the hidden value to reveal it.

    Two things just happened. The value re-hides itself after 30 seconds, and the reveal was written to the audit log before it was shown to you — so a read is recorded even if you never actually see it.

    That is the point: revealing is for a person who genuinely needs to look. Pipelines should never do this. They use reoclo run, which injects the value without exposing it.

  4. Change the value, then undo it

    Edit the secret and save a different value. It becomes Version 2 — the first version is not gone.

    Now open the secret’s version history and roll back to version 1.

    Rolling back does not delete version 2. It writes version 1’s value forward as a new current version, so the record of what happened stays intact. This is the recovery path when a rotation goes wrong at 2am: you are picking a known-good value, not restoring a backup.

  5. Check the trail

    Open the Activity tab.

    Everything you just did is there: the project created, the secret written, the reveal, the rollback. When a pipeline starts resolving this project, its reads land here too — listing the key names it received, never the values.

  6. Grant someone access

    Open the Access tab and click to add a grant. This step needs the Admin role.

    Pick a principal:

    • a user, for one person
    • a role like Developer, for everyone at that level and above
    • an Automation key, for a pipeline

    Human grants are read-only, and that is deliberate: developers can already manage secrets through their role, so a grant only settles whether they may see the values.

    A principal with no grant sees nothing in this project. There is no global access.

What you have now

Section titled “What you have now”

A project with a versioned secret, a full audit trail, and access you control per principal. Nothing here required anyone to paste a value into Slack.

The natural next move is to stop handling the value by hand entirely — either by injecting it into a pipeline or by referencing it from an application’s environment.

Doing this from the terminal

Section titled “Doing this from the terminal”

The same lifecycle works from the CLI:

Terminal window
reoclo secrets projects ls
reoclo secrets set DATABASE_URL --project payments-production --from-file url.txt
reoclo secrets ls  --project payments-production
reoclo secrets get DATABASE_URL --project payments-production

Prefer --from-file or stdin over --value, which leaves the secret in your shell history and in the process table. See reoclo secrets.

Next Steps

Section titled “Next Steps”