Should your team operate Centaur?
Evaluate Centaur when shared tools, credential grants and durable agent sessions solve an existing team problem. Its deployment asks you to operate a control plane and Kubernetes sandboxes, so a successful package install is only an early prerequisite.
Centaur is a self-hosted agent platform with Slack conversations, API access and per-conversation Kubernetes sandboxes. The repository documents CLI harnesses including Amp, Claude Code and Codex. It also describes persisted messages and execution events, shared Python tools, and workflows that can wait, resume or start child agents. These are documented capabilities, not deployed behavior verified by our run.
What our October 2 run established
Our sandbox's recorded October 2, 2026 run at commit 72e565b reports a successful pnpm install in 42 seconds. The exact checkout was 72e565bcd1921266f7e10e5062d7b9ae39601fc9. The sandbox record specifies lab-node:22, three CPUs and 8 GB of memory.
Our harness records command outcomes separately: installation has success status, elapsed time and exit code; build and test each have a skipped flag. The raw record gives no script as the reason for both skips. Skipped checks are neither passing checks nor failed checks, and they do not establish that the repository lacks tests elsewhere.
The stored dependency summary reports 343 packages and 308 MB. The install tail reports Packages: +342 and Done in 22.7s using pnpm v10.28.1. The harness records 42,235 milliseconds for the install step, rounded to 42 seconds in the attached summary. Package additions in that tail and pnpm's completion time should not be substituted for the harness measurements.
We did not boot Kubernetes, run the documented smoke test, complete a model turn, test Slack delivery or verify credential substitution. The audit field is null, so this run supplies no advisory result or known scan coverage. No new execution was performed for this correction.
The MrKeyoor testing methodology explains how command outcomes and measurement limits reach a review. That page was retrieved after this run; it does not establish which methodology version the October run used.
What you must configure before an agent turn
The quickstart requires Docker and a Kubernetes cluster plus just, kubectl, Helm and jq. A lightweight k3s cluster is supported; a production-sized cluster is not required for local evaluation.
Default bootstrap requires OP_SERVICE_ACCOUNT_TOKEN, OP_VAULT, SLACK_BOT_TOKEN, SLACK_SIGNING_SECRET and SLACKBOT_API_KEY. Application credentials belong in 1Password or the configured iron-proxy secret source. The documented default harness is Codex and needs OPENAI_API_KEY there before Slack agent turns can complete.
The documented next step is to boot the stack, verify API health and run the smoke test before configuring Slack. That smoke test waits for a completed execution containing PONG. Slack then requires a reachable public HTTPS webhook and the appropriate app configuration. Follow that sequence in your evaluation environment; our dependency install did not verify its outcome.
Isolation still needs operator policy
Centaur's security guide says outbound egress policy is open by default. Operators must replace the wildcard domain allowlist with the hosts their tools need if they want restrictive host policy.
The guide describes per-thread pods and a dedicated iron-proxy for each sandbox. Sandboxes receive credential placeholders, and the proxy substitutes real credentials for declared hosts and request locations. Network containment requires a CNI that enforces Kubernetes NetworkPolicy; setting proxy environment variables alone does not enforce that boundary.
These controls do not prevent an agent from misusing capabilities it legitimately holds. The documented threat model also excludes a fully privileged attacker on the host or cluster control plane. Treat tool grants, default roles and outbound policy as deployment decisions, and verify them with the actual tools you intend to allow.
Compare the layer you need
OpenHands Agent Canvas supports local, Docker, VM and cloud agent backends. Consider it when a developer control center with selectable execution backends fits your workflow better than Centaur's Kubernetes deployment. Its README warns that the option without a sandbox gives the agent full filesystem access. We did not run OpenHands or compare setup times.
E2B Runtime provides Firecracker microVM sandboxes with pause and resume. Consider it when your requirement is an execution substrate on which you will build an agent application. That makes it an alternative at the sandbox layer, rather than a demonstrated replacement for Centaur's Slack delivery, shared tools and durable conversation handling. The supplied evidence does not establish a Centaur integration.
How the editorial ratings work
These ratings assess the supplied evidence, not runtime performance or adoption. Setup ease uses 1 for a cluster deployment with several credential prerequisites and 5 for a verified single-step local start. Documentation uses 1 for missing operational instructions and 5 for complete instructions whose outcomes we independently verified. Community requires evidence of participation and response beyond the existence of contribution instructions; without it, we leave the dimension unassessed. Maturity uses 1 for an undocumented prototype and 5 for independently demonstrated deployment and operational stability.
Centaur receives setup ease 1 because its documented first turn requires cluster and credential setup. Documentation receives 4 because the supplied quickstart and security guide explain verification steps, defaults and limitations, but we did not execute those steps. Maturity remains 2 because this review has installation evidence and documented operational mechanisms, without a verified deployment or stability record. None of these ratings establishes security.