Centaur: shared AI agents for teams, self-hosted on Kubernetes
Centaur is frontier, agentic infrastructure that you own. Centaur is like Claude Tag, but open source and on steroids.
At a glance
- What is it?
- Centaur is a self-hosted agent platform from paradigmxyz that runs Slack conversations inside Kubernetes sandboxes with durable state and controlled outbound access. It is real infrastructure, not a wrapper, and that is both the pitch and the cost.
- Who is it for?
- Adopt Centaur if you already run Kubernetes or k3s and want one shared, auditable agent instead of per-developer local setups. Do not adopt it if you want a single binary or a hosted service, or if you cannot supply a Slack app, a 1Password service account and a small always-on host.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Centaur solves: one shared agent instead of many local ones
Most teams end up with a different agent setup per developer. Someone has a local CLI agent wired to their own API keys, someone else runs a different harness, and none of the configurations are shared or auditable. Centaur's answer is to move the agent out of the laptop and into a platform the team owns. The README frames it plainly: "Centaur is a self-hosted agent platform for teams that want one shared agent instead of many one-off local setups."
The intended user is a team that already has internal services worth exposing to an agent: CI systems, databases, search endpoints, deployment tooling. The README lists investigating CI failures, answering questions with internal tools, summarizing Slack threads or customer context, running recurring checks and digests, and coordinating multi-step operational workflows as the target work. That is an operations audience, not a solo developer experimenting with prompts.
The interaction model is Slack-first. You mention the bot in a thread, Centaur assigns a sandbox to that thread, and progress plus the final answer come back into the same thread. There is also a direct API path, so Slack is not strictly required for every caller.
How the architecture is laid out: control plane, sandbox, and outbound proxy
The README's diagram is short but specific. Slack or the API feeds the Centaur API, which holds Postgres durable state, tool metadata, the workflow runtime, and sandbox assignment. From there work goes to a Kubernetes sandbox containing the agent harness, a workspace and shell, and local tool CLI shims. Outbound traffic leaves through a controlled path.
The repository splits these responsibilities across directories. services/api-rs is described as the Rust control plane for agents, tools, workflows, auth, and durable state. services/slackbotv2 handles Slack event handling and delivery. services/sandbox holds the agent container image and harness adapter. services/iron-proxy is the component for controlled outbound access and credential injection, and it links to docs.iron.sh. Tools live in tools/ and workflows in workflows/.
Two design choices stand out. First, the control plane is Rust while tools and workflows are Python, which means plugin authors do not need to touch the control plane. Second, credential boundaries are enforced by the proxy rather than by handing keys to the agent: the feature list says agents can use approved services without receiving raw API keys in their environment. That is a meaningful separation, and it is also the part most likely to need configuration work before anything useful runs.
Installing Centaur locally with k3s and just
Centaur expects a Kubernetes environment, but the README is explicit that a full production installation is not required: a lightweight k3s cluster on a small always-on host is enough. The README also states an expected local checkout path, which matters because the Justfile and bootstrap steps assume it.
/Users/magelinskaas/paradigmxyz/centaurClone the repository and enter it, then install the local command runner with Homebrew.
git clone <repo-url>
cd centaur
brew install justBefore the first boot, Centaur needs infrastructure secrets exported in your shell. The README shows the required set, including a 1Password service account token and vault, the Slack bot token and signing secret, and an API key the Slackbot uses to call Centaur.
export OP_SERVICE_ACCOUNT_TOKEN=...
export OP_VAULT=...
export SLACK_BOT_TOKEN=...
export SLACK_SIGNING_SECRET=...
export SLACKBOT_API_KEY=...The Slack app itself is created at api.slack.com/apps. According to the README, the app's Bot User OAuth Token goes into SLACK_BOT_TOKEN and its Signing Secret into SLACK_SIGNING_SECRET. Optional Teams ingress needs TEAMS_BOT_APP_ID, TEAMS_BOT_APP_PASSWORD, and TEAMS_BOT_APP_TENANT_ID when teamsbot.enabled=true, and TEAMSBOT_API_KEY is generated by local bootstrap when omitted.
With the environment set, two just targets do the work. The first creates the local Kubernetes Secrets from those variables; the second boots the stack.
just bootstrap-secrets
just upAfter just up finishes, the README points to Slack or to the API examples in AGENTS.md under e2e-testing-without-slack. For a more explicit host setup, docs/pages/mac-mini-setup.mdx covers k3s on a small VPS, a DigitalOcean droplet, a Linux box, or a Mac Mini-style host. A first real use is to mention the bot in a Slack thread with a task such as "can you figure out why the billing tests are failing?" and watch the sandbox take over.
Tools and workflows: Python plugins with a generated CLI bridge
Tools are small Python plugins, and the README gives the directory shape directly: __init__.py, client.py, cli.py, .env.example, and pyproject.toml. Each runtime tool should declare a [project.scripts] entry so sandbox startup installs it as a local CLI shim. Agents then discover installed tools through a generated command.
centaur-tools list
my-tool --helpWorkflows are Python functions with durable steps. The README shows a WORKFLOW_NAME constant and an async handler, and states that jobs can sleep, resume, wait for events, start child agents, and survive service restarts. Workflow handlers can still invoke tools through ctx.call_tool(...), with the workflow host using the generated centaur-tools bridge for that compatibility path.
One detail in the README is easy to miss and worth flagging: api-rs does not expose legacy HTTP tool-method routes as the current sandbox tool registry. If you are carrying over assumptions from an older integration style, the tool surface is the CLI shim, not HTTP method routes. The README also notes that organization overlays let you layer in your own tools, workflows, personas, skills, and prompts without forking the base platform, which is the intended path for team-specific behavior.
Where Centaur is the wrong tool
The setup cost is the obvious limitation, and the README does not hide it. You need a Kubernetes or k3s cluster, Postgres for durable state, a Slack app with a bot token and signing secret, and a 1Password service account token plus vault for secret resolution. If your team has none of those, Centaur is a large commitment before the first useful answer.
The README does not document rollback or teardown for the local stack, and it does not describe upgrade procedures between releases. Given that releases are frequent (centaur-0.1.143 on 2026-09-17, with 0.1.142 and 0.1.141 earlier the same week), an operator should expect to track version churn without a documented migration path in the README. That is a real gap, not a nitpick.
The licence is listed as NOASSERTION, so the repository does not declare a standard SPDX identifier in the metadata available here. Anyone planning to redistribute Centaur or build a product on it should read the LICENSE file in the repository root before assuming permissive terms. Nothing in the README or the release names addresses this.
Finally, if your need is a single developer running an agent on a laptop with their own keys, Centaur is overbuilt. The whole point is shared state, shared tools, and credential separation across a team.
How Centaur differs from a hosted agent product
The README positions Centaur against a hosted product directly: "Centaur is like Claude Tag, but open source and on steroids." The meaningful difference is not the feature list but where the state and credentials live. A hosted agent product keeps transcripts, tool access, and credential handling on the vendor's side. Centaur keeps them in infrastructure you run: Postgres for durable state, your own Kubernetes sandboxes, and iron-proxy for outbound access and credential injection.
That trade is concrete. You gain control over where messages, executions, events, and delivery state are stored, and you can add tools and workflows as Python plugins without waiting on a vendor. You give up the zero-setup path. There is no hosted tier described in the README, no managed Postgres, and no documented way to skip the k3s requirement.
A closer comparison is a local CLI agent harness. Centaur explicitly supports running CLI-based agents such as Amp, Claude Code, Codex, or deployment-specific harnesses, so it is not competing with them at the model layer. It is competing at the layer above: sandbox lifecycle, durable transcripts, tool access, credential injection, workflow execution, and final delivery. If you already like your harness and only lack shared infrastructure, that is exactly the gap Centaur targets.
Maintenance, releases, and upgrade cost
The repository is not archived, and the last push was on 2026-09-17, so this is a project under current development rather than a dormant one. Release cadence is high: centaur-0.1.143, centaur-0.1.142, and centaur-0.1.141 all landed within a few days. Version numbers remain in the 0.1.x range, which is worth reading as pre-1.0 software.
The operational cost sits in the components you must keep running: a k3s or Kubernetes cluster, Postgres, the api-rs control plane, the Slackbot service, the sandbox image, and iron-proxy. The README describes durable workflows that survive service restarts, which reduces the pain of restarting individual services, but it does not describe how to upgrade a running deployment or how schema changes in Postgres are handled across releases.
On licensing, the repository metadata reports NOASSERTION rather than a recognised identifier such as MIT or Apache-2.0. That is a signal to check the LICENSE file yourself. It is not legal advice, and it is not a statement that the terms are restrictive; it is simply that the metadata available here does not name them.
Editorial conclusion
Adopt Centaur if you already run Kubernetes or k3s and want one shared, auditable agent instead of per-developer local setups. Do not adopt it if you want a single binary or a hosted service, or if you cannot supply a Slack app, a 1Password service account and a small always-on host. Before committing, verify that your harness of choice is supported by the sandbox adapter, that iron-proxy can resolve the credentials your tools need, and that the local checkout path expected by the Justfile matches your machine.
Frequently asked questions
How do I install Centaur?
The README's local path is to clone the repository, install the just command runner with Homebrew, export the required secrets, then run just bootstrap-secrets followed by just up. A lightweight k3s cluster on a small always-on host is enough; a full production Kubernetes installation is not required.
How do I set up Centaur locally?
You need a k3s cluster, Postgres-backed durable state, and secrets including OP_SERVICE_ACCOUNT_TOKEN, OP_VAULT, SLACK_BOT_TOKEN, SLACK_SIGNING_SECRET, and SLACKBOT_API_KEY. The README also points to docs/pages/mac-mini-setup.mdx for a more explicit host setup.
How do I use Centaur?
Mention the bot in a Slack thread and the agent assigns a sandbox for that thread, then delivers progress and the final answer back to Slack. The README also shows an API path using POST /api/session/{thread_key}, a messages endpoint, an execute endpoint, and a GET events endpoint for streaming or replay.
Community notes