Why Kodama Software Factory Being Open Source Feels Like a Breath of Fresh Air

Gordon Chase — Sun, 15 Nov 2026 11:09:00 +0000

A coding agent in a terminal is great for one developer on one laptop. The trouble starts the day your company wants to run agents as a team across a hundred repositories—with separate roles, review gates, audit trails, and shared credentials.

Right now, almost everyone trying to solve that problem wants to sell you a new SaaS subscription.

You know the pitch: connect your GitHub organization to our cloud, hand over write tokens to private repositories, route your internal context and logs through our multi-tenant black box, and pay per seat—or marked-up compute minutes—while your own Kubernetes cluster sits right there doing nothing.

That is why stumbling onto Kodama feels so refreshing. Instead of wrapping container orchestration and human approvals behind a hosted paywall, Kodama ships the whole software factory as Apache-2.0 open-source software in Go—ready to run on rootless Podman on a Linux laptop in minutes, and on the Kubernetes cluster you already operate in production.

What Kodama Actually Is

Louis introduced Kodama on DEV with a line that sticks: “Like OpenClaw, but for teams.” Even if you have never touched OpenClaw, the core product model fits in one sentence:

A pipeline is an ordered list of actions; an action runs a container or requests an answer; an execution runs a pipeline once; a task is a conversation that starts executions.

If you have ever used container-native CI like Drone, the first half feels immediately familiar: containers run in order, share a workspace, and exit zero or nonzero.

The second half is what turns CI into a software factory:

An action does not have to run a container. It can pause the line and request a decision from a role (role/reviewer) or an automated policy service (service/<id>).
An agent is just another container command. Claude Code, Codex, OpenCode, Pi, or an ordinary shell script all plug into the exact same pipeline alongside your build and test images.
Tasks hold the shared history. People, scripts, or editor agents submit tasks via REST, MCP, or kodactl. Reviewers work from a role inbox; failed executions land in the operators' inbox.

How It Works Under the Hood

What makes Kodama a pleasure to inspect is how cleanly its architecture draws boundaries (KODAMA.md lays out the entire v2 design and 20 acceptance criteria in one readable spec):

Shell (Control Plane): Owns tenants, projects, OIDC and service-token identity, authorization, tasks, role inboxes, envelope-encrypted secrets, and a single operation router with REST and MCP edges (used by kodactl and editor integrations alike).
Kernel (Execution Engine): Advances ordered executions, enforces action deadlines, and recovers cleanly after crashes—without depending on HTTP, Git, OIDC, or message brokers.
Durable State & Messaging: PostgreSQL is the source of truth for state, approval receipts, and the event table (isolated per tenant and project with forced row-level security). NATS JetStream distributes events and live logs; if the broker hiccups, integrations wait, but executions do not lose state.
Workloads (Podman or Kubernetes Jobs): Locally, actions run as rootless Podman containers. In production, each container action is a plain Kubernetes Job mounting a workspace PVC—no custom CRDs and no Kubernetes operator to babysit. Workloads authenticate back to the Shell with short-lived execution tokens.
Userland Services: Git hosting, coding agents, and external adapters live outside control-plane internals and use the public API and approval verification.

Why Open Source Beats Another Agent SaaS Here

Some software categories make sense as SaaS. Your software delivery control plane—where code, credentials, review authority, and release history meet—is where open source and self-hosting shine brightest. Four details in Kodama show why:

1. Your keys, code, and decisions stay in your cluster

With Kodama, your repositories, pipeline state, and approval records stay in your own database and cluster. Even better: workload containers never need raw ANTHROPIC_API_KEY or OPENAI_API_KEY secrets. Agents point their base URL at Kodama's built-in model proxy using an execution token that is revoked when the execution waits or finishes. Only the model prompts your agents send go to the LLM provider you configure.

2. Waiting for a human costs zero compute

In many hosted agent platforms, human-in-the-loop workflows feel awkward or expensive because sandboxes stay warm or sessions time out after half an hour. In Kodama:

When a pipeline reaches a role/reviewer approval step, zero workload containers run while waiting (up to 30 days). The workspace volume is preserved and the execution credential is revoked until a reviewer approves.
When an agent gets stuck mid-task and posts a question to a role inbox, Kodama ends the execution cleanly. Answering the question starts a fresh execution with the full task conversation mounted at /kodama/task.json.

3. Real separation of duties—including against the agent itself

Two security properties stood out right away:

Role checks have teeth: If an Engineer starts an execution and tries kodactl approve <id> on a Reviewer gate, Kodama refuses with forbidden. Even holding Admin does not grant review authority. When paired with Kodama's Git service, main can require a verified approval bound to the exact candidate commit, target ref, and expected base.
Agents cannot edit the pipeline that governs them: Kodama does not auto-discover pipeline YAML from Git pushes. Pipelines are applied explicitly via the API (kodactl pipeline apply). A coding agent with branch-push access cannot sneak a change into .kodama/ to skip tests or bypass review.

4. Deliberate simplicity (and honest boundaries)

SaaS marketing pages love promising infinite flexibility. Kodama's specification spends real ink on what it refuses to build:

No DAGs, no when expressions, no loops, no parallel branches inside a pipeline. A pipeline is an ordered list; branching logic belongs in a shell script or tool you can actually unit-test. Scale comes from scheduling many independent task executions across Kubernetes Jobs.
Plain, honest status notes: Current release 0.2.1 is exercised locally on Linux with rootless Podman 5+, and live-validated in cloud deployment on Scaleway (with OpenTofu roots also implemented for AWS and GCP). Its container isolation separates tenants across namespaces, default-deny NetworkPolicy, KMS-backed secrets, and PostgreSQL RLS—built for organizations running trusted engineering tools, not as an untrusted hostile-code sandbox.

Try It Locally in Four Commands

If you have a Linux box with rootless Podman 5+ (systemctl --user enable --now podman.socket), you can inspect the ~100-line installer (it verifies SHA256SUMS, installs into ~/.local/bin, and never asks for root) and spin up the full stack—PostgreSQL, NATS, Kodama server, Git service, and four local roles (admin, engineer, reviewer, operator):

curl -fsSL https://raw.githubusercontent.com/optimiware/kodama/master/install.sh | sh
kodama up
source ~/.kodama/instances/default/env.sh
kodactl whoami

When you are done experimenting, kodama down --purge cleans up every container and volume.

GitHub (Apache-2.0, Go): github.com/optimiware/kodama
Full architecture & spec: KODAMA.md
Quickstart & docs: optimi.com/en/docs/kodama/getting-started
Hands-on walkthrough: Kodama: run coding agents as a team, at scale, on your own Kubernetes

DEV Community: Gordon Chase