Self hosted means yours

Burrow runs on the cluster you own. Not our platform, not our account, not a slice of shared infrastructure we rent to you. Your machines, your cloud bill, your root access. Burrow installs into that environment and operates there, and the line between "your stuff" and "our stuff" is simple: it is all yours.

This is the core difference between Burrow and a PaaS. A PaaS runs your app on their platform. You hand over your code, they run it somewhere you cannot see, and the day you want to leave you find out how deep the roots went. Burrow runs your app on infrastructure you already control. We are the tooling, not the landlord.

You install it into your own cluster

The ownership starts at the very first command. You do not sign up for an account and get a slice of something we run. You take a cluster you already have, one you point at with your own credentials, and you install Burrow into it.

burrow install my-cluster        # installs into the cluster you name, using your access

That single step is the whole relationship, in miniature. We never held your cluster credentials, so there was no moment where you handed us the keys. The piece that does hold them, the part that talks to Kubernetes on your behalf, runs inside your cluster from the start. It is yours, sitting on your machines, using access you granted locally and can revoke locally. Nothing about that install phones anywhere. It puts our software on your infrastructure and steps back.

Burrow works with any Kubernetes cluster, so the one you install into is a choice you make, not one we make for you. If you already run on DigitalOcean, a managed provider, or your own hardware, that is where Burrow goes. You are not migrating onto our ground to use it; it comes to yours.

Where your things actually live

It is worth being specific, because "self hosted" gets used loosely. When you install Burrow, everything of substance sits inside your cluster:

  • Your app and its traffic. Your services run on your machines. Requests come in and responses go out without ever passing through anything we run. We are not a proxy in front of your app, so there is nothing for us to see even if we wanted to.
  • Your logs and metrics. They are collected and stored in your cluster. When you run burrow app logs web or query metrics, you are reading data that never left the environment you own.
  • Your secrets. You set these at your own terminal, and they live in your cluster. Burrow never asks you to paste a secret into a chat, an agent, or a form we host. More on that below, because it is the sharpest example of the whole stance.
  • Burrow's own state. The record of your apps, releases, and guardrail decisions lives in a database that runs inside your cluster too, next to everything else. It is not a copy we keep on our side.

The line between "your stuff" and "our stuff" stays simple because there is barely any "our stuff" at all. We ship you software. You run it. The data it touches is yours from start to finish.

We never phone home

Burrow does not ship your data anywhere. Your app's traffic, your logs, your metrics, your secrets: they live on your cluster and stay there. There is no telemetry pipeline quietly reporting your usage back to us, because we are not in the path of your production traffic and we are not collecting a profile of how you run.

That is not a setting you have to find and switch off. It is the default, and it is the design. The value of Burrow is that it operates your infrastructure well, not that it watches you do it.

The secret handling is where this gets concrete. When you set a secret, the value stays at your terminal and inside your cluster. It is never printed back, never written to your shell history, and never logged. This matters most when you put an AI coding agent to work on your infrastructure. The agent operates through a narrow channel that holds no cluster credentials of its own, and secrets never cross it. The agent can confirm that a key like DATABASE_URL exists, so it knows the app is configured, but it cannot read the value, and neither can we. Your code never crosses that channel either. The agent builds a container image with ordinary tooling, pushes it to a registry your cluster can pull from, and deploys by reference. Only the reference and small metadata travel; the source stays with you.

No lock in, by construction

The real test of lock in is what happens when you leave. So here is the honest answer: delete Burrow, and your apps keep running.

Your apps are deployed as standard container images on infrastructure you own. Burrow orchestrates the deploys, the rollbacks, the guardrails, and the addons, but it does not wrap your app in anything proprietary that only we can unwrap. Take the tooling away and what remains is a normal set of running services on a cluster that was yours the whole time.

Two things make that more than a promise. First, Burrow is open source under Apache-2.0. You can read exactly what it does, run it without asking anyone, and keep running it whatever happens to us. A company can disappear; a license you already hold does not. Second, the images you deploy are ordinary container images and the cluster is an ordinary Kubernetes cluster. Point your existing image references at any other tooling and they run the same, because there was never a Burrow specific wrapper around them to unpick. Migrating off is not a rescue operation. It is just deploying the same images a different way.

