Kokumi (/koʊkuːmi/, Japanese: コク味, from コク “richness” + 味 “taste”) means "heartiness" or
"richness" — subtle compounds that enhance and harmonize flavors.
Kokumi applies this idea to Kubernetes delivery by introducing the missing
"richness" in an OCI-first workflow, preserving the subtle qualities of
GitOps like clarity, traceability, and review, while embracing OCI's
strengths in portability and immutability. The result is a system where
configuration isn't just shipped, but deeply understood and transparently
delivered.
GitOps made Git the source of truth. That was a good deal. You got history, blame, diffs, and PR-based review essentially for free. OCI is increasingly taking over as the delivery mechanism for Kubernetes config, and it brings real strengths: content-addressability, immutability, and airgap compatibility that Git was never designed for. But the industry is swapping one for the other as though Git's review and traceability properties were incidental. They weren't. Kokumi is built on the premise that you shouldn't have to choose: it embraces OCI as the artifact layer while preserving the visibility and human-in-the-loop qualities that made GitOps worth adopting in the first place.
Kokumi is a Kubernetes operator for structured, immutable release management. It draws a hard line between three concerns that most delivery systems conflate:
- Intent — what should be built and how (the Order)
- Artifact — what was built, exactly (the Preparation)
- Activation — what is currently running (the Serving)
By keeping these separate and immutable at the artifact layer, your engineers can:
- Gate on human approval before a rendered artifact ever reaches a cluster.
- Inspect the full rendered manifest in the built-in UI before promoting.
- Edit rendered manifests in the UI. Tweak the fully-rendered manifest in the browser and produce and activate a new Preparation revision.
- Roll back instantly by selecting any previous Preparation — the artifact already exists, no re-render required.
- Operate in restricted networks — the entire pipeline works offline; all dependencies are OCI artifacts that can be mirrored in advance.
- Detect drift unambiguously — compare the deployed SHA-256 digest to the desired one; any mismatch is a concrete, actionable signal.
Kokumi supports both Helm charts and pre-rendered manifest bundles as OCI source artifacts, and delegates all runtime deployment to Argo CD — feeding your existing GitOps workflow rather than replacing it.
Kokumi is currently experimental — use with caution in production environments.
Read the Installation guide and Getting Started guide on the docs site for full setup instructions, or explore the Architecture & Concepts page to understand how the reconciliation model works before diving in.
Contributions are highly welcome! See the Contribution Guide for details on how to get involved.
Kokumi models delivery using four Kubernetes primitives.
Order is the concrete execution request. An Order declares the source OCI artifact (a Helm chart or manifest bundle), optional patches, and rendering configuration. It describes what should be built — not a running system. Every change to an Order triggers a new render cycle and produces a new Preparation automatically. Optionally, an Order can consume and parameterize a Menu template.
An immutable OCI artifact produced by rendering an Order at a specific point in time. Preparations are created automatically — you never write one directly. Multiple Preparations accumulate per Order, giving you a complete, reproducible history of every version ever built. Promoting or rolling back is simply a matter of pointing the Serving at a different Preparation.
The active deployment pointer — exactly one per Order. A Serving references
one specific Preparation and creates or updates an Argo CD Application that
syncs that artifact into the cluster. Switching versions (upgrading or rolling
back) means updating which Preparation the Serving references; the artifact
does not change.
Menu is the reusable delivery template. It represents the base structure that an Order can consume and parameterize per environment or rollout.