Kubernetes is a wonderful place to run apps and a miserable place to learn to run apps. Between your finished code and a healthy, reachable service sits a pile of operational chores: the kind of work that has nothing to do with your product and everything to do with keeping it alive. Most of it is fiddly, easy to get subtly wrong, and completely uninteresting once it works.
You should not have to become an expert in any of it. Here are seven of those chores, and how Burrow handles each one so you can stay in the part that is actually yours.
1. Writing and maintaining YAML
The classic first tax. To run one app on raw Kubernetes you write, by hand, a deployment, a service, probably a config map and a secret, maybe an ingress, each with its own indentation rules and its own ways to break. Then you keep all of it in sync forever, by hand, as the app changes.
Burrow does not ask you to write any of it. You deploy by naming an image:
burrow app deploy web --image ghcr.io/you/web:1.2.0
Burrow turns that into the running workload, wires in your config and secrets, and keeps the whole shape correct as you deploy new versions. You can read YAML, sure. You just never have to write it to get your app running.
The subtle tax here is not the first file, it is the drift. Manifests you wrote by hand rot: you tweak the app, forget to update the secret reference, copy a block from an old service and miss a field. Every one of those is a small, silent breakage waiting for a deploy to surface it. When Burrow owns the shape, that whole category of paper cut goes away.
2. Rolling out a new version without downtime
When you ship a new version, the old one should keep serving until the new one is proven healthy, then traffic should shift over cleanly. Doing that by hand means understanding rollout strategies, readiness checks, and how to avoid dropping requests in the gap.
Every Burrow deploy is a clean rolling update. The new version comes up, health is checked, traffic moves, and the old version steps down, all without you specifying any of it. If the new version never becomes healthy, the rollout does not quietly leave you in a broken half state, it tells you, and the previous version is still right there.
The failure mode this saves you from is the worst one: a deploy that half succeeds. Some requests hitting the new version, some hitting the old, users seeing errors while you try to work out which pods are which. A clean rollout is either fully the new version or, if the new version cannot prove itself healthy, still the old one. There is no murky in between for you to untangle under pressure.
3. Getting a certificate and keeping it fresh
HTTPS is not optional, and certificates are a chore that never ends: request one, prove you own the domain, install it, then remember to renew it before it expires and quietly takes your site down. People have built entire outages out of forgotten renewals.
Burrow requests and manages the certificate for you when you publish:
burrow app publish web --host app.example.com --port 8080 --tls
That one flag, --tls, gets you a real certificate for the host and keeps it renewed. You do not track expiry dates. You do not run a renewal cron job. The certificate is just there, and it stays there.
4. Figuring out why the app is not reachable
"It is deployed but I cannot reach it" is one of the most frustrating states in all of operations, because the chain from your browser to your app has so many links: the route, the address, the certificate, DNS. Any one of them can be the problem, and a bare "down" tells you nothing about which.
Burrow walks the chain for you and names the broken link:
burrow app reachability web
Instead of "not reachable," you get "the certificate has not issued yet" or "DNS does not resolve to the cluster." That is the difference between a five minute wait and a two hour debugging session. Your agent can read the same output and often fix the link itself.
5. Keeping the app up when something falls over
Processes crash. Nodes hiccup. A healthy production setup notices and restarts the failed piece without a human waking up. Building that yourself means health checks, restart policies, and the plumbing to make them work together.
Burrow runs your app so it self heals. If a process falls over, it comes back. This is table stakes for production, and it is the default, not something you configure. You get the good part of Kubernetes, the resilience, without assembling it.
Staying up under load is the same story. When traffic climbs, running more copies is one command:
burrow app scale web 3
And when you would rather not watch the graphs yourself, autoscaling adjusts the count for you between a floor and a ceiling you set:
burrow app autoscale web
It scales up when the app is busy and back down when it is quiet, so you are neither paying for idle capacity nor caught short during a spike. Turn it off again with burrow app autoscale web off whenever you want the number pinned. Either way you set the bounds, so "scale automatically" never means "surprise me with a bill."
6. Standing up the backing services your app needs
Real apps need more than the app: a database, somewhere to see logs, a way to watch performance, maybe a cache. On raw Kubernetes each of those is its own project to install, configure, secure, and connect to your app.
Burrow installs them as one command addons that run on the nodes you already pay for:
burrow addon install postgres
burrow addon attach postgres web
That gives your app its own database and wires the connection string in for you. The same pattern gives you logs, metrics, and a cache. No separate installs to research, no connection strings to copy around by hand. When you outgrow the built in ones, Burrow can connect to backends you already run instead.
When you attach the Postgres addon, Burrow generates a DATABASE_URL for that app and wires it in as an environment variable, so your code connects the way it already expects to. The same one command pattern covers the rest of the usual supporting cast:
burrow addon install logs # VictoriaLogs, searchable app logs
burrow addon install metrics # VictoriaMetrics, performance graphs
burrow addon install cache # ValKey, a fast in memory cache
burrow addon attach cache web
Each of those runs on the nodes you already pay for, not on some external service with its own bill and its own login. And if you already run Loki for logs or Prometheus for metrics, Burrow can connect to those instead of standing up its own, so you are never forced to duplicate infrastructure you have.
The reason this is a chore and not just a task is the long tail. Standing up a database is a day. Keeping it secured, giving each app its own isolated space, rotating credentials, remembering to back it up, that is the part that drags on forever and is easy to half finish. Burrow gives each attached app its own database and role, wires the credentials in, and puts backups one command away:
burrow addon backup postgres web
burrow addon backups postgres web
So the parts people usually skip, isolation and backups, are the parts you get by default.
7. Getting back to a known good state fast
Even with everything above, a bad version will slip out sometimes. The chore then is recovery: figuring out how to redeploy the last good version, and doing it while the site is down and you are stressed. On raw Kubernetes that can mean digging for the previous image and hoping it comes back up.
Burrow keeps your previous version warm and ready, so going back is one command:
burrow app rollback web
No rebuild, no cold start, no scramble. Traffic shifts back to the version that was healthy a minute ago, and you get room to figure out what went wrong without the clock running. The recovery and the diagnosis become two separate steps, and the stressful one is already done, which is exactly what you want when a release goes sideways.
What this looks like on an ordinary Tuesday
Put the seven together and a normal working day is short. You build a new image, deploy it, glance at the status, and get on with your life:
burrow app deploy web --image ghcr.io/you/web:1.3.0
burrow app status web
If the status is green, you are done. If it is not, the logs tell you why:
burrow app logs web --tail
And if the release turns out to be bad after it is live, recovery is one line and takes seconds:
burrow app rollback web
That is the whole rhythm. No YAML edits, no certificate to chase, no scramble to find the last good image. The chores are still happening under the surface, the rolling update, the health checks, the certificate renewal, but they are not on your desk. Your agent runs this exact same rhythm through its scoped commands, so you can hand off the routine and keep the decisions.
Questions people ask about this
Does Burrow hide my cluster from me? No. Everything runs on the cluster you own, and it is all plain Kubernetes underneath. You keep kubectl, you keep root, and you can inspect anything. Burrow does the chores in the open, it does not lock the door behind them.
What about per service resource limits? Setting a memory and CPU budget per app is coming soon, not shipped yet. When a doc or a command promises something, it is because it works today. Anything still ahead is named as ahead, on purpose.
Can I still drop down to raw Kubernetes when I want to? Yes. Burrow owns the shape of the workloads it manages, but it is running on your cluster with your access intact. Nothing stops you from looking at, or running, other things alongside it.
Do the addons lock me in? No. The built in Postgres, logs, metrics, and cache addons run on your nodes, and where an open standard already exists (Loki, Prometheus), Burrow can point at what you already run instead. There is no lock in to a hosted back end you cannot leave.
Are these chores really optional?
It is worth being honest about what is happening here, because "the tool handles it" can sound like "the work disappeared." It did not disappear. Rolling updates still happen, certificates still get requested and renewed, health checks still run, backups still get taken. The work is real and it still needs doing. What changed is who does it and how much of your attention it costs.
That distinction matters because it is the difference between Burrow and a magic box. Burrow is not hiding your infrastructure from you or running it somewhere you cannot see. It is doing the operational chores on the cluster you own, out in the open, with plain commands you can read and rerun. You keep root, you keep the ability to look at everything, and you hand off the tedium, not the ownership. That is the trade that makes sense: give up the busywork, keep the control.
The thread running through all seven
None of these chores are hard exactly. They are just endless, easy to get wrong, and utterly beside the point of building your product. Every hour you spend writing YAML by hand or chasing a certificate renewal is an hour not spent on the thing your users actually care about.
The promise is simple: you own the cluster, you keep root, and you run real production Kubernetes, but you never have to touch the tedious parts of it. Burrow does the chores. You ship the app. And because it is all plain commands, your agent can do the chores too, staying inside the guardrails you set, so you can hand off the operational busywork and keep the decisions.
If you have been putting off owning your own cluster because this list is what "owning a cluster" used to mean, that is the thing to reconsider. The chores were never the reason to run your own infrastructure, they were just the toll you had to pay to get there. Stop paying the toll and what is left is the good part: your apps, running on machines you own, at full speed, with the tedium handled.
That is the whole idea. Kubernetes where you want it, which is running your app well, and nowhere you do not, which is anywhere near your afternoon.