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) has a guardrail: allow it, hold it for your sign-off (confirm), or refuse it outright (deny). The ones you cannot undo — deleting an app, deleting a DNS record — start denied, and you open them where it suits you.

burrow guard set --env prod app.deploy confirm    # require your sign-off before any prod deploy
burrow guard set --env dev app.delete allow       # let it clean up after itself in dev
burrow guard set --env staging app.delete confirm # ask you first in staging — prod stays denied
burrow guard set dns.write allow                  # let it add DNS records

Rules can be scoped per environment, so the agent moves fast in staging while prod stays locked down — and per app, for the one thing in an environment that has to be off limits:

burrow guard set --env prod --name payments app.deploy deny   # everything else in prod still deploys

burrow guard list --env prod --name payments then shows, guardrail by guardrail, whether the answer was set for that app, for the environment, or inherited.

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 database per app, on one shared instance per environment), logs (VictoriaLogs), metrics (VictoriaMetrics), and cache (ValKey).

One database server per environment is the default, not the limit. A service that wants its own — its own blast radius, its own resource ceiling, its own upgrade schedule — gets one with burrow addon install postgres --name analytics, and apps attach to it by that name. An app can hold connections to more than one; the second one names the variable it is written into, since DATABASE_URL belongs to the first.

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.

Postgres runs on CloudNativePG — including Burrow's own control-plane database, so installing Burrow puts the operator on the cluster. One more setup step adds off-cluster backups before the first database: burrow cluster postgres install. It asks for cluster-admin, which is why it is yours to run and not your agent's.

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 cluster install <context>         # installs Burrow into the named kube context (run `burrow cluster install` to list them)
burrow agent claude install              # wire Claude Code to burrow-agent (any other agent: `burrow agent <tool>` prints the rules to set)

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. Claude Code is the one agent with built-in wiring today; for any other, burrow agent <tool> prints the exact allow/deny rules to set by hand — burrow-agent is a plain binary, so any agent that can run a command can drive it.

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 optional and off the default path — building and pushing images with your own tooling, then deploying by reference, remains the default — and it carries the limits noted in docs/CAPABILITIES.md.

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. For what is built today versus what is decided but not yet built, see docs/CAPABILITIES.md.

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/CAPABILITIES.md: "can Burrow do X?" — every capability, the command that reaches it, its sharp limits, and what is decided but not yet built.
• 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.