uBix Vault v0.2.0-beta.9

Ninth beta. Production-oriented storage and operations.

Added

• MySQL/MariaDB storage backend — -storage mysql (or Helm storage.type=mysql) runs the vault against a database instead of a local disk, so the node is replaceable: it can die and restart against the same durable, replicated database. The vault creates its own tables; you provide a database, a user, and a DSN (via a Secret in Kubernetes). Values stay barrier ciphertext — the database never sees plaintext, so a DB or DSN compromise yields ciphertext, not secrets. Single active writer (durability, not multi-writer HA). No new dependency — reuses the MySQL driver. (ADR D-014)
• Rekey — rotate the Shamir unseal shares live, with no downtime and no data re-encryption (e.g. when a share-holder leaves). POST /v1/sys/rekey/* or ubixvault operator rekey init|update|status|cancel. The master key is regenerated and the keyring re-wrapped under it; the barrier key and all data are untouched.
• Scheduled backups (Helm) — an opt-in backup.enabled CronJob snapshots the running vault to a separate (off-node) PVC on a schedule, using a least-privilege sys/snapshot token.

Still essentially one dependency (the MySQL driver). See docs/DEPLOYMENT.md for MySQL storage setup and credential hardening.

Pre-release. Not production-hardened; no external security review. For production, use HashiCorp Vault or OpenBao.

See CHANGELOG.md.