Guides
Using StoreEnv in CI
What works today, what doesn't, and the safest current setup.
Guides 1 min read
!There are no machine tokens yet. A CI job can't sign in to StoreEnv on its own today, and copying a person's CLI session into CI doesn't work: sessions renew their tokens and each renewal invalidates the previous one, so a copied session stops working after its first renewal (within an hour). Machine tokens for CI are planned.
The safest current setup
Keep using your CI system's own secret store (GitHub Actions, GitLab CI, CircleCI and others), and fill it from StoreEnv on a trusted machine when values change. The values are decrypted on your machine, written to a file for as long as the import takes, then deleted.
$ storeenv pull --env production --stdout > ci.env$ gh secret set -f ci.env --env production # GitHub Actions; use your provider's import$ rm ci.env
- Use a person who has exactly the production access the pipeline needs.
- pull --stdout is recorded in the project's activity log, so the sync is visible.
- Run it again after every change, or after storeenv revoke tells you which values to rotate.
Risks to know
- Values in a CI secret store are outside StoreEnv: StoreEnv's history, access rules and revocation don't reach them.
- Anyone who can change the pipeline can usually read its secrets. Protect the branches and environments that use them.
- Don't put a recovery phrase or a copy of ~/.storeenv in CI. It would give the whole account to every job.
When machine tokens arrive
The pieces CI will need already exist: writers listed in .storeenv.json "writers" (or STOREENV_TRUSTED_KEYS) tell a job whose signed values to accept without asking, and run refuses unsigned values without prompting.