There is a moment in a lot of projects where you start to wonder whether you have outgrown your PaaS. The bill is climbing, you are bumping into limits, and you are eyeing the cluster you could run yourself. But self hosting has its own reputation for pain, so the question is real: which one is right for you, right now?
This is not a pitch to leave your PaaS today. It is eight honest questions to help you decide, from someone who thinks owning your infrastructure is worth it when the time is right, and premature when it is not. The core difference to keep in mind: a PaaS runs your app on their platform, self hosting runs it on yours.
1. Is your bill growing faster than your app?
PaaS pricing is convenient at small scale and unforgiving as you grow. Per seat, per project, per unit of usage, the meter climbs, and at some point you are paying platform margins on top of the actual compute. If you look at your invoice and most of it is the platform rather than the machines, that is a signal. Owning a cluster means you pay for the compute and get your money's worth from it, without the markup for running it on someone else's account.
If your bill is small and predictable, though, this question does not apply yet. Do not self host to save money you are not actually spending.
2. Do you keep hitting the platform's edges?
Every PaaS has a shape it is good at and edges where it says no. A background job that runs too long, a service it does not support, a networking setup it does not allow, a database it will not let you tune. If you keep filing your app down to fit the platform, you are paying for convenience with capability. Your own cluster does not have those edges, because it is just Kubernetes, and Kubernetes runs anything.
3. Do you care where your code and data actually live?
On a PaaS, your code and data live on their infrastructure, in an account you do not fully control. For a lot of apps that is fine. For some, it is not: you want your data on machines you own, no telemetry pipeline reporting your usage back to a vendor, and a clear line where everything on one side is yours. If that ownership matters to you, self hosting is the only version that actually delivers it. Your machines, your cloud bill, your root access.
4. What happens the day you want to leave?
This is the question most people skip until it is too late. The real test of lock in is what happens when you try to go. On some platforms, the deeper you integrate, the harder the exit, and you find out how deep the roots went exactly when you want them shallow. Self hosting on standard container images means your apps are portable by construction: they are normal services on a cluster you own, not something wrapped in a proprietary layer only the platform can unwrap. Take the tooling away and your apps keep running.
5. Are you willing to own day two?
Here is the honest cost of self hosting. A PaaS handles the operational grind for you: keeping things up, rolling out new versions cleanly, certificates, the boring resilience work. Own your cluster and that becomes yours. The first deploy is easy, everything after is the real job. This is the question that actually decides it for most people, because day two is where self hosting historically got painful.
The reason this question is less scary than it used to be is tooling. You do not have to choose between "a PaaS does the operations" and "I write YAML by hand forever." Burrow exists precisely to give you production grade day two operations, self healing, clean rollouts, certificates, logs, backups, on a cluster you own, driven by plain commands instead of a wall of Kubernetes. So the honest answer to this question is now "yes, if I have tooling that carries the day two weight." Which is the whole point.
6. Are you a Kubernetes expert, or do you refuse to become one?
Two kinds of people self host happily. Kubernetes experts who enjoy tuning the cluster, and people who never want to see it. The trap is the middle: capable developers who are not experts, who end up drowning in the operational surface area of raw Kubernetes because the standard tooling assumes you want to be an operator.
If you are in that middle, the deciding factor is whether your tooling lets you run real Kubernetes without becoming a Kubernetes person. You should be able to deploy, roll back, read logs, and publish at a domain without learning what an ingress controller is. If you have that, the "I am not an expert" objection stops being a reason to stay on a PaaS.
This is the objection that used to end the conversation, and it is the one that has genuinely changed. For years the honest advice to a capable but not expert developer was "stay on the PaaS, self hosting will eat you alive," because the only way to run your own cluster was to learn to operate one. That is no longer the only way. The middle path, running your own infrastructure while your tooling carries the expert parts, did not really exist a couple of years ago, and now it does. So if this question was the one keeping you on a PaaS, it is worth reexamining, because the ground under it has moved.
7. Do you operate through an AI agent?
This one is new and it changes the math. If your daily driver is an AI coding agent, self hosting used to mean the agent could write your code but not safely operate your infrastructure, so you leaned on a PaaS for the running part. That gap is closing. You can now point the agent at your own cluster and let it deploy, diagnose, and roll back, while guardrails you set keep it bounded: it moves fast in staging, and the risky prod moves come back to you for a sign off.
If you already trust your agent to write your app and you want it to operate the app too, on infrastructure you own, that is a strong pull toward self hosting, in a way that simply was not available a year ago.
8. Is now the right time, or are you optimizing early?
The last question is about timing, because the answer to every question above can be "yes eventually" and still "not yet." If you are pre launch with three users, self hosting is probably a distraction from finding out whether anyone wants the thing. A PaaS getting you live tonight is the right call. The time to own your infrastructure is when the bill is real, the limits are biting, the ownership matters, and you have day two tooling that will not eat your weekends. Not before.
A middle path most people miss
The question is usually framed as a one way door: you are on a PaaS, or you have crossed over to self hosting, and switching is a big scary migration. It does not have to be that dramatic. The two can overlap while you make up your mind.
A sensible way to test the water is to move one app, not your whole world. Pick something real but not your most critical service, stand it up on a cluster you own, operate it for a few weeks, and see how day two actually feels with proper tooling. You keep the rest on your PaaS the entire time. If owning the app turns out to be more work than it is worth for you right now, you have learned that cheaply, on one service, and you walk it back. If it feels good, you have a proven pattern to move the next app, and the one after that, on your own schedule.
That incremental path takes almost all the risk out of the decision. You are not betting the company on a migration weekend, you are running an experiment with a known cost and an easy exit. And because self hosting with good tooling keeps your apps as ordinary portable services rather than locking them into anything, the experiment stays reversible the whole way through.
What moving one app actually looks like
To make that concrete, here is the shape of the experiment with real commands, so "move one app" stops being an abstraction. Say you already have a cluster (on DigitalOcean, or anywhere else, Burrow does not care whose it is). You install Burrow into it once:
burrow install do-cluster
That points Burrow at your cluster context and stands up the control plane, the part that will hold the credentials and do the operating from here on. Then you build your app's image with your normal tooling, push it to a registry the cluster can pull from, and deploy by reference:
burrow app deploy web --image ghcr.io/you/web:1.0.0
Non secret config goes in with a plain command, and secrets you set yourself at your own terminal so their values never route through anything but the control plane:
burrow app config set web LOG_LEVEL=info
burrow app secret set web DATABASE_URL
If the app needs a database, you do not have to bring your own: an addon stands one up in the cluster and wires it in.
burrow addon install postgres
burrow addon attach postgres web
Then the day two operations you were worried about are one command each: burrow app status web to see health, burrow app logs web to read output, burrow app rollback web to get back to the last good release, and burrow app scale web 3 for more copies. Want it public at a domain with HTTPS? burrow domain add web app.example.com and Burrow handles the ingress and the certificate. None of this asked you to write YAML or learn what a control loop is. That is the day two weight being carried for you, on a cluster you still own outright.
If the experiment does not pay off, walking it back is just as cheap. The app is an ordinary container image on standard Kubernetes, so you point your PaaS at the same image and you are back where you started, having learned what you needed on one service instead of betting everything.
A few honest caveats
To keep this fair, a few things self hosting does not magically solve. You still own the cluster itself: the nodes, the upgrades, the bill from whoever rents you the machines. Burrow carries the app level day two work, not the cloud account. You are trading a platform's margin and its edges for a cluster you have to keep pointed in the right direction, and that trade is a good one only once the app side is genuinely easy, which is the whole reason the tooling question above matters so much.
And be honest about scope. Compute, deploys, rollbacks, logs, scaling, autoscaling, domains, and managed addons like Postgres and caching are the job Burrow does today. Finer grained controls such as per service resource limits are coming, not shipped, so if your decision hinges on one of those, check where it stands before you lean on it. The right time to move an app is when the things you actually need are the things that already work.
How to read your answers
There is no universal winner here, and anyone who tells you otherwise is selling something. Roughly: if you are early, small, and just want to be live, a PaaS is a fine place to be, keep shipping. If your bill is real, you are hitting limits, you care about owning your stack, and, crucially, you have tooling that makes day two manageable, self hosting stops being the hard road and starts being the obvious one.
The thing that has changed is that last clause. Self hosting used to mean signing up for the full operational burden yourself. It does not have to anymore. When the answers above start pointing toward owning your infrastructure, the question is no longer whether you can handle day two, it is which tooling carries it for you while you keep root.
