Stop shipping secrets in .env files.
xecret stores your environment variables once, encrypted per environment, and injects them into whatever you are running — locally, in CI, in production. No file on disk, no credentials in Slack, no “works on my machine”.
Free forever for small teams · see what it costs
$ xecret run -- npm run devHow it works
Sixty seconds, start to finish
There is no agent to install, no sidecar to run and no IAM policy to write. Three steps, and your application never learns that anything changed.
Create a project
One project per application, with an environment for each stage you deploy to. Every environment gets its own encryption key at the moment it is created.
Import your .env
Drag in the file you already have. Parsing happens in your browser, so a pasted blob of production credentials never becomes a request body.
Run your app
The CLI resolves the environment, decrypts server-side, and injects everything into the process. No .env file on disk, and every read is in the audit log.
Install
Thirty seconds to installed and signed in
One static binary — no Node, no Python, nothing to compile, nothing to keep running. Pick your platform, run the line, and the credential you get back is held by your operating system rather than by a file in your home directory.
The credential lives in the macOS Keychain — never in a dotfile you might commit or sync.
Every path, including checksum verification and upgrades, is in installing the CLI
A secret you cannot audit is a secret you have already lost.
Encryption is the easy half. The half that decides how your next incident goes is knowing exactly who read what, and when — before you need to know it.
What you get
Built for the way you already work
Six things that matter on a Tuesday, not six things that demo well.
A key per environment
Development, staging and production never share a data key. Compromising one environment does not hand over the others.
One command, any stack
xecret run injects the environment and execs your process. Next.js, Node, Vite, Go, Docker, CI — nothing in your code changes.
An append-only audit log
Every read, write and rotation is recorded with who, what and when. It is the record you need before an incident, not after.
Access you can revoke
Members, roles and per-environment access. A leaver loses production the moment you remove them, not the next time somebody rotates.
Works on a plane
The CLI keeps an encrypted offline cache, so a flaky network does not stop you running the app you were already running.
Yours to run
The server is AGPL-3.0 and the CLI is MIT. Self-hosting is a documented path with nothing held back behind it.
What xecret can and cannot see
xecret uses server-side envelope encryption. Every environment has its own data key, which is itself encrypted under a root key we hold; values are decrypted only inside a single request handler, and every decryption is written to an append-only audit log.
What we can see
- Encrypted secret values, which we can technically decrypt — the root key is ours
- Secret names, project names, environment names and organisation names, unencrypted
- Your email address and the identity provider you signed in with
- Every read, write and rotation, in the audit log, with who and when
What we never receive
- Your source code — xecret never sees a repository
- The contents of the .env file you imported, before you imported it: parsing happens in your browser
- Your PIN, which unlocks the dashboard locally and is never sent to us
- Anything at all, on a self-hosted deployment — that database is yours
That means we can technically decrypt your secrets — it is the same model Doppler uses, and it is what makes team sharing, CI tokens and browser-side import work without a key-exchange ceremony. If you need a provider that cannot read your secrets even in principle, you need a zero-knowledge product, and we would rather you knew that now than after migrating.
Open source
Read it before you trust it
The crypto you are relying on is reviewable by anyone, and the binary that ships inside your Docker images carries a licence your legal team has already approved.
AGPL server, MIT CLI
The threat model, the key-recovery ceremony and every architecture decision are documents in the repository, not blog-post promises. The CLI is MIT precisely because it ends up inside your images and pipelines, where a copyleft licence would be a question nobody wants to answer.
Run it yourself
Cloudflare Workers, a Neon or vanilla PostgreSQL database, and your own WorkOS account for identity. The self-hosting guide states the real dependency list plainly — including the parts that are friction — because an open-source secrets manager that hides its operational cost is not being honest about the one thing it sells.
Questions
The things people ask first
Short answers to the six that come up before anybody signs up.
Can xecret read my secrets?
Technically, yes. xecret uses server-side envelope encryption: every environment has its own data key, encrypted under a root key we hold, and values are decrypted inside a single request handler. That is the same model Doppler uses, and it is what makes team sharing, CI tokens and browser-side import work without a key-exchange ceremony. If you need a provider that cannot read your secrets even in principle, you need a zero-knowledge product, and we would rather you knew that now than after migrating.
Do I have to change my application code?
No. The CLI resolves the environment, decrypts it, and injects the variables into the process it starts — your code carries on reading process.env, os.Getenv or whatever it already used. The only file that changes is .xecret.yaml, which holds slugs rather than secrets and is meant to be committed.
What happens if xecret is down when I need to deploy?
The CLI keeps an encrypted offline cache of the environments you have already resolved, so a local run keeps working. For a deploy, the honest answer for a pre-alpha product is to hold a break-glass copy of your production credentials somewhere you control, and to treat any single provider — us included — as something that can fail.
Is it really open source, or is the useful half proprietary?
The server is AGPL-3.0 and the CLI is MIT, and self-hosting is a documented first-class path. No feature is held back from a self-hosted deployment. What a paid plan buys on the hosted service is capacity and support, not capability.
What does it cost?
The free tier is free forever: one organisation, five projects, three members, three environments per project, and seven days of audit history. Pro is $5 per member per month billed yearly — $8 month to month — for three organisations, twenty-five projects, ten environments per project, unlimited members and thirty days of history. Team is $12 billed yearly, or $19 month to month, and adds ten organisations, a hundred projects, twenty-five environments per project, a hundred and eighty days of history, roles and per-environment access, and priority support. Enterprise is custom and drops the ceilings; SAML single sign-on is a $199 per connection per month add-on from Team, and is included with Enterprise; directory sync (SCIM) is included with Enterprise and not sold below it. Neither is built yet. Self-hosting is free and unlimited. While xecret is in pre-alpha no card is collected, and each plan’s limits apply now.
Is xecret ready for production?
It is pre-alpha. The encryption, the audit log, the CLI and self-hosting all work today, but the API surface can still change and there is no SLA. Use it for a side project or a new service; do not migrate a payments system to it this week.
Forty more, including the ones about billing, rotation and what a departing employee can still reach, are on the full FAQ page.
Get your secrets out of version control.
Create a project, import the .env file you already have, and run your app through the CLI. It takes about a minute, and the free tier does not ask for a card.
No credit card · AGPL-3.0 server · MIT CLI · Self-host it for free