A CLI for SOPS · age · Secure Enclave · YubiKey
macOS + Linux ·new in v2.0.0 →

Encrypted secrets you can actually commit to Git.
Decrypt with Touch ID or a YubiKey

Plaintext is never in the repo, never in Slack. Sleep soundly at night.

sopsy encrypts the secrets in your .env, .yml, and .json files — values only, names left in the clear. The file stays diffable and git blame-able, so you can see exactly when each key appeared and who added it, then commit the whole thing without flinching. By default every teammate's key is minted in hardware: their Mac's Secure Enclave, or a YubiKey on Intel Macs and Linux. The repository's policy decides whether the OS keychain is allowed for machines with neither.

Hardware keys decrypt with Touch ID, or a YubiKey PIN and a touch. The private key never leaves the chip, and any current member can grant the next one access. sopsy run hands the secrets straight to your app, with no plaintext file at all. No server. No subscription. No plaintext in Slack — or anywhere for that matter.

$brew install kigster/tap/sopsy

$cargo install sopsy

See the 60-second setup ↓

~/my-app — sopsy

sopsy init bootstrapping your encrypted repository ✔ git repository ✔ tools installed (sopsy deps) > Key stores members may use: onchip, exthardware > Generate a Secure Enclave identity? Yes ✔ created Secure Enclave identity (Touch ID) ℹ private key never leaves the Enclave ➜ public recipient age1se1q2a48h0242huw4… > Your name (key owner): Grace Hopper ✔ .sops.yaml ✔ .env.example ✔ .env.encrypted ✔ .gitignore ✔ .sopsy.yml ✔ .sopsy.sha > Set up a break-glass emergency key? Yes ✔ wrote break-glass.private + .public ⚠ store both offline in 1Password, then continue press ENTER once the keys are saved … ✔ removed local key files ✔ recorded break-glass in both config files ✔ repository bootstrapped

Built on SOPS + age — the encryption tools teams already trust. sopsy just makes them delightful.

crate v2.0.0CI passinglicense MIT / Apache-2.0os macOS · Linux🔑 YubiKeykey never leaves the chip

Quick start

From zero to a whole team in eight steps.

Start (or enter) a git repository
git init my-app && cd my-app
Bootstrap everything
sopsy init — installs missing tools, records a hardware-only key policy, makes your key in the Secure Enclave or on a YubiKey, writes the config files, and sets up the break-glass key.
Put real secrets in
sopsy edit .env.encrypted decrypts to your editor and re-encrypts on save. Or change one value without an editor: sopsy set API_KEY asks for it with hidden input.
Verify hygiene before you commit
sopsy check — the same command your CI runs.
Commit the encrypted artifacts
git add .sops.yaml .sopsy.yml .sopsy.sha .env.example .env.encrypted .gitignore — plaintext .env is already gitignored. Push the ciphertext with confidence.
A teammate joins (self-service)
The new dev clones the repo and runs sopsy join "Alan Turing" — mints their own key in the Secure Enclave or on a YubiKey, within the repository's policy, and records a pending request. They commit and open a PR.
An existing member approves
Any current member runs sopsy approve "Alan Turing" — vouches for the key, promotes it into .sops.yaml, and re-keys every secret. Who approved, and when, is recorded in .sopsy.yml — sopsy recipient list shows the whole audit trail. Now Alan can decrypt.
Run your app with its secrets
sopsy run -- bin/rails server decrypts into that one process's environment. Nothing is written to disk.

Watch the entire process live just below…

Terminal recording of the full sopsy workflow with Secure Enclave keys: init, edit, check, commit, join, and approve

What's new in 2.0.0

Any key store. Fewer prompts. No plaintext on disk.

2.0 lets every member keep their key where it suits them, inside the bounds the repository sets. It adds commands that change one secret or feed secrets straight to a process, and it is honest about what rotating a key does and does not change.

key stores

Four key stores, and a policy for the repo

Your key lives in the Secure Enclave (on-chip), a YubiKey (external hardware), the OS keychain or a plaintext file. init records which stores members may use, hardware only by default, and --store auto picks the strongest one your machine has. Hardware always comes before software, whatever order the list is in.

