$$$$$$$$ /$$$$$$ /$$ | $$/ /$$ $$ | $$ | $$ /$$$$$$$ /$$ /$$| $$ _/ /$$$$$$ /$$$$$$ | $$ | $$$$$ | $$ $$| $$ /$$/| $$$$$$ /$$__ $$ |____ $$| $$ | $$/ | $$ \ $$ \ $$/$$/ __ $$| $$$$$$$$ /$$$$$$$| $$ | $$ | $$ | $$ \ $$$/ /$$ \ $$| $$/ /$$ $$| $$ | $$$$$$$$| $$ | $$ \ $/ | $$$$$$/| $$$$$$$| $$$$$$$| $$ |/|/ |/ _/ _/ _/ _/|/

Git for secrets. An offline, Git-native secrets manager for environment variables and the files that go with them — TLS certificates, service-account JSON, keystores, kubeconfigs. Built on SSH and Age. Your vault is a file in your repo — encrypted for the people who need it, switched by branch, and mergeable like code.

EnvSeal isn't a cloud secrets manager. It isn't just an encrypted .env file. It's a file in your repository that holds every secret your app needs to start — environment variables and the certificates, service-account JSON, and kubeconfigs that never fit in .env. It travels with git pull, follows your branch, resolves with git merge, and is reviewed in pull requests like everything else you commit.

No cloud. No accounts. No shared master password. Just Git, public keys, and a CLI that stays out of your way.

Secrets aren't always strings. TLS certificates, service-account JSON, .p12 keystores, SSH keys, and kubeconfigs can live in the same vault. At runtime, EnvSeal decrypts each one to a private temporary file and hands your process the path — not a shared drive, not a wiki attachment, not a "temporary" commit from three years ago.

Linux & macOS

curl -sSfL https://raw.githubusercontent.com/viswajith275/EnvSeal-CLI/master/scripts/install.sh | bash

Windows

winget install --id viswajith275.envseal -e

From source

git clone https://github.com/viswajith275/EnvSeal-CLI.git cd EnvSeal-CLI

cargo build --release

Verify:

envseal --version

If the binary isn't found, make sure ~/.local/bin or /usr/local/bin is on your PATH. On most systems the install script handles this automatically.

1. Initialize the vault inside your repo

envseal init --local envseal git-setup

2. Store a secret (prompts without echoing)

envseal set DATABASE_URL

3. Run your app with secrets injected

envseal run -- npm start

4. Commit the vault like any other file

git add .envseal && git commit -m "seal secrets" && git push

That's the entire setup. Once you've added them as a recipient (below), your teammate pulls, runs envseal run -- npm start, and it works — same keys, correct branch, zero DMs.

Already have a .env? Import it in one step:

envseal import .env

the original plaintext file is left for you to delete

Already have a secret that's a file? Seal it the same way:

envseal set TLS_CERT --file ./certs/server.pem --env-var TLS_CERT_PATH envseal run -- node server.js

$TLS_CERT_PATH → a private temp file that disappears when the process exits

--env-var defaults to the key name, so envseal set GCP_SA --file ./gcp.json gives your process $GCP_SA.

Add a teammate — two paths, depending on their setup:

Path A — they have SSH keys on GitHub:

EnvSeal fetches their public SSH keys automatically.

envseal recipient add @their-github-handle

Path B — they don't have SSH keys set up:

They run envseal recipient id, which creates or reuses their local identity key.

They send you the output. You add it manually.

envseal recipient add "age1ql3z7hjy54pw3hy..."

Both work. Path A is one command with zero manual key exchange. Path B is still a single command — you just paste a key instead of a handle.

$ git checkout staging $ envseal run -- npm start

app@1.0.0 start node server.js listening on :3000

No --tag needed: envseal run reads your current Git branch and applies the matching tag (here, staging) before starting the child process.

$ git add . $ git commit -m "wip" [envseal] COMMIT REJECTED: Staged plaintext .env file(s) detected:

• .env [envseal] Use 'envseal run' or encrypt secrets into '.envseal' instead.

Someone leaves the team:

$ envseal recipient rm 1 Removed recipient 'age1...'. Vault re-encrypted.

$ envseal rotate re-encrypting vault and rotating DEK... successfully rotated DEK. All previous tokens are now invalid.

Removing the recipient re-wraps the vault key for everyone else. rotate is the step that changes the data key, so do it immediately — and rotate the real credentials too, because old commits and copied keys are still out there.

$ envseal run -- npm start

app@1.0.0 start node server.js listening on :3000 ^C

Text secrets were injected into the child process's environment; file secrets were temp paths that EnvSeal overwrote and deleted on exit.

Pull only DATABASE_URL from the global vault

envseal run --override DATABASE_URL -- npm start

Overlay everything from the global vault (global wins)

envseal run --with-global -- npm start

Use a specific global group and tag

envseal run --with-global --global-group shared-aws --global-tag prod -- ./deploy.sh

Bulk editing secrets in your editor:

Open the base secrets for the current group in $EDITOR

envseal edit

Edit a specific tag

envseal edit --tag staging

Edit a specific group in the global vault

envseal edit --group myapp

The edit command decrypts the selected secrets into a temporary file, opens it in your default editor, and writes only the net changes back into the encrypted vault. The temporary file is overwritten with zeros and deleted on exit. This is ideal for bulk updates or when you prefer a native editor over repeated set/rm commands.

A certificate that never touches a shared folder:

