Kodama: Open-Source AI Agent Pipelines for Teams

DEV Community

Why Kodama Being Apache-2.0 Open Source Feels Like a Breath of Fresh Air

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/). 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 co...

Powered by Readybot.io