$sopsy init --allow-stores yubikey,enclave

yubikey

YubiKey, without the friction

sopsy asks you to plug the YubiKey in instead of failing, reminds you to touch it after the PIN, and caches the PIN for the session with -c cached. Making a key without your YubiKey on you? Press e to use the Secure Enclave instead. Several keys fit on one YubiKey; pick one with --yubikey-slot.

$sopsy join "Alan Turing" -s yubikey -c cached -b cached

run

Secrets in a process, not on disk

sopsy run decrypts into the environment of one command and writes nothing to disk. One Touch ID per launch, not one per shell or per worktree. Exit codes and signals are the command's own.

$sopsy run -- bin/rails server

set / unset

Change one value, no editor

sopsy set KEY asks for the value with hidden input, or reads it from stdin, so it never lands in your shell history or a process listing. sopsy unset removes a key. set needs sops 3.11 or newer.

$sopsy set API_KEY

$op read op://dev/api/key | sopsy set API_KEY

rotate

Swap your key, keep your name

sopsy recipient rotate replaces your key under the same name and approval: move to another store or YubiKey slot, or change a PIN or touch policy. It changes who can unwrap the data key, not the data key itself. After a lost or stolen key, add --new-data-key, then change the secret values.

$sopsy recipient rotate -s enclave -t

$sopsy recipient rotate --new-data-key

rotate-data-key

A fresh data key for every file

Removing a recipient re-wraps the data key but keeps it, so anyone who decrypted before still could. sopsy rotate-data-key re-encrypts every managed file under a brand-new data key for the current recipients. Run it after offboarding, then commit.

$sopsy rotate-data-key

deps

Tooling installed for you

sopsy deps installs whatever is missing: sops, age, age-plugin-se, age-plugin-yubikey and ykman. init runs it first (--skip-deps turns it off), and an interactive init sets up the break-glass key by default.

$sopsy deps

$sopsy init --skip-deps

yubikey · enclave

The UX for every tool it wraps

sopsy yubikey and sopsy enclave pass your arguments straight to age-plugin-yubikey and age-plugin-se, so you never need to remember the plugin's name.

$sopsy yubikey --list

$sopsy enclave --help

sopsy does not replace SOPS. It makes SOPS delightful.

sopsy join

Generate

Your keypair is minted in hardware: the Secure Enclave (Touch ID) or a YubiKey (PIN and a touch). The private key never leaves it; your public key is recorded pending in .sopsy.yml.

sopsy approve

Vouch & approve

You open a PR; any active member vouches and promotes your public key from pending into .sops.yaml’s recipient list — recording who approved you, and when, in .sopsy.yml.

sops updatekeys

Re-key secrets

Every encrypted file is re-wrapped for the new recipient set — so your key, and only listed keys, can open them.

sopsy edit

Edit & commit

git pull, then your key decrypts into your editor and re-encrypts on save. Commit the ciphertext; plaintext .env stays gitignored.

SOPS stays the encryption engine. age stays the cryptography. Your Secure Enclave or YubiKey holds the private key.

sopsy orchestrates all three with safe defaults, great diagnostics, and a scriptable interface — so the right thing is finally the easy thing.

Why not just use sops?

You already can. sopsy removes the sixteen ways you can get it wrong.

Everything here runs sops + age under the hood. The difference is the friction — the steps you have to remember, the flags you have to know, and the safety rails that aren't there until you build them.

Task

raw sops + age

with sopsy

Bootstrap a repo

✕Hand-write .sops.yaml creation_rules, craft .gitignore rules, build .env.example, then encrypt by hand.

→One idempotent command writes every file and seeds an encrypted .env.encrypted for you.

sopsy init

Get a hardware identity

✕Run age-plugin-se keygen or age-plugin-yubikey --generate, copy the public key, paste it into config without fat-fingering it.

→The key is made in the best allowed store your machine has (Secure Enclave, YubiKey, keychain), printed prominently, and recorded in config automatically.