$ envseal set KUBECONFIG --file ~/.kube/prod.yaml --env-var KUBECONFIG sealed file 'KUBECONFIG' in group 'project' (local seal)

$ envseal run -- kubectl get pods

KUBECONFIG points at a private temp copy, overwritten and deleted when kubectl exits

No USB stick. No "download this from the wiki." No plaintext kubeconfig sitting in a synced folder with production cluster access.

SOPS encrypts files. It's a great tool for a different job: encrypting config at rest. What it doesn't give you is a branch-aware, Git-native workflow or a merge driver. It can inject secrets with sops exec-env / exec-file, but you wire that workflow yourself. Every new teammate means a manual age key exchange and a sops updatekeys run.

dotenvx encrypts your .env file and lets you commit it safely. It's a solid tool with real encryption, rotation, and git-diff audit. The difference is architectural: dotenvx uses a single shared private key per environment, so "who has access" is the same question as "who has the key." It also stops at environment strings — a certificate or kubeconfig still has to live somewhere else. EnvSeal seals the vault to individual recipients and handles both, so adding a teammate is a Git commit and removing one is a commit plus envseal rotate — not a key redistribution.

Doppler / Infisical are excellent products. They're primarily cloud services with dashboards, audit logs, and per-seat pricing (both offer self-hosting, with supported/air-gapped deployments on paid tiers). If your team needs those things, use them. Infisical's MIT-licensed core is free to self-host; supported air-gapped deployments are an Enterprise offering.

EnvSeal is for the team in between: small, already on Git, tired of being the unofficial IT department, and still passing certificates around because they don't fit in a .env.

If you've built anything with more than one contributor, one of these has happened to you:

"Wait, it works on my machine." Someone adds a new API key to their local .env, gets the feature working, and pushes the code. Nobody else has that key. The app breaks for everyone else, and you spend the next hour in a group chat asking "does anyone know what PAYMENT_API_KEY is supposed to be?"

The .env file that never gets shared. .env is gitignored for good reason, but that also means it never reaches your teammates automatically. So it gets passed around as a WhatsApp message, a Discord DM, or a copy-pasted block in a shared Google Doc — sitting there in plaintext, forever, in someone's chat history.

Wrong branch, wrong database. You switch from main to a staging or experiment branch to test something, but your .env doesn't know that. You're now running experimental code against production data, or worse, testing against a database that doesn't have the tables your new branch expects.

The 2 AM git add .. It's late, the deadline is tomorrow, and git add . scoops up a .env file along with everything else. Now there's a real API key sitting in your Git history — and if the repo is public, bots are already scanning for it.

The secret that isn't a string. Your TLS certificate, service-account JSON, SSH key, and kubeconfig don't fit in .env, so they live in a shared drive, a wiki attachment, or a synced folder with production access. Someone rotates one and the next person spends an afternoon discovering the app was reading a stale copy. .env was never designed for files — so the files quietly became everyone's problem.

None of these are exotic. They're what happens when secrets live outside version control and the code that needs them doesn't. The fix isn't a better .env file. It's putting the vault somewhere Git already knows how to move.

EnvSeal keeps secrets inside your repository, but encrypted — so Git can do what Git is good at (syncing state across a team) without ever exposing plaintext.

In short: EnvSeal is what happens when you get tired of being the unofficial IT department for your own group project.

Bonus: Because the vault is just a file in the repo, your secrets inherit all the normal Git workflows you already use — pull requests, code review, git blame, and history. You can see when a secret was added or changed without ever seeing the value itself.

Git-native branch binding

envseal run checks git rev-parse --abbrev-ref HEAD behind the scenes. If a stored tag matches your current branch name, it's applied automatically:

git checkout feature/stripe-v2 envseal set --tag feature/stripe-v2 STRIPE_SECRET envseal run -- cargo test # this branch's secret + falls back to base

Frictionless onboarding

New contributor joins the project? They run:

envseal recipient id

...send you the output, you run envseal recipient add, and they're in. No re-typing shared passwords into a dozen laptops.

If their GitHub account has SSH keys, you can skip the key exchange entirely:

envseal recipient add @their-github-handle

Scoped tokens for CI/CD

Never paste your personal SSH or Age key into a CI runner. Mint a short-lived, narrowly scoped token instead:

envseal token --tag prod -o ./ci.token --exp 3600 STRIPE_SECRET DATABASE_URL envseal run --token ./ci.token -- npm run migrate

Tokens scope file secrets the same way: list TLS_CERT in the token and the runner can read that file key, nothing else. You can also pass the token string (or a path to it) through the ENVSEAL_TOKEN environment variable.

Group member leaves the project, or a laptop gets compromised? Rotate the encryption key and every previously issued token can no longer decrypt the current vault:

envseal rotate

Pre-commit shield

envseal git-setup installs a hook that blocks staged .env files — .env itself and variants like .env.local and .env.staging — while letting .env.example / .sample / .template / .dist and the encrypted .envseal file through.

Need separate vaults for different environments without relying only on branch tags? Use -e / --env:

envseal -e staging set DATABASE_URL envseal -e prod run -- npm start

targets .staging.envseal / .prod.envseal

Global vault override

Mix secrets from your system-wide global vault into a local project at runtime. These flags are available on run, load, and export.

Pull only the named keys from the global vault

envseal run --override DATABASE_URL,STRIPE_KEY -- npm start

Overlay all keys from the global vault (global takes precedence)

envseal run --with-global -- npm start

Specify whic