uBix Vault 1.0 — Stable, and Honest About What That Means
1.0
uBix Vault is 1.0.0. A from-scratch, self-hosted secrets manager — the encryption barrier, the Shamir seal/unseal, all the cryptography written in-house against the Go standard library — has gone from a design note to a stable release over about a dozen betas. The API, the CLI, the storage format, and the Helm chart are now covered by Semantic Versioning: I’m committing to not breaking them out from under you.
I want to be precise about what that number means, because I said something different a few betas ago and I’d rather explain the change than let it slide.
What I said before, and what changed
Back at beta 11, I wrote that the last gate on the road to 1.0 was an external security review — the one thing I couldn’t build myself. I meant it. But I was conflating two things that a version number was never meant to carry at once.
A version number, under SemVer, communicates exactly one thing: the stability of the public interface. 1.0 means the API is stable and I’ll follow the compatibility rules from here. It says nothing — it cannot say anything — about whether the cryptography has been audited. Those are two different axes: is the interface stable and has someone independent tried to break it. I had welded them together, so “1.0” was being held hostage to an event with no fixed date.
So I unwelded them. 1.0 is an API-stability and feature-completeness milestone. The security review is now tracked as its own open, actively-pursued milestone — and it is explicitly not a version gate. Decoupling them lets each tell the truth: the interface really is stable (say so), and the audit really hasn’t happened yet (say that too, loudly, in the same breath).
This is not me quietly lowering the bar. The bar for trust is exactly where it was.
So: has it been audited? No.
Plainly: uBix Vault has not undergone an independent third-party security audit. The crypto and the trust path are standard-library Go, written carefully, fuzzed, and property-tested. That is real engineering, and it is not the same as an outside expert who isn’t invested in my being right trying to break it. I cannot audit my own cryptography and have that mean anything — the entire value of a review is that it isn’t me.
Until that review lands, the honest guidance hasn’t changed: weigh it before you put high-blast-radius secrets in it, prefer running it alongside an audited store, and make the risk visible to whoever owns security. The disclaimer at the top of the repo says this, and it stays until an auditor — not a version bump — takes it down.
What 1.0 actually is
Everything the Community tier of the tool most people mean by “a secrets manager” has, done from scratch and readable in an afternoon:
- An encryption barrier (AES-256-GCM, path-bound), in-house Shamir seal/unseal, and three ways to auto-unseal — including a KMS/HSM seal that reaches any cloud KMS through a command you supply, with no provider SDK in the vault.
- KV v2, Transit as crypto-as-a-service (now with per-context key derivation and convergent encryption), dynamic database credentials, PKI, per-token cubbyhole, and response wrapping.
- A full identity layer — one subject behind many logins, groups (internal and IdP-driven), and policy templating so one rule gives every user their own drawer.
- The complete auth set: token, AppRole, Kubernetes, userpass, JWT/OIDC, TLS client-certificate, and LDAP/Active Directory.
- Durable MySQL/MariaDB storage, live rekey, encrypted snapshots, metrics/health, a read-only web console, signed images with SBOMs — over a Vault-compatible API, with essentially two dependencies in the whole tree.
It also, as of 1.0, survives its database blinking — a transient storage outage is retried and degraded to a clean 503 instead of failing every request, because a secrets manager shouldn’t be one slow query away from an outage.
Where it is
uBix Vault is BSD 3-Clause, on GitHub at github.com/cwolsen7905/uBixVault, tagged v1.0.0, with signed multi-arch images.
A dozen betas ago it was a plan. It became a design, a binary, a service that could authenticate seven different ways and be its own CA, one whose data outlives its machine and whose crypto keys never leave it. Now it’s 1.0 — stable, feature-complete, and honest about the one thing it’s still waiting for. That last door still needs someone who isn’t me to walk through it. Everything on my side of it is done.