Why We Built a Config and Secrets Manager That Never Phones Home

Prajna — Wed, 26 Aug 2026 01:14:41 +0000

How we built KeyKosh(K2): offline Ed25519 licensing, Docker-only delivery, and one-time pricing — for people who self-host on purpose.

The problem

Most config management tools assume two things: that your infrastructure can reach the internet, and that you're fine with a vendor's cloud sitting in your critical path. Not all of them — a couple self-host cleanly, one has no server at all — but enough that it shaped the market.

The pattern was consistent. The governance features a team actually needs — RBAC, SSO, audit logging — sat behind per-identity pricing or an enterprise tier. Self-hosted builds still wanted to call home. The alternatives that avoided both took real operational muscle to run well.

What we wanted was unglamorous and apparently hard to buy: install it, own it, govern it, and have it call nobody.

What KeyKosh does

One Docker image and a Postgres. An organization → application → environment tree holding config and secrets, per-org roles, an audit log, and Java/Node/Python SDKs that read over scoped tokens. The feature list is on the site; what's worth writing about is the reasoning behind three decisions that shaped it.

Three decisions worth explaining

Licensing is offline. Activation is an Ed25519 signature verified against a public key bundled in the image. No license server, no callback, no outbound call ever. The interesting part was accepting the constraint honestly: if validation is offline, revocation has to be designed for it — signed key IDs, an operator-supplied denylist — rather than pretending a callback exists.

It also answers the question every closed-source self-hosted tool gets asked. If this project disappears, nothing changes for you: there is no server of ours to die, your license is a perpetual signed artifact, and your data is in your Postgres.

Enforcement degrades instead of bricking. Paid keys are domain-bound to prevent resale. But a key on the wrong host, an expired trial, a revoked key — the install drops to the free tier's limits and keeps serving config. Nothing is deleted, and the caps apply only to creating new resources. A licensing mistake should be an inconvenience, not an outage.

That's the kind of claim a vendor shouldn't be believed on, so it's pinned by twelve assertions run against the published image with a real purchased key, including "the degraded install still serves config to an SDK token" and "the encrypted-at-rest secret still decrypts while degraded." Results at keykosh.com/proof.txt.

We shipped an encrypted offline cache, then deleted it. This is the decision we'd defend hardest, and it started as a mistake.

The SDKs keep a local copy of your config so your app boots when the server is unreachable. The first version was a binary format, encrypted and keyed to the token that fetched it. It looked responsible, and it survived review because "we encrypt the cache" is the sentence everyone wants to say.

Then we tried to write the threat model down. The file exists so the SDK can start when there is no server to ask — so the key has to be derivable by the SDK, alone, on a machine that can't reach us. Which means the key travels with the file. A lock whose key is taped to it is not a lock, and calling it encryption tells operators to relax about a file that deserves the same care as a .env.

So the format is now plaintext JSON, and the docs say plainly that it holds whatever the token could read, secrets included: gitignore it, mount it with secret file modes, turn it off per client if you'd rather fail closed than boot stale.

Two things fell out that we didn't plan. Python's SDK lost its last dependency and is now genuinely zero-dep. And workload-identity clients — authenticating with signed AWS STS envelopes rather than a static token — could suddenly use the file at all, because there was no longer a token to key it to. The encrypted design had quietly excluded the credential type with the best security story.

Pricing, and why it isn't per-seat

The license is one-time and perpetual, and nothing is metered per seat. That second part matters less as a discount than as a decoupling.

Per-identity pricing means the tool gets more expensive precisely as the team grows — which is the same moment governance starts mattering, because roles and an audit trail are things you need because there are now enough people to need them. You end up paying most for the controls at the point you can least treat them as optional. Attaching the license to a domain instead of a headcount breaks that link, and it's structural rather than generous: with no recurring meter there's no metering to build, so per-seat billing was never an option.

It isn't unbounded — each tier has a user ceiling, so cost moves in a step rather than a slope. The numbers are on the pricing page.

Where it is today

The platform and the three SDKs (Maven Central, npm, PyPI — MIT and readable on GitHub) are built and tested end to end.

What has not been proven, stated so you don't have to find it in a comment thread: there has been no third-party security audit. The admin UI is an MVP. Password resets are admin-issued rather than self-service, because a self-hosted install has no guaranteed outbound mail. The approval flow is unit-tested rather than black-box tested. That list, and the full assertion results, are on the proof page.

Two disclosures worth making up front. KeyKosh is built and maintained by a one-person team — which is exactly why the architecture is designed so that our survival isn't your dependency. And it was built with heavy AI assistance; we'd rather say so than have someone find it. Judge it on the proof page and the bare-VM install rather than on how it was written.

Free tier and a 14-day trial, no card: keykosh.com. The quickstart is one curl and one docker compose up.