sopsy init

Onboard a teammate

✕Hand-edit .sops.yaml, run sops updatekeys on every file — and just trust on faith that the key really belongs to them.

→The newcomer joins to record a pending request (no access yet); any active member approves — vouching for the key, promoting it, and re-keying every secret in one step.

sopsy join → sopsy approve

Audit who has access

✕git blame .sops.yaml and hope the commit history tells the story of who let whom in.

→Every member carries requested_at, approved_at, and approved_by — one command prints the whole audit trail as a table.

sopsy recipient list

Offboard a teammate

✕Hand-edit .sops.yaml, run updatekeys on each file, and miss that the data key never changed.

→recipient remove re-wraps every file for the remaining members. The data key stays the same, so rotate-data-key re-encrypts under a new one. Then change the secret values: old ciphertext in git history still opens.

sopsy recipient remove → sopsy rotate-data-key

Swap your own key

✕Generate a new key, add it, remove the old one, re-key every file, and redo your approval by hand.

→One command swaps your key under the same name and approval, and re-wraps every secret. --new-data-key also re-encrypts under a fresh data key.

sopsy recipient rotate

Edit an encrypted file

✕Pass --input-type/--output-type yourself — .env.encrypted has no extension sops recognizes.

→File type is auto-detected (dotenv / yaml / json / binary); your $EDITOR just opens.

sopsy edit

Change one secret

✕Decrypt the whole file into an editor, find the line, retype the value, and hope nothing else changed.

→Asks for the value with hidden input, or reads it from stdin, so it never lands in shell history. unset removes one.

sopsy set API_KEY

Run an app with secrets

✕Decrypt to a plaintext .env and remember to delete it, or wire up sops exec-env yourself.

→Decrypts into one command's environment and writes nothing to disk. Several files merge; later ones win.

sopsy run -- bin/dev

Encrypt a file in one shot

✕Call sops --encrypt with the right --input-type, then redirect the output yourself and hope the artifact matches a creation rule.

→sopsy encrypt writes a .encrypted artifact, auto-detecting the format — .env, json, yaml, ini — all encrypt values only; anything else as one blob.

sopsy encrypt [file] -o file.encrypted

Decrypt to stdout or a file

✕sops --decrypt with manual type flags, then redirect — easy to clobber the wrong file or leak plaintext to disk.

→sopsy decrypt prints plaintext to stdout or writes it with -o file.

sopsy decrypt file.encrypted [-o file]

Know what's value-encryptable

✕Dig through docs to learn which formats support partial, values-only encryption versus whole-file.

→sopsy types prints exactly which extensions value-encrypt (.env / .yaml / .json / .ini); everything else is encrypted as a single binary blob.

sopsy types

Guard CI against leaks

✕Roll your own grep for tracked plaintext and hope it catches every case.

→Seven hygiene invariants, a clear pass/fail checklist, and a non-zero exit on any violation.

sopsy check

Give CI decryption access

✕Generate an age key on a laptop, paste the private half around, hand-edit .sops.yaml, and remember to delete the local copies.

→A guided ceremony provisions a portable key, waits while you store one CI secret (SOPS_AGE_KEY), then deletes the local files and re-keys. A Linux runner with only sops installed can decrypt.

sopsy recipient ci

Diagnose a broken setup

✕Dig through $PATH, tool versions, Enclave and YubiKey status by hand.

→A grouped, colorful report you can paste straight into a GitHub issue, including which key store auto would use. sopsy deps installs whatever is missing.

sopsy doctor → sopsy deps

Stay disaster-proof

✕Nothing reminds you to keep an offline recovery key. Lose the device, lose the secrets.

→One guided ceremony generates a portable emergency key, waits while you store it offline, then deletes the local copy and registers it — and doctor and check nag until it exists.

sopsy recipient break-glass

●Net effect: the same battle-tested crypto, minus the foot-guns — every interactive prompt also has a flag, so a human at a terminal and an unattended CI job run the exact same tool.

What's in the box

Safe defaults, sharp diagnostics, zero ceremony.

hardware

