CircleCI
Inject Envshed secrets into your CircleCI jobs so you stop maintaining the same value in two places — once in CircleCI contexts, once in Envshed.
The first-party CircleCI orb (envshed/envshed) ships in Q4 2026. The CLI workaround below is the same pattern the orb wraps under the hood.
How it will work
- One orb —
orbs: envshed: envshed/envshed@1exposes a single command:envshed/load. - One context — store
ENVSHED_TOKENin a CircleCI context that only your deploy jobs can access. - Per-job environment —
envshed/load: { environment: production }(orstaging,preview) decides which Envshed environment to pull from. - Bash and Alpine images — works on the standard
cimg/*images and on barealpine:images via a static binary.
Workaround today
Use the envshed CLI and a service token directly in your job. The orb will wrap exactly this pattern.
version: 2.1
jobs:
deploy:
docker:
- image: cimg/node:22.0
steps:
- checkout
- run:
name: Install Envshed CLI
command: npm install -g envshed
- run:
name: Deploy with secrets injected
command: envshed run -e production -o my-org -p backend -- ./scripts/deploy.sh
workflows:
ship:
jobs:
- deploy:
context: envshed-deploys
Two things to set up once:
- Create a CircleCI context called
envshed-deploys(or whatever name you prefer) and add a single environment variable:ENVSHED_TOKEN. The CLI reads that automatically. - Use a service token scoped to the environment you are deploying to — the same token can be reused across jobs in the same context.
If you would rather write secrets to a file (for tools that read .env), swap envshed run for envshed pull -e production -f .env --force as the first step.
Want this sooner?
CircleCI sits in the Q4 2026 batch on the public roadmap. If the orb would unblock your team, email hello@envshed.com with a line about which executors you use (cimg, machine, macos) — that drives which executor the orb tests against first.
Related
- GitHub Actions — same idea, GitHub Actions
- GitLab CI — same idea, GitLab
- Service tokens
- Public roadmap