burrow

Burrow

For developers moving fast with AI who don't want to break things

Production grade self hosting for your apps, operated by the AI agent you already use. Point Claude Code, Cursor, Codex, or your own agent at your Kubernetes cluster and it deploys, scales, debugs, and rolls back your apps. It drives burrow-agent, a scoped CLI, but the credentials and the guardrails live in a control plane you own. Every risky move (deploying to prod, deleting an app, exposing to the internet, DNS and add-on changes) is gated by a policy you set: the agent proposes, you decide, and the boundary is enforced in code the agent can't reach past, not an instruction it might ignore.

Burrow runs its own site on Burrow, live at burrow-cloud.dev.

It is not another git deploy host. Vercel and friends run your app on their platform; Burrow operates your cluster (real Kubernetes, done right), and goes past the app to the whole stack. The agent writes the integration code, and Burrow stands up and runs the backing service behind the same guardrails.

Why Burrow

• Bring the agent you already use. Claude Code, Cursor, Codex, or your own. Burrow is not another agent to adopt or a dashboard to learn, and there is no MCP server to stand up: put one binary on the agent's PATH and it can operate real infrastructure, safely.
• The boundary is enforced, not instructed. The agent holds no cluster credentials. A control plane you own holds them and gates every dangerous operation, so a bad prompt or a confused step can't cross a line you drew. "Be careful with prod" is a wish; a guardrail is a control.
• Own your infrastructure, no lock-in. Burrow self-hosts in your own cluster. Open source (Apache-2.0), one binary, no vendor platform in the path to migrate off later.
• Production grade by default. Real Kubernetes done right: self-healing workloads, rolling deploys, ingress and TLS, in-place upgrades, sane defaults.

Talk to your agent

Once Burrow is connected, you operate your apps by talking to your agent. Things you can say today:

• Deploy my app to prod
  • Burrow figures out which app you mean from the folder you are in, builds it, and rolls it out to your cluster.
• Roll back the last release
• Scale web up or Scale web to 3
• Autoscale web between 2 and 10 replicas on CPU
• Show me any 500 errors from my web app and figure out what happened
  • Your agent reads the logs and tells you what broke, in plain language.
• Why isn't my site reachable at example.com?
  • Your agent walks the chain (DNS, TLS, cluster), finds the broken link, and proposes a fix.
• How is my app doing? or Why is my app slow?
  • Straight answers, no dashboards to dig through.
• My site is slow, would a cache help?
  • Your agent checks your logs and metrics, tells you if it would, and if you say yes, sets one up and wires your app to it.

Coming soon: Limit web to 500MB of memory and 1 CPU.

Build it, then fix it

Your agent can write your app. The real test is whether it can keep it working, and most agents go blind the moment the code leaves the editor. Burrow gives yours the tooling to diagnose and fix a live app, not just ship it, all as one-command addons that run on the worker nodes you already pay for, so they add capability without adding cost.

• Why is my app throwing errors? Burrow adds centralized logging to your cluster and gives your agent access, so it reads what actually happened instead of guessing. Chasing a stubborn bug? It adds logging to your code, redeploys, and reads the new lines back.
• My site feels slow Burrow installs a metrics collector that watches CPU, memory, and traffic. Your agent finds the bottleneck and tells you the fix, or makes it.
• My latest change won't deploy A bad build or a broken image is blocking the rollout. Your agent sees exactly why it failed, fixes the code, and redeploys.

Guardrails

Guardrails are how you decide what your agent can and cannot do. Every risky action (deploying to prod, deleting an app, rolling back, exposing publicly, DNS and add-on changes) can be gated by a guardrail you set: raise it to confirm to require your sign-off, or to deny to refuse it outright. You opt in, so the agent proposes and you decide.

burrow guard set --env prod app.deploy confirm   # require your sign-off before any prod deploy
burrow guard set --env prod app.delete deny      # never let the agent delete an app in prod
burrow guard set dns.write allow                  # let it add DNS records
burrow guard set dns.delete deny                  # but never delete them

App-level rules can be scoped per environment, so the agent moves fast in staging while prod stays locked down.

Addons

Building something new, or adding a capability? Ask your agent to stand up a backing service and wire your app to it:

• Add a Postgres database and connect my app to it
• Set up logging so I can see what my app is doing
• Add a cache to speed up my site

Available today: Postgres (a cluster-shared database), logs (VictoriaLogs), metrics (VictoriaMetrics), and cache (ValKey).

Postgres always exports its own metrics, so once you install the metrics addon your database is scraped automatically (connection and transaction health plus pg_stat_statements slow-query stats) — install the two in either order. Now when a page feels slow the agent can rule the database in or out instead of guessing.

By default the agent asks before standing anything up: it proposes, you approve. Make it hands-off with burrow guard set addon.install allow, or install it yourself with burrow addon install postgres.

Want an addon we do not have yet? Request one.

Built for day two

The hard part isn't the first deploy, it's everything after. Once your app is live, this is what you get:

• It keeps running. Your app self-heals when something falls over, and new releases roll out without taking the old one down.
• It stays reachable, over HTTPS. Your app gets a URL with TLS, and when something is off you get a straight answer about which link in the chain broke ("the cert hasn't issued yet"), not just "it's down."
• You operate it by talking. Status, logs, rollback, scale: your agent does the work, and the guardrails you set gate the risky moves (a prod deploy, a delete) so it can't get past you.
• You get plain-language answers. Ask how things are going and your agent tells you in a sentence, no dashboards to dig through.

And the risky changes go through you: set a guardrail and the agent proposes, you approve, it executes, with a record of what happened either way. That human-in-the-loop step is what makes letting an agent operate production actually acceptable.

How it works

Three things:

