Secrets in CI and on servers

Machines can't sign in with Google or approve with a passkey. They get one of three credentials, all made on a project's Machines tab:

Credential	For	Stored where the job runs
Workload identity	GitHub Actions jobs, Kubernetes pods, External Secrets Operator	Nothing: the job's own identity gets a token of one hour
Machine token	Anything else that reads or changes a protected environment	A `sig_` token, for 90 days at most
API token	Anything else, for environments that aren't protected	A `sig_` token, for 7 to 365 days

Prefer workload identity where the platform offers it. Otherwise, make one token per machine or pipeline, scoped to the environments it needs.

API tokens

On the project's Machines tab, click Create token, name it, pick the environments it may use (or all of them), and how long it lasts: 7, 30, 90 or 365 days. The token is shown once; copy it then. Sigillo keeps only its SHA-256 hash.

A token belongs to one project, and optionally only some of its environments. It can't read or change a protected environment: that takes a machine token.
It acts for the person who made it. It stops working when they can no longer sign in or open its project, and for an admin-only environment when they are no longer an org admin.
Anyone who can open a project's environments can create tokens for them. Once you have a passkey, creating one takes it, since a token outlives the session that made it.
The Machines tab shows when and from which IP each token was last used, to the hour. An expired token gets 401 API token expired.
Only a token's creator or an org admin deletes it. Tokens made before expiry existed never expire and show Never: regenerate them to give them one.

Machine tokens

CI and servers can't use a passkey. For them, an org admin creates a token on the Machines tab with Machine token checked. Making it takes the admin's passkey, also before the organization has a protected environment, so a stolen admin session can't leave one behind that reads environments protected later. It expires after 90 days at most, reads and changes protected environments without a passkey, and stops working when its creator is no longer an admin. The Machines tab marks it Machine.

Keep it on the machine it's for, and scope it to the environments it needs: it also reads environments of its scope that are protected after it was made.

Before a token expires

A token warns before it stops working, in the last quarter of its lifetime and at most its last 14 days: the last 42 hours of a 7-day token, the last 14 days of a 90-day one.

The Machines tab marks it, and a banner on the dashboard lists what expires soon: an org admin sees the organization's tokens and trust rules, a member their own tokens.
Every API response to a token says when it expires, and warns inside that window, in two headers: see expiry headers.
The CLI prints one line on stderr, so it shows in the CI log without touching the command's output:

1warning: this API token expires on 2026-10-13 (in 3 days). Regenerate it on the project's Machines tab; the old value then keeps working for up to 7 days.

Regenerate a token

The regenerate button on the Machines tab gives a token a new value and a new expiry. It stays the same token, with its name, scope and history, and it keeps acting for the person who made it.

The old value keeps working for the grace period you pick, none, a day or seven days, but never past the expiry it had, so CI keeps running while you update it. The Machines tab shows when and from which IP the old value was last used, so you can tell whether anything still sends it, and Stop ends it early. Deleting the token ends both. An old value used after its grace gets 401 API token expired: it was regenerated, use the new value.

The token's creator or an org admin regenerates it, with their passkey once they have one; a machine token takes an admin with their passkey, as creating one does, and lasts 90 days at most. A token whose creator can no longer use it can't be regenerated: make a new one.

Use a token

Set it as SIGILLO_TOKEN, with your instance and the project and environment:

12345678- name: Run with secrets
  env:
    SIGILLO_API_URL: ${{ vars.SIGILLO_API_URL }}
    SIGILLO_TOKEN: ${{ secrets.SIGILLO_TOKEN }}
    SIGILLO_PROJECT: ${{ vars.SIGILLO_PROJECT }}
    SIGILLO_ENVIRONMENT: ${{ vars.SIGILLO_ENVIRONMENT }}
  run: |
    npx @kldzj/sigillo run -- next build

On a machine where the token should stay, save it for a directory instead:

1sigillo login --api-url https://secrets.acme.com --token sig_xxx --scope .

Without a stored token

GitHub Actions jobs and Kubernetes pods can skip the token altogether. An org admin adds a trust rule for the repository and its GitHub environment, or for the pod's service account, and the job gets a token of one hour for its own identity:

12345678permissions:
  id-token: write
steps:
  - run: npx @kldzj/sigillo run -- ./deploy.sh
    env:
      SIGILLO_API_URL: ${{ vars.SIGILLO_API_URL }}
      SIGILLO_PROJECT: ${{ vars.SIGILLO_PROJECT }}   # the project's ID
      SIGILLO_ENVIRONMENT: prod

See workload identity for the rules, Kubernetes and External Secrets Operator.