Your addons travel with you too. When you bring a database into the cluster as an addon, it runs on your machines, and its data is yours. Burrow can take a backup and restore from one, but the backups land in storage you control, not in a vault we hold. If you ever walk away from Burrow, the database is still sitting there on your cluster with your data in it, exactly as it was, because it never lived anywhere else. The backup you took last night is a file on your storage that any standard tool can read, not a snapshot format only we can open.

burrow addon backup   db          # a backup, into storage you own
burrow addon backups  db          # the ones you have

The migration story is deliberately dull, which is the highest compliment you can pay it. There is no export tool, because there is nothing trapped to export. Your images are already standard container images in a registry you control. Your data is already in databases on your cluster. Your app is already running on Kubernetes. To move off Burrow you keep doing all of that with different tooling. Nobody has to rescue anything from us, because we were never holding it hostage.

We want you to stay because Burrow is genuinely the calmest way to operate your own infrastructure, not because leaving is painful. Keeping the exit cheap keeps us honest. You keep root the whole time, and the door is always unlocked from the inside.

Why we built it this way

It would be easier, commercially, to run your app on our platform. That is the model most of the industry uses, and the reason is not subtle: when you hold the credentials, sit in the traffic path, and store the data, you own the customer. Leaving is expensive, so people do not leave, so the revenue is sticky. Lock in is not usually a villain twirling a moustache. It is the natural shape a business takes when nobody decides otherwise.

We decided otherwise, on purpose, up front. The whole architecture is arranged so that the sticky version is not even available to us. We are not in your traffic path, so we could not build a usage profile even if we wanted the data. We do not hold your cluster credentials, so we could not lock you out even by accident. Your apps are plain container images, so there is no proprietary format we could grow you dependent on. The decisions that would let us trap you are ones we gave up on the way in, which is the only kind of promise worth making. A promise you could break but choose not to is weaker than one the design will not let you break at all.

That choice costs us the easy moat, and we think it buys something better: a tool people run because it is genuinely the calmest way to operate their own infrastructure, not because the exit is welded shut. If Burrow is only worth keeping when leaving is painful, it was never worth keeping. So we made leaving painless and put the weight on being good instead.

The questions people actually ask

Do you see my production traffic? No. Burrow is not in the request path. Traffic goes straight to your app on your cluster and never touches anything we run.

Can you read my secrets? No. Secrets are set at your terminal and live in your cluster. They are never printed, logged, or sent anywhere, and the agent channel cannot carry them. We can no more read them than a stranger could.

What happens to my apps if Burrow the company goes away? They keep running. They are standard container images on your own cluster. And because the software is open source and Apache-2.0 licensed, you keep the right to run it regardless.

Is there a paid tier that phones home? The not phoning home part is not a plan tier, it is the architecture. We are not in your traffic path and we do not collect a usage profile, so there is nothing to gate behind a plan.

How hard is it to leave? As hard as pointing your image references somewhere else. There is no proprietary format to export and no data to extract from us, because we never held it.

Do I need to trust a claim, or can I check it? You can check it. Burrow is open source, so the code that runs on your cluster is code you can read. The "never phones home" and "never reads your secrets" parts are not marketing you have to take on faith; they are behavior you can inspect in a codebase you already have a copy of.

Where do my logs and metrics actually sit? On your cluster. When you read them with burrow app logs or a metrics query, you are pulling from storage inside the environment you own. Nothing is mirrored to us, so there is no second copy anywhere for us to lose or leak.

Owning it means owning the bill too

Keeping root cuts both ways, and that is the honest part. Because it is your cluster, it is your cloud bill: you pay your provider directly for the machines your apps run on, at their rates, with no markup passing through us. That is the deal that makes the rest of it true. If we ran your app on our platform, we would hold the credentials, see the traffic, and set the price. Because you run it on yours, none of those are ours to hold. You own the cluster, you own the bill, and you own the decision to leave whenever you like.

There is a quieter benefit to paying your provider directly: your costs are legible in the same place all your other infrastructure costs already are. You are not reconciling a separate Burrow invoice against usage you cannot fully see. The machines are on your cloud bill at your provider's rates, and Burrow is the software operating them, not a meter running on top of them. When the thing you install does not sit in your traffic path and does not hold your data, it has no natural place to charge rent, and that is exactly the point.

Questions about running this on your own terms go to hi@burrow-cloud.dev.