1. Your agent - any AI coding agent you already use (Claude Code, Cursor, Codex, Copilot, OpenCode).
2. Burrow - the piece you install. It holds your cluster credentials, does the work (deploy, scale, logs, backing services), and gates the risky actions behind the guardrails you set, per environment, so the agent stays inside the lines you draw.
3. Your Kubernetes cluster - your infrastructure, which you own.

Two things keep it safe: your code never passes through Burrow (it moves through a container registry, not the agent connection), and every change the agent tries to make is checked before it runs. Nothing lands on your cluster that you did not approve.

For a deeper look at the architecture, see Architecture.

Try it

Burrow works with any Kubernetes cluster you can reach with kubectl. Three commands get you from nothing to an agent operating your cluster:

brew install burrow-cloud/tap/burrow     # installs burrow and burrow-agent
burrow install <context>                 # installs Burrow into the named kube context (run `burrow install` to list them)
burrow agent claude install              # wire your agent to burrow-agent (or another supported agent)

Then just talk to your agent ("deploy this and serve it at example.com over HTTPS"), or drive Burrow directly with burrow app deploy web --image nginx:alpine and burrow app status web.

Don't have a cluster yet? You can spin one up on DigitalOcean in a few minutes — a managed cluster, or a single droplet the VPS bootstrap can use. (Referral link — you get free signup credit, and it helps support Burrow.)

Want to try it with no cloud at all? docs/QUICKSTART.md takes you from nothing to your agent deploying an app to a local k3d cluster — and getting blocked trying to delete it — on your laptop in about 5–10 minutes.

See docs/getting-started.md for the full walkthrough, including the complete list of supported agents and how to wire any other agent by hand.

Prefer to build from source? go build -o burrow ./cmd/burrow && go build -o burrow-agent ./cmd/burrow-agent.

Upgrading later? See Upgrade.

System requirements

Burrow runs on a cluster you provide, so the sizing is yours to plan. It depends on whether you self-host on a single VPS or bring a managed Kubernetes cluster. The numbers below are what Burrow's own pieces reserve; your apps and builds need room on top.

Self-host (single VPS / k3s)

burrow cluster bootstrap turns one machine into a k3s cluster with Burrow installed. Before it touches the machine it runs a preflight that requires at least 2 GB of RAM and refuses to continue below that, printing a memory breakdown so you can see where it goes (ADR-0044). So a 2 GB VPS is the practical floor; a 2-vCPU / 4 GB machine leaves comfortable headroom for your own apps and for an in-cluster build to schedule. Budget a few GB of disk on top for k3s, container images, and the control-plane database. A single node's public IP serves a free LoadBalancer through the bundled servicelb / MetalLB, so there is no separate load-balancer bill to plan for.

Managed Kubernetes (DOKS / EKS / GKE)

• A LoadBalancer is required to reach your apps from the public internet, and cloud providers bill for it — a fixed monthly charge per LoadBalancer, separate from your nodes.
• Worker-node sizing and count matter, because platform overhead can eat most of a small node before any of your workload runs. On DigitalOcean (DOKS) the system components — the Cilium CNI, CoreDNS, and per-node agents — take roughly ⅔ of a CPU on a 1-vCPU / 2 GB node, leaving little for apps or builds. Give the cluster real headroom: a node with at least 2 vCPU / 4 GB, or more than one small node, so an app and an in-cluster build both have somewhere to schedule (#274).

Component resource costs

Approximate requests for Burrow's own components, in plain units. A request is what a component reserves at rest; most sit well under their limits until they are worked.

The in-cluster build is the demanding one: it reserves ¼ of a CPU and can burst to 2 CPUs and 2 GB while it runs. On a cluster with no spare capacity it will not schedule at all, which is why a small single node needs headroom above the platform and control-plane baseline. It is still experimental and not yet functional; today you build and push images with your own tooling and deploy by reference.

Shell completion

burrow ships completion for bash, zsh, fish, and PowerShell. Load it for your shell:

source <(burrow completion bash)                                  # bash (current shell)
burrow completion zsh > "${fpath[1]}/_burrow"                     # zsh
burrow completion fish > ~/.config/fish/completions/burrow.fish   # fish
burrow completion powershell | Out-String | Invoke-Expression     # PowerShell

Then reload your shell so completion loads: source ~/.zshrc (or source ~/.bashrc), or just open a new terminal.

Run burrow completion <shell> --help for how to install it permanently.

Changelog

Burrow follows semver from v0.1 toward v1.0. This table never lags the code.

Documentation

• docs/QUICKSTART.md: a validated laptop walkthrough — your agent deploys an app to a local k3d cluster and hits the delete guardrail, no cloud, in about 5–10 minutes.
• docs/getting-started.md: set up Burrow on your cluster and connect your agent, start to finish.
• docs/ARCHITECTURE.md: the system design, its four layers, invariants, and request paths.
• docs/HARDENING.md: keep Burrow the agent's only path to the cluster, so the guardrails actually bound it.
• docs/ROADMAP.md: version milestones, v0.1 → v1.0.
• docs/PLAN.md: the current execution plan.
• docs/adr/: Architecture Decision Records, every load-bearing decision, with its reasoning and rejected alternatives.
• CLAUDE.md: the contributor and agent guide.

License and contributing

How the code is licensed (LICENSING.md):

• All of Burrow's code in this repository is Apache-2.0: the burrow CLI, the burrow-agent control channel, and the software that runs in your cluster. Read, modify, self-host, and integrate against it freely.

Burrow is open source. Need enterprise features such as SSO? Reach out at hi@burrow-cloud.dev.

Contributions are welcome. Open an issue or a discussion. Bug reports, ideas, and design feedback are the best way to help and to shape where Burrow goes. Commits are signed off under the Developer Certificate of Origin (git commit -s). See CONTRIBUTING.md.