Skip to main content

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.

On the roadmap — target Q4 2026

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 orborbs: envshed: envshed/envshed@1 exposes a single command: envshed/load.
  • One context — store ENVSHED_TOKEN in a CircleCI context that only your deploy jobs can access.
  • Per-job environmentenvshed/load: { environment: production } (or staging, preview) decides which Envshed environment to pull from.
  • Bash and Alpine images — works on the standard cimg/* images and on bare alpine: 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.