Hardware-backed identities

Your private key is generated inside hardware and cannot be read, copied, or exfiltrated: the Secure Enclave of an Apple Silicon Mac (Touch ID), or a YubiKey PIV slot (PIN and a touch) on Intel Macs and Linux. Only the public recipient is ever shared.

init

One-command bootstrap

sopsy init installs missing tools, then writes .sops.yaml, .env.example, an encrypted .env.encrypted, .gitignore safety rules, and .sopsy.yml, and sets up the break-glass key. Idempotent — re-running is always safe.

stores

Key stores & repo policy

Four stores, strongest first: enclave, yubikey, keychain (macOS Keychain or Linux Secret Service), and a plaintext file as a last resort. --store auto picks the best one your machine has; sopsy init --allow-stores decides which ones members may use, hardware only by default. Hardware always beats software, whatever order the list is in.

diagnostics

doctor health checks

macOS, Apple Silicon, Secure Enclave, Touch ID, YubiKey, every external tool, and repo health — a colorful report you can paste straight into an issue. sopsy deps is the remedy: it installs whatever doctor found missing, ykman included.

edit

Friendlier edits

Open an encrypted file through SOPS with automatic file-type detection and nicer errors. Your $EDITOR, your workflow — none of the flag-juggling.

secrets

Scriptable encrypt / decrypt

One-shot, no-editor crypto for scripts and CI. sopsy encrypt .env -o .env.encrypted and sopsy decrypt .env.encrypted (to stdout, or -o a file). Structured .env / JSON / YAML / INI encrypt values only; everything else becomes one binary blob. Pipe decrypted values straight into your shell — via direnv in .envrc or a wrapper around your app — with no plaintext ever hitting disk:eval "$(sopsy decrypt .env.encrypted | sed -E '/^#/d; /^$/d; s/^([A-Z])/export \1/g')"

recipients

Recipient management

Add, remove, list, and rotate who can decrypt. Every change re-wraps existing secrets via sops updatekeys, so the key set never drifts from the ciphertext. The data key itself stays the same: sopsy rotate-data-key replaces it.

run / set

Secrets straight into a process

sopsy run -- bin/rails server decrypts into one command's environment and writes nothing to disk. sopsy set API_KEY and sopsy unset change one value without an editor, and the value never shows up in a process listing.

check

A CI gate that bites

Seven hygiene invariants, a pass/fail checklist, and a non-zero exit the moment a plaintext secret is tracked. Needs no key — runs on Linux runners too.

join / approve

Self-service onboarding

Newcomers sopsy join to mint a key and record a pending request — no access granted yet. Any active member sopsy approves: vouch for the key, promote it, re-key. Requests expire after 72h by default.

provenance

A built-in audit trail

Every member carries their name, username, when they requested access, and who granted it — approved_by recorded as "Grace Hopper (grace)". sopsy recipient list shows it all in one table.

integrity

Tamper-evident config

.sopsy.sha — a SHA-256 checksum of .sopsy.yml plus the admin public key — is refreshed on every write and verified on every read, so hand edits are surfaced instead of silently trusted. sopsy doctor repairs it.

One-secret CI decryption

sopsy recipient ci runs a guided ceremony that provisions a portable decryption key for your pipeline. Store one CI secret — SOPS_AGE_KEY — and a Linux runner with nothing but sops installed can decrypt.

How encryption flows

Plaintext stays local. Only ciphertext ships.

sopsy shells out to sops, which uses age recipients drawn from.sops.yaml. The primary path is dotenv: a plaintext.env becomes an encrypted .env.encrypted that's safe to commit.

Only encrypted files and public metadata belong in Git. The plaintext.env must always stay on your machine.

.env · plaintext

Your real KEY=value secrets. Gitignored automatically — never committed.

sops --encrypt --input-type dotenv

Recipients come from .sops.yaml creation_rules. sopsy never touches ciphertext itself.

.env.encrypted · committed

Encrypted values + sops metadata. Safe to push — only public recipients live here.

sopsy edit → decrypt → re-encrypt

