Skip to content
Outry

Secrets

Secrets never go into env.toml — sooner or later someone commits a token. Instead, Outry reads them from the operating system’s password storage.

Locally: the system keychain

Section titled “Locally: the system keychain”
Terminal window
outry secret set token --env dev     # reads the value from stdin
outry secret rm token --env dev
GET /me {
  headers { Authorization: "Bearer ${token}" }
}

When token is not defined anywhere else, Outry looks it up in:

  • macOS — Keychain;
  • Windows — Credential Manager;
  • Linux — Secret Service (GNOME Keyring, KWallet, KeePassXC).

Secrets are stored per project and environment, under the service outry with the key <project>/<env>/<name>. The project name is project from env.toml, or the name of the project folder (the parent folder if it is called api).

In the desktop app use Add secret at the bottom of the sidebar — it saves to the same place.

Declaring secrets

Section titled “Declaring secrets”

List the names of secrets in env.toml — only the names, never the values:

api/env.toml
secrets = ["token", "api_key"]

Then outry vars and the Variables tab in the app show which secrets are missing for the current environment, and the editor suggests them. Secret values are masked in both places.

In CI: environment variables

Section titled “In CI: environment variables”

There is no keychain on CI runners. Pass secrets as OUTRY_<NAME> environment variables — they take precedence over env.toml and the keychain:

- run: outry run api --env staging --no-keyring
  env:
    OUTRY_TOKEN: ${{ secrets.API_TOKEN }}

--no-keyring skips the keychain lookup entirely. Without it Outry also works on headless machines: if no secret storage is available, it simply treats the secret as missing.