A shared agent service, not another chat integration
Centaur turns command-line coding agents into infrastructure a team can use from Slack or an API. Mention the bot in a thread, and the platform assigns a Kubernetes sandbox containing a shell, workspace, Git, Python, Node.js, Bun, and development tools. Codex, Claude Code, Amp, or another supported harness runs inside it. Progress and the final response return to the thread, while messages, executions, events, and delivery state persist in Postgres.
The important part is everything around the model. Each conversation gets an isolated execution environment. Shared Python tools can call internal services. Durable workflows can wait, resume after restarts, run on schedules, or start child agents. Organization overlays add prompts, personas, skills, and tools without changing the base repository. That is a credible answer to the problem of every developer configuring a powerful local agent differently.
Centaur fits tasks such as investigating a failed build, querying an internal system, producing a recurring digest, or letting an agent inspect a real repository and run tests. It is less compelling when the job is merely answering questions in Slack. The operational bill only makes sense when shell execution, shared permissions, and recoverable workflows are essential.
The security design addresses the right danger
Agents execute model-generated commands and consume untrusted content, so prompt injection is an infrastructure concern, not just a model-quality problem. Centaur gives every thread a short-lived, restricted pod with privilege escalation disabled and Linux capabilities dropped. A default-deny Kubernetes NetworkPolicy allows the sandbox to reach only the Centaur API and its dedicated iron-proxy pod. Sandboxes are separated at the filesystem, process, and network layers.
Credential injection is particularly well considered. Tool definitions name a placeholder, allowed hosts, and the header, query field, or path where the secret may appear. The sandbox sees the placeholder rather than the real key. Iron-proxy substitutes the credential only on a matching outbound request. OAuth, Google service accounts, and Postgres connections receive related typed handling. Structured proxy logs and durable execution records provide evidence of what an agent attempted.
These controls limit exposure, but they do not make an agent trustworthy. The security guide says egress is permissive by default until an operator replaces the wildcard with explicit domains. Agents retain broad filesystem and shell power inside their pods and can call every tool permitted by their token. A model can still misuse a legitimate capability after prompt injection. Centaur also does not protect against an attacker who already controls the host or Kubernetes control plane.
Permission configuration deserves the same attention as cluster setup. Credentials can share a backing Kubernetes Secret or 1Password vault, while the Console scopes access by principal, role, and request rules. New principals receive the infra role by default so they can run a harness. Operators must decide default roles, repository-cache access, sandbox capabilities, and direct tool grants before broad rollout.
The quickstart is an infrastructure project
A local evaluation does not require a production Kubernetes installation, but it does require a cluster. The guide supports k3s, kind, minikube, or Docker Desktop Kubernetes. You also install just, kubectl, Helm, jq, and Docker. Before just up, the default chart expects a Slack bot token, Slack signing secret, service API key, 1Password service account token, and vault identifier. Codex is the default harness, so a working model credential must exist in the configured secret source.
Then Slack needs a public HTTPS webhook, event subscriptions, bot scopes, interactivity configuration, and an app reinstall. A smoke command tests the durable API without Slack, which is a good diagnostic boundary. The docs provide health checks, logs, pod queries, and a complete API example rather than pretending a successful Helm install proves the agent works.
Production adds an external Postgres decision, multiple high-entropy signing and encryption keys, Console bootstrap credentials, ingress, backups, image management, a dedicated runtime class or node pool, secret rotation, and capacity limits. Issue #1357 points to one practical gap: an administrator cannot force-reclaim a sandbox from the web interface and may hit the running limit while waiting for maximum lifetime cleanup. Issue #1356 reports that the bundled sandbox chart cannot pin an image using a SHA-256 digest, a meaningful problem for strict supply-chain policy.
Excellent documentation around a young system
The project was created in May 2026, so maturity claims should be conservative. Release centaur-0.1.115 arrived on August 8 and packages the trusted control-plane Helm chart. The repository was pushed on August 12, with identity, Slack, sandbox, usage, and permission changes landing or under review that day. GitHub showed 90 open issues and pull requests combined, but only 16 open issues in an issue-only search. The difference reflects an unusually busy pull-request queue rather than 90 confirmed defects.
Documentation is a standout. The quickstart names every prerequisite, the production guide inventories secrets and operating decisions, the architecture explains service boundaries, and the security page states both mitigations and exclusions. The code is offered under the reader's choice of Apache 2.0 or MIT.
Centaur is a strong choice for a team that has outgrown personal agent installations and already accepts Kubernetes as an operating boundary. Start with one low-risk workflow, close the egress allowlist, grant tools narrowly, and appoint an owner for incidents and upgrades. If those steps sound excessive, the platform is excessive for your current need. If they sound overdue, Centaur deserves a serious pilot.