v0.13.0 · 15 backends · 508 live-backend assertions

One registry.
Every repo. Every backend.

Multi-backend secrets orchestration via an alias registry that lives in your own backend. No SaaS. No re-encryption. No lock-in. No .env files. Migrate from one backend to another without touching a single repo.

Get started → Read the docs $ brew install secretenv
~/projects/checkout-svc — secretenv run
--registry dev
resolution flow
✓ resolved · fetched in parallel · injected into child process · gone on exit
The problem

Every existing tool assumes it is your only backend.

Your org uses AWS SSM for infra credentials, 1Password for team secrets, and Vault for service tokens. Every developer assembles a slightly different .env from manual fetches. Onboarding takes a day. Offboarding is a checklist nobody fully trusts.

Three backends. One .env per developer. Drift everywhere.

Each repo cobbles its own glue. Paths leak topology. Migration means PRs across every service.

checkout-svc
STRIPE_KEY=op://payments/stripe/api_key
1Password
orders-api
DB_URL=aws ssm get-parameter --name /prod/db/url
AWS SSM
notifier
DD_KEY=vault read -field=key kv/datadog
Vault
…and 23 more
↳ no two of them assemble env the same way
3+
backends per org, on average
1day
onboarding, asking where things live
Nrepos
to touch, every backend migration
The three-file model

Three files. Three owners. Three lifecycles.

SecretEnv separates what every other tool conflates. The manifest tells SecretEnv what is needed. The registry tells where things live. The machine config tells which backends exist on this machine.

Concrete workflows

The day-to-day SecretEnv was built for.

Backend migration

One registry set.
Every repo follows.

Move a secret from 1Password to Vault. Update one line in the registry. Every repo using stripe-key picks it up on its next secretenv run. No PRs. No re-encryption. No coordination.

Repoint the alias

Stripe lives in Vault now. One operation, on the platform team's machine.

$ secretenv registry get stripe-key
stripe-key → 1password-work://payments/stripe/api_key
$ secretenv registry set stripe-key "vault-prod://secret/payments/stripe_key"
✓ updated · effective on next run · 0 PRs · 0 re-encryption
14 repos · same alias · routed to vault
Supported backends

15 backends. One binary. No plugins.

SecretEnv delegates all authentication to each backend's native CLI. You inherit your existing MFA, SSO, biometric unlock — with no new auth surface to audit.

Stability proof

Every backend tool claims stability. SecretEnv proves it.

The smoke harness exercises the real binary against real backend CLIs in real shells — not mocks. 508 assertions across 15 backends as of v0.13.0.

Live-backend assertion growth

If a test doesn't pass, it doesn't ship. Every release exercises every backend, end-to-end, against the live CLI — before the tag is cut.

backends
15
assertions
508
600 450 300 150 0
How SecretEnv compares

Honest tradeoffs. No marketing math.

Property SecretEnv .env fnox direnv
Multi-backend in one invocation ✓ — ✓ manual per-project
Backend migration without editing repos ✓ one registry set n/a edit every config n/a
Infrastructure topology hidden from repos ✓ aliases only ✗ ✓ ✗ paths in .envrc
Centrally-shared mutable alias registry ✓ in your backend — — —
One-line offboarding (single revoke covers all repos) ✓ ✗ depends on mode ✗
Stores no secret material on disk ✓ ✗ depends ✓
No SaaS dependency ✓ ✓ ✓ ✓
Inherits backend MFA / SSO / biometric ✓ native CLI — partial —

Stop assembling .env files.
Start orchestrating.

One binary. Your backends. No SaaS.
Built with frustration at .env files and multiple password managers.