A Touch ID prompt releases your Enclave key, opens your editor, and re-encrypts on save.

The CI gate

Seven invariants stand between you and a leak.

sopsy check is the sops-hygiene gate for CI and your pre-commit hook — it verifies the encryption discipline itself, and pairs with content scanners like gitleaks (below). It validates encrypted files by their on-disk sops metadata — never by decrypting — so it needs no private key and no Secure Enclave. Drop it on a Linux runner and it just works.

$sopsy check && echo "secrets hygiene: OK"

And when a job must actually decrypt — deploys, integration tests — sopsy recipient ci provisions a portable key in one guided ceremony. Store a single CI secret, SOPS_AGE_KEY, and a Linux runner with nothing but sops installed can decrypt. Never reuse the break-glass key for CI — offline/few-hands and online/every-run are opposite threat models.

$sopsy recipient ci

01.env is not tracked by git

02.env is gitignored

03.sops.yaml valid + has creation_rules

04every encrypted file matches a creation rule

05no plaintext secrets tracked

06every encrypted file carries sops metadata

07a break-glass recipient is configured

all checks passed · exit 0

Defense in depth

Stop secrets before the commit ever lands.

Don't rely on remembering. Run sopsy check from a pre-commit hook and in every CI pipeline, and pair it with a content scanner such as gitleaks or detect-secrets in your own hook manager. Three complementary checks, each catching what the others miss.

$printf '#!/bin/sh\nexec sopsy check\n' > .git/hooks/pre-commit

$chmod +x .git/hooks/pre-commit

sopsy check

Is the encryption intact?

The structural gate. Confirms sopsy's seven invariants — plaintext .env never tracked, every managed file genuinely encrypted, a break-glass recipient present. It knows which files must be encrypted, so it's deterministic and needs no key — but it doesn't read file contents looking for secret-shaped strings.

gitleaks

Does anything look like a token?

The pattern gate. Regex + entropy, git-aware. Catches known secret shapes — cloud keys, tokens, private keys — anywhere in your staged diff, including files sopsy never manages.

detect-secrets

Anything new since we audited?

The baseline gate. Scans against a committed .secrets.baseline you triage once; only new, un-audited findings block the commit — so noise stays low and real leaks stand out.

sopsy check proves the sops workflow itself is correct;gitleaks and detect-secrets read the content for secrets that never went through sops at all. What one heuristic misses, another catches — and because the pre-commit hook is advisory (--no-verify skips it), the same sopsy check in CI is the gate that can't be bypassed.

Encryption & team onboarding

Access is a pull request — and a human vouch.

Every teammate must be admitted before they can decrypt. A stranger who clones the repo, encrypted files and all, can never open them — they were never added to the recipient set. The first encryptor is the prime, and holds the offline break-glass pair in a vault for the day every laptop is lost.

newcomer · sopsy join

# Alan Turing's MacBook — branch off maingit checkout -b sopsy/add/alan-turing# request to join, and stage the change with --gitsopsy join "Alan Turing" --git# …trade the thumb for --without-touch-id ➜ pending request written to .sopsy.yml ✔ git add .sopsy.yml .sopsy.sha — staged for you ◇ ready-to-paste commit + PR printed below ↓git commit -m "Request access" && git push

member · sopsy approve

# Any already-approved engineer — same branchgit fetch && git checkout sopsy/add/alan-turing# vouch out of band, then approve + stage with --gitsopsy approve "Alan Turing" --git# …or bare `sopsy approve` to triage every request ✔ re-keyed every secret for the new recipient ✔ staged the re-keyed files — commit + PR printedgit commit -m "Approve Alan Turing" && git push ✔ merge the PR — Alan can now decrypt

Add --git to any command that changes files — init, join,approve, edit, and everyrecipient mutation — and sopsy git adds exactly the files it touched (never your plaintext .env) and prints ready-to-paste commit and pull-request commands. The secrets themselves are written with the scriptable shorthandsopsy encrypt .env -o .env.encrypted — no editor required.

Team scenarios

One team, four people, one policy.

