Optio: self-hosted orchestration for AI coding agents, from ticket to merged PR
Workflow orchestration for AI coding agent swarms, from task to merged PR.
At a glance
- What is it?
- Optio is a TypeScript, MIT-licensed control plane that runs AI coding agents inside your own Kubernetes cluster and drives them from a submitted task to a squash-merged pull request. Its bet is infrastructure ownership and vendor neutrality rather than a better agent.
- Who is it for?
- Optio fits teams that already operate Kubernetes and cannot send source code, secrets or production data to a hosted agent service, and it fits shops that want to switch or A/B agent vendors per repository. It does not fit teams without a cluster, or teams whose agent work is small enough that a local CLI session is cheaper than running Postgres, Redis and a control plane.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 36 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Optio picks: agent output that stops at the pull request
Most ticket-to-PR tools end their job when the diff exists. Optio's documentation frames the gap differently: the interesting failure is not producing a patch, it is what happens after CI goes red or a reviewer asks for changes. The README states that when CI fails, the agent is automatically resumed with the failure context, and when a reviewer requests changes, the agent picks up the review comments and pushes a fix. When everything passes, the PR is squash-merged and the issue is closed. That loop, not the agent itself, is what the project sells.
The second problem is placement. Optio runs entirely inside a Kubernetes cluster (the README names GKE, EKS, AKS, or any conformant K8s), so code, secrets and agent logs stay on infrastructure the operator controls. The intended audience is stated plainly: security-conscious organizations, regulated industries where data residency and tenancy isolation are requirements, and platform teams that already run Kubernetes and want to add agent work to the stack they operate. If your team has no cluster and no intention of running one, the project's own comparison concedes that hosted options are simpler.
Three tiers, one control plane: Tasks, Jobs and persistent Agents
Optio splits agent work by shape rather than by feature. Tasks turn tickets into merged pull requests and are submitted manually or from GitHub Issues, Linear, Jira or Notion. Jobs are parameterized runs with no repository checkout, aimed at reports, alert triage, dependency audits, database queries and Slack posts. Persistent Agents are long-lived, named processes with a stable slug, an inbox and a cyclic state machine; they wake on user messages, agent messages, webhooks, cron ticks or ticket events, and can address each other through an inter-agent HTTP API. The README's own distinction is worth quoting: Tasks and Jobs are the job model, where the run is the unit of identity, while Agents are the service model, where a turn is an input to a long-lived process.
What holds the tiers together is shared machinery. All three are driven by the same trigger types, prompt-template engine, log streaming and /api/tasks HTTP surface, according to the README. Connections are the fourth piece: Notion, Slack, Linear, GitHub, PostgreSQL, Sentry or any MCP-compatible server can be attached and injected into agent pods at runtime. Persistent agents also expose three pod lifecycle modes (always-on, sticky, on-demand), which is the main lever for controlling cost against latency. Two runnable examples are cited in the repository: a four-agent Forge demo and Mars Mission Control.
The reconciliation loop and why pod state is not held in memory
The architectural claim worth examining is the control plane. Optio routes all task and pod state changes through what the README calls a Kubernetes-style reconciliation control plane: a pure-decision-plus-CAS-executor loop with periodic resync. The stated purpose is to keep runs from getting stuck on lost events. That is a real failure mode in agent orchestration. A webhook from GitHub or a CI status callback that never arrives leaves an in-memory orchestrator waiting forever, and the run silently dies.
Optio's answer is the same one Kubernetes uses. A decision function reads desired and observed state and emits actions; a compare-and-swap executor applies them; a periodic resync re-derives the decision from stored state even when no event fired. The consequence is that the database, not the process, is the source of truth, which is why the install expects Postgres and Redis rather than an embedded store. It also means the orchestrator can be restarted without losing track of in-flight tasks. The trade-off is that every state transition costs a round trip and a CAS attempt, and operators inherit the operational surface of a stateful control plane. The repository points to docs/reconciliation.md for the full description; that document is the first thing to read before trusting the loop with production repositories.
Getting it running: Helm, Postgres, Redis and an agent vendor
The README describes a drop-in Helm install with bring-your-own Postgres and Redis, integrating with existing observability, ingress and identity. It does not print a copy-pasteable install command in the material available here, so the exact chart name and values file are things to confirm in the repository before planning a rollout. What is documented is the surrounding surface: OIDC/OAuth for identity, Kubernetes RBAC, workspaces for tenancy, and secrets encrypted at rest with AES-256-GCM. Those are configuration concerns, not defaults you can ignore, because the platform stores credentials for GitHub, Slack, Linear and any MCP server you attach.
The agent side is deliberately pluggable. Claude Code, OpenAI Codex, GitHub Copilot, Google Gemini, OpenCode and Cursor sit behind one interface, and the README claims you can switch per repository or A/B agents on the same task. That is the most consequential configuration decision in the system: it determines which vendor sees your source, what the per-task cost looks like, and which container images the cluster pulls. The dashboard screenshots referenced in the README show cost tracking and Claude Max usage alongside pod status, so spend is surfaced per task rather than only in aggregate. Confirm the agent image references and any outbound network requirements before you point Optio at a private repository.
Where Optio is the wrong tool
The heaviest cost is the cluster itself. Optio assumes Kubernetes, Postgres and Redis are available or acceptable. A team of three engineers without a platform function will spend more time operating the control plane than the agent saves, and the README's own comparison says as much: if you would ship to a hosted agent without hesitation, the hosted option is simpler. This is not a hedge in the documentation, it is a fair description of the trade.
A second limitation is agent quality. Optio orchestrates vendors; it does not improve them. If the underlying agent cannot resolve a failing test from the failure context, the auto-resume loop will retry with the same information and produce the same result. The feedback loop shortens the distance between failure and next attempt, but it does not guarantee convergence, and nothing in the material describes a retry ceiling or a cost cap per task. That is a gap worth checking in the source.
A third is scope. Jobs and persistent Agents are documented as first-class tiers, but the repository's own framing puts Tasks and the ticket-to-PR loop at the centre. Teams whose work is mostly scheduled reports and alert triage should read docs/tasks.md and the examples directory before assuming the non-PR tiers are as exercised. The persistent-agent examples are demos, not production deployments, and the README does not claim otherwise.
Against hosted ticket-to-PR services, and against a plain agent CLI
The README names Devin, Charlie Labs, Cursor background agents and Sweep as the hosted alternatives, and characterises the difference as placement plus vendor choice. A hosted service gives you a working loop without a cluster; you trade control of where the code and logs live, and you accept whatever model family the vendor runs. Optio inverts both: you keep the cluster and the logs, and you pick the agent per repository. The cost is that you now own upgrades, database backups, secret rotation and the ingress in front of the API.
The more honest comparison is against a developer running an agent CLI locally. That path needs no Postgres, no Redis and no reconciliation loop, and for a single engineer on a single repository it is strictly less work. Optio only earns its complexity when work must be triggered by external events (an issue, a webhook, a cron tick), when multiple agents run concurrently in isolated environments, or when the run must survive a restart of the orchestrator. Those three conditions are exactly what the reconciliation control plane and the /api/tasks surface exist to serve. If none of them apply to you, the platform is overhead.
Maintenance, release cadence and what the MIT licence does and does not give you
The release history in the supplied material shows v0.3.1 on 2026-04-20, v0.3.2 on 2026-04-24 and v0.4.0 on 2026-04-27, with the last push to the default branch on 2026-08-11. That is a young 0.x line with a burst of releases in April and continued repository activity afterwards. A 0.x version number is a signal about interface stability, not about quality: expect the HTTP surface, the configuration keys and the Helm values to move between minor versions, and plan to read release notes before upgrading a running cluster.
Upgrade cost is dominated by the stateful dependencies, not by the Optio binary. Postgres schema migrations, Redis compatibility and the agent container images all change on their own schedules, and the reconciliation loop's resync behaviour is the thing most likely to be affected by a version bump. Pin the chart version, keep database backups, and test an upgrade against a staging cluster before touching production tasks.
The licence is MIT, which permits reading, forking and auditing the code, and the README leans on that explicitly. What MIT does not provide is any certification, attestation or compliance artefact. Running agents inside your own cluster keeps data on your network, but it does not by itself satisfy a regulator, and the README's mention of regulated industries describes who the project is aimed at, not what it has been certified for. Treat the encryption-at-rest claim (AES-256-GCM) and the RBAC integration as things to verify in configuration rather than assume.
Editorial conclusion
Optio fits teams that already operate Kubernetes and cannot send source code, secrets or production data to a hosted agent service, and it fits shops that want to switch or A/B agent vendors per repository. It does not fit teams without a cluster, or teams whose agent work is small enough that a local CLI session is cheaper than running Postgres, Redis and a control plane. Before adopting, verify three things against the repository: the Helm chart's declared dependency set, the docs/reconciliation.md description of the decision-and-CAS loop, and the exact agent images the multi-vendor interface pulls at runtime. The licence is MIT, so forking is permitted, but the project ships no compliance certification, and shipping code to your own cluster is not the same as being audit-ready.
Community notes