What happens to your secrets if seekrit disappears
Trust
A secrets manager is the most awkward dependency in your stack. Every deploy blocks on it, it holds the credentials to everything else, and it's usually sold by a company much smaller than the infrastructure it sits in front of.
So the question is fair, and you should ask it of every vendor in this category including us: if you go away, what do I still have?
Most answers are some version of "we have a good uptime record" and an SLA that pays out in service credits, which are worth exactly nothing to a company that can't deploy. This is our attempt at a real answer.
Why the question is sharper for us
Being zero-knowledge makes this both better and worse.
Worse, because we genuinely cannot help you. A vendor holding your keys can mail you a plaintext dump on the way out. We can't — we don't have your keys and never did. If our answer to this question were "contact support," there would be no answer at all.
Better, because it forced the exit path to be a real feature rather than a policy. The design constraint was: the customer must be able to get everything out and open it with no network, no account, and no seekrit in existence.
What you can take, today
One command exports the entire organization as a single JSON file:
seekrit archive create --out acme-2026-08-23.json
That file holds every row we store for you: applications, groups, environments and their branches, every current ciphertext and every historical version, every environment key wrapped to every principal, members and roles, service token metadata, rotation policies, lease targets, the full audit log, and every version of every signed agent access policy — so what an agent was permitted to reach stays verifiable years later.
It also carries your own passphrase-encrypted private key, which is what makes the archive self-sufficient: the file plus your passphrase is everything.
Exporting decrypts nothing. The archive is exactly as unreadable to us as the database it came from.
Two things worth knowing about the policy around it. Export is never gated on
your plan — the ability to leave isn't a paid feature, and a vendor who
paywalls the exit has told you something. And every export writes an
org.exported audit row with the actor, the row counts, and the archive digest,
so it's as visible as any other privileged action.
Opening it with no network and no us
Two paths, neither of which needs seekrit to exist.
The CLI decrypts an archive without building an API client at all — the
archive subcommands never talk to a server:
seekrit archive decrypt acme-2026-08-23.json --out ./plaintext
# ./plaintext/apps/web/production.env
Or, with nothing installed, the standalone decryptor: a single HTML file you keep next to your archives.
seekrit archive decryptor --out seekrit-decrypt.html
Open it in any browser, including from file:// on an air-gapped machine. Drop
in the archive, enter your passphrase, read your secrets.
That page declares Content-Security-Policy: default-src 'none'. The browser
will refuse every outbound request it could possibly make, so the page that
handles your passphrase and your plaintext is structurally incapable of
sending them anywhere. It's one line at the top of the file — read it before
you trust it, which is the point.
Keep a copy of that HTML file with your backups. An archive, the decryptor, and your passphrase is the entire recovery path, and none of it involves us.
Verifying it years later
The archive's manifest carries a SHA-256 digest per section and is signed with Ed25519, so it's tamper-evident offline:
seekrit archive verify acme-2026-08-23.json
verify names the section that failed rather than saying "bad file." Two
exports of unchanged data are byte-identical, so you can diff last month's
archive against today's.
One caveat with a deadline on it: to check provenance as well as integrity you
pin our signing key, published unauthenticated at
/.well-known/seekrit-export-signing-key. If we're gone, that endpoint is gone.
Fetch it once and keep it with your archives — the docs say so, and this is
the reason.
The harder case: losing the person, not the file
An archive plus a passphrase assumes someone still has the passphrase. The worse scenario is that the only key-holder for an environment has left and their passphrase went with them.
That's what customer-controlled recovery is for, and the archive carries everything the ceremony needs — each environment's data key wrapped to the org recovery key, plus every custodian's wrapped Shamir share. So the ceremony runs offline, from the archive alone. Each custodian unwraps their share from their own copy:
seekrit archive share acme-2026-08-23.json --out share-ana.json
Any threshold of shares reconstructs the recovery key and opens everything:
seekrit archive decrypt acme-2026-08-23.json \
--share share-ana.json --share share-bo.json --out ./recovered
Below the threshold it fails outright rather than producing plausible garbage. The standalone HTML decryptor accepts pasted shares too.
This only works if you set recovery up before you need it. That is the single most valuable thing in this post: configure custodians while everyone still works here.
Where the answer stops
Some honest limits, because a section like this is worthless if it only contains good news.
It is an exit artifact, not a restore point. There is no import. Getting a live organization back means re-granting keys through the recovery ceremony, not uploading a file. If we vanished overnight you would have all your secrets in plaintext and would then be standing up a different secrets manager with them.
An archive is one person's view. It carries your wrapped private key and nobody else's, and environments your key holds no grant on are skipped rather than failed. Each admin exports their own; between them the coverage is complete.
Three columns are deliberately excluded, because including them would hand you either an offline cracking target or an undecryptable blob: authentication hashes for tokens and sessions, the admin credentials on lease targets, and the destination API credentials on sync connections. The last two are encrypted to a server-side key that no key of yours can open.
Honey tokens are never in an archive. A decoy credential works because nobody knows where it's planted, and an archive is a file that travels. Every trip is still in the audit log.
Backups are still your job. We keep your ciphertext available; we do not keep your archives. A file you never exported protects nobody.
Ask everyone this
We built this because the honest version of the zero-knowledge pitch has an uncomfortable corollary: if we can't read your secrets, we also can't rescue them. The exit had to be real.
But the question generalises, and it's the most useful one you can put to any vendor in this category:
- Can I export everything — versions, grants, audit — or just current values?
- Can I open that export with no network and no account?
- Can I verify it wasn't tampered with, offline, a year from now?
- Is export available on the free plan, or is leaving a paid feature?
Our answers are yes, yes, yes, and yes — the commands are above and the export guide has the rest. Go ask whoever holds your secrets today. The answer tells you more about a vendor than any feature page.