Ada, the VP of Engineering, sets the policy and holds the break-glass key. Alan prefers a YubiKey. Grace prefers the Secure Enclave on her MacBook. Dennis works on Linux and does not want hardware keys. Ada's--allow-stores choice decides whether Dennis can join at all, and with what.

Ada

sets the policy

VP of Engineering

$sopsy init -A onchip,exthardware

Hardware only: the Secure Enclave or a YubiKey. The policy is committed in .sopsy.yml.
Interactive init also creates the break-glass key. Ada saves it in the team vault and presses ENTER; sopsy deletes the local copy.
CI never runs init. It gets its own portable key with sopsy recipient ci.

Alan Turing

YubiKey

engineer

$sopsy join "Alan Turing" -s yubikey -c cached -b cached

-c cached: the PIN is asked once per session, until the YubiKey is unplugged.
-b cached: after the PIN, one touch, then not again for 15 seconds.
He pushes the pending entry; Ada runs sopsy approve "Alan Turing".

Grace Hopper

Secure Enclave

engineer

$sopsy join "Grace Hopper" -s enclave

Every decryption asks for Touch ID. Fine for an occasional sopsy edit.
A problem once tools decrypt on their own, in every worktree and every shell. See the caching tips below.

Dennis Ritchie

Linux, no hardware

engineer

$sopsy join "Dennis Ritchie"

Whether Dennis can join at all is Ada's call, made when she ran init.
Under the default hardware-only policy he is refused until he has a YubiKey, or Ada widens the policy.

Dennis joins from Linux: Ada's policy decides

Ada ran init withDennis runsResult

-A onchip,exthardwaresopsy join "Dennis Ritchie"Refused: no allowed store works on his machine. He needs a YubiKey, or Ada widens the policy.

-A onchip,exthardware,keychainsopsy join "Dennis Ritchie" -s keychainHis key lives in the Secret Service keyring (GNOME Keyring, KWallet), encrypted at rest. No plaintext key on disk.

-A anysopsy join "Dennis Ritchie" -s fileHis key is a plaintext file in keys.txt. Anyone who can read his home directory can decrypt every secret.

The repository order never puts a weaker store first: even under -A any, Grace's and Alan's auto still picks hardware. Changing the policy later is a reviewed pull request to .sopsy.yml.

Many worktrees, many prompts?

When every worktree's .envrc runs sopsy decrypt, every new shell means another Touch ID. Three ways out, from least to most strict:

Drop the Touch ID gate

Swap in an Enclave key without Touch ID. It still never leaves the chip, but any program running as you can decrypt silently.

sopsy recipient rotate -s enclave -t

PIN once, no touch

A YubiKey key that asks for the PIN once per session and never for a touch. Policies are fixed in the key, so rotate to change them.

sopsy recipient rotate -s yubikey -c cached -b never

Skip .env entirely

Decrypt into one command's environment. Nothing on disk, one prompt per launch instead of one per shell.

sopsy run -- bin/rails server

The Secure Enclave security model

The private key never leaves your Mac.

Generated inside the chip. On Apple Silicon the private key is created within the Secure Enclave and bound to that hardware — it cannot be read, copied, or exported by anyone or anything.
Released with Touch ID. Decryption prompts your fingerprint, every time. If that gets old, sopsy recipient rotate -s enclave -t swaps in a key with no Touch ID gate: it still never leaves the chip, but any program running as you can then decrypt.
Only the public recipient travels. The age1se1… string is safe to commit and safe to share. It is all a teammate or admin needs to grant you access.
No Secure Enclave? Use a YubiKey. On Intel Macs and Linux the key lives in a YubiKey PIV slot instead: a PIN once per session with -c cached, then a touch. Up to 20 keys fit on one YubiKey.
Lose the device, keep the repo. Because the key is bound to one Mac or one YubiKey, a break-glass recipient is what keeps secrets recoverable if every hardware key is lost.

Break-glass keys

Set up disaster recovery on day one.

