Skip to content
Mocó v0.0.3

Moco 0.0.3: release and recovery evidence

Release v0.0.3 adds published controller artifacts alongside the server. Source revision: d3230a01676007350f3452f0ad6b2c79c6697cd5. Release publication completed successfully. The release contains both chart archives, release.json and SHA256SUMS; the manifest records image and chart identities.

Markdown table
Published imageMulti-platform index digest
ghcr.io/araihu/moco:0.0.3sha256:d6a8167c48c771884729405ff4a0d3c8f65bb1b69bbcb96c091745de6eade180
ghcr.io/araihu/moco-controller:0.0.3sha256:b5a1ec66f8fc562584202c5e117de4af827acba5fd60bc082f516e72e7e04ffa

Both indices include Linux amd64/arm64, provenance and SBOM attestations. Both released charts pin their respective image digest.

Published artifact acceptance

The vind + Calico + ESO run passed 21 scenarios using the published images and charts, not rebuilt application binaries. The test harness revision was 2b236a3319c7591cfd608a9a0e8e1fe4ff8a4a66. It verified release archive checksums, OCI identities, installed chart versions and running image IDs.

Coverage included:

  • Declarative tenant/vault/authorization creation, idempotence, drift repair, controller restart, credential refresh and CRD admission guards.
  • Scoped authorization, ESO delivery to a consumer, special-character paths, binary Base64 decoding, invalid-token retention and CA repair.
  • TLS certificate, reader-token and controller-token rotation with revocation; NetworkPolicy boundaries and protected metrics.
  • Conditional updates with audit, automatic mirrored snapshots, root-key rotation/rewrapping, mirror failure readiness and recovery.
  • Persistent data after pod replacement, offline restoration with historical keys, fresh ESO sync and retained resources after CR deletion.

Reproduce with make vind-test on a host suitable for vind; the workflow can also run in release mode. See prerequisites and report fields. Use make vind-source-test when testing current source changes.

Scope and limits

The acceptance cluster used static single-node RWO volumes. The mirror was a separate volume on the same Docker host. This proves application integration and recovery behavior under the tested faults; it does not demonstrate off-host durability, a particular CSI driver's fencing, multi-node availability or your homelab's recovery objectives. Production remains one SQLite writer. External KMS/HSM and high availability are not implemented.

Keep historical root keys and deployment credentials in separate custody, protect backups as sensitive data and rehearse a restore on your own storage. Recovery runbook · Production profile.