A break-glass key is a separate emergency age key pair — portable by design, stored offline in a vault and shared with only a few admins. If every developer's Secure Enclave or YubiKey is lost, it can still decrypt and re-key the repository. An interactive sopsy init sets it up by default. sopsy recipient break-glass runs the whole ceremony in one command: generate, hand off, wait for ENTER, delete the local copies, register and re-key.

Lose your only hardware key with no break-glass key, and every secret becomes permanently undecryptable. That's why doctor and check nag until one exists — and sopsy refuses to remove the sole break-glass recipient. The same guided ceremony powers sopsy recipient ci for your pipeline — but the two keys must never be the same: offline/few-hands and online/every-run are opposite threat models.

offline · once

# one guided ceremony: generate → store → delete → registersopsy recipient break-glass -o break-glass✔ wrote break-glass.private + break-glass.public⚠ copy both into 1Password / a vault, then continue press ENTER once the keys are saved … ✔ deleted both local key files ✔ registered break-glass recipient✔ re-keyed every secret (sops updatekeys)

Command reference

One verb per job. Every prompt has a flag.

sopsyinit[-A stores] [-s store]

Bootstrap an encrypted repository: install missing tools (--skip-deps to skip), record which key stores members may use (--allow-stores, hardware only by default), make your key, write every config file, and set up the break-glass key (--no-emergency-keys to skip). Idempotent — keeps existing files unless --force.

sopsydoctor

Print a grouped health report — system, tools, repository, recipients — and always exit 0. Repairs a stale .sopsy.sha checksum (its only write). Safe to paste into a bug report.

sopsyjoin<name> [-s store] [-t]

Self-service onboarding (alias: request-access): generate your key in any store the repository allows (-s enclave|yubikey|keychain|file) and record a pending request in .sopsy.yml. Commit, open a PR, and ask any member to approve. Pass -t / --without-touch-id to mint the key with no presence gate — handy for direnv and many-window workflows.

sopsyapprove<name>

Any active member vouches for a pending key, promotes it into .sops.yaml, and re-keys every secret — recording approved_by and approved_at for the audit trail, with atomic rollback if the re-key fails. Refuses requests older than join_request_ttl (default 72h).

sopsyedit<file>

Open an encrypted file in your editor through SOPS, with friendly errors and automatic file-type detection. Resolution: --editor → $EDITOR → $VISUAL → vi.

sopsyrecipientadd · remove · list · keygen · rotate · break-glass · ci

Manage who can decrypt. add/remove keep .sopsy.yml and .sops.yaml in sync and re-key secrets; list prints every member with their approval provenance; rotate swaps your key under the same name (--new-data-key also replaces the data key); break-glass and ci run guided portable-key ceremonies; keygen mints a key in any store without registering it.

sopsyencrypt · decrypt<file>

One-shot, scriptable crypto outside the editor. sopsy encrypt writes a .encrypted artifact (or stdout); sopsy decrypt prints plaintext to stdout or -o a file — ideal for direnv and CI. Structured .env/yaml/json/ini encrypt values only; anything else as one blob.

sopsyrun[-f file] -- <cmd>

Run a command with the decrypted values in its environment. Nothing is written to disk; sopsy replaces itself with the command, so exit codes and signals are its own. Repeat -f for several files (later ones win); --pristine passes only the decrypted values.

sopsyset · unset<KEY> [VALUE]

Change one value in an encrypted file without an editor. Omit the value to be asked with hidden input, or pipe it in on stdin; it never appears in a process listing. -f picks the file (default .env.encrypted). set needs sops 3.11 or newer.

sopsyrotate-data-key[files…]

Re-encrypt files under a brand-new data key for the same recipients (sops rotate). With no arguments, every encrypted file the repository manages. Run it after recipient remove.

sopsyyubikey · enclave<plugin args>

Run age-plugin-yubikey or age-plugin-se with your arguments, passed through unchanged. sopsy yubikey --list shows every key on your YubiKey: slot, PIN and touch policy.

sopsytypesalias: list-supported-types

Print the file formats sopsy understands and which extensions auto-detect to each: dotenv, yaml, json, ini (value-encrypted) plus binary (whole-file). Takes no flags; the longer list-supported-types name still works.

sopsycheck

The CI gate: seven hygiene invariants, a pass/fail checklist, non-zero exit on any violation. Never decrypts — needs no key, runs anywhere.

sopsydeps[--check] [--dry-run]

Install the external tools (sops, age, age-plugin-se, age-plugin-yubikey, ykman) with Homebrew. Probes first, installs only what is missing. The remedy that pairs with doctor: --check fails CI if anything is absent, --dry-run previews the brew command.

sopsycompletion<shell>

Generate shell completions for bash, zsh, fish, powershell, and elvish — derived from the CLI definition, so they never drift from the real flags.

sopsy--help· global --git

A clap-based CLI: sopsy --help and sopsy <command> --help are always authoritative. Every interactive prompt has an equivalent flag. The global --git flag stages exactly the files a command changed and prints ready-to-paste commit + PR instructions — a no-op when nothing was modified.

Install

Up and running in one command.

Homebrew

recommended

$brew install kigster/tap/sopsy

Installs a prebuilt binary — no Rust toolchain — and pulls the tools sopsy orchestrates (sops, age, and age-plugin-se) automatically. sopsy deps adds the YubiKey tools when you need them.

From crates.io

requires Rust

$cargo install sopsy

Builds from source with Cargo. You'll still need sops, age, and age-plugin-se on your PATH — or run sopsy deps to fetch them, along with age-plugin-yubikey and ykman. sopsy init runs the same step first.

Tap trust

only if required

$brew trust --tap kigster/tap

$brew trust --formula kigster/tap/sopsy

Only when your Homebrew sets HOMEBREW_REQUIRE_TAP_TRUST: trust the tap and the formula once before installing, and re-run brew trust --formula kigster/tap/sopsy before each brew upgrade sopsy.

●macOS-first (v2.0.0). Homebrew installs the prebuilt binary and every prerequisite; the Cargo path needs the Rust toolchain.

Encrypted secrets you can actually commit to Git.Decrypt with Touch ID or a YubiKey

Plaintext is never in the repo, never in Slack. Sleep soundly at night.

From zero to a whole team in eight steps.

Start (or enter) a git repository

Bootstrap everything

Put real secrets in

Verify hygiene before you commit

Commit the encrypted artifacts

A teammate joins (self-service)

An existing member approves

Run your app with its secrets

Watch the entire process live just below…

Any key store. Fewer prompts. No plaintext on disk.

Four key stores, and a policy for the repo

YubiKey, without the friction

Secrets in a process, not on disk

Change one value, no editor

Swap your key, keep your name

A fresh data key for every file

Tooling installed for you

The UX for every tool it wraps

Generate

Vouch & approve

Re-key secrets

Edit & commit

You already can. sopsy removes the sixteen ways you can get it wrong.

Safe defaults, sharp diagnostics, zero ceremony.

Hardware-backed identities

One-command bootstrap

Key stores & repo policy

doctor health checks

Friendlier edits

Scriptable encrypt / decrypt

Recipient management

Secrets straight into a process

A CI gate that bites

Self-service onboarding

A built-in audit trail

Tamper-evident config

One-secret CI decryption

Plaintext stays local. Only ciphertext ships.

.env · plaintext

sops --encrypt --input-type dotenv

.env.encrypted · committed

sopsy edit → decrypt → re-encrypt

Seven invariants stand between you and a leak.

Stop secrets before the commit ever lands.

Is the encryption intact?

Does anything look like a token?

Anything new since we audited?

Access is a pull request — and a human vouch.

One team, four people, one policy.

Ada

Alan Turing

Grace Hopper

Dennis Ritchie

Dennis joins from Linux: Ada's policy decides

Many worktrees, many prompts?

Drop the Touch ID gate

PIN once, no touch

Skip .env entirely

The private key never leaves your Mac.

Set up disaster recovery on day one.

One verb per job. Every prompt has a flag.

Up and running in one command.

Homebrew

From crates.io

Tap trust

Encrypted secrets you can actually commit to Git.
Decrypt with Touch ID or a YubiKey