When to Leave Vercel for Your Own Box
When to leave Vercel and similar managed platforms for your own VPS: the traffic, cost, and control signals that mean you have outgrown convenience hosting.
Leave Vercel when the bill stops matching the value, when a feature you need runs into a platform wall, or when you have enough apps that per-project pricing turns into a tax. Not before. Managed frontend platforms are genuinely good at the start, and I tell people not to flee them on principle. Flee them on evidence. Here is the evidence to watch for and what to do when you see it.
The short version: managed platforms sell convenience per project, and convenience is worth paying for until the moment it costs more than the control you gave up. Learn to spot that moment.
The signals that you have outgrown managed hosting
Watch three meters. When any of them crosses over, it is time.
The bill meter. Managed platforms price per project, per seat, per build minute, per gigabyte of bandwidth. One app, cheap. Ten apps, and the invoice is a number that would rent a serious VPS fleet with room to spare. When your monthly bill exceeds what a couple of boxes would cost, you are paying for convenience you could reproduce, and I broke that curve down in the real cost of managed clouds.
The feature-wall meter. You need a long-running background job, a websocket server, a cron process, a binary the platform does not allow, or a database that lives next to your app instead of a network hop away. Managed frontend platforms push all of that off to other paid services. When your architecture is fighting the platform's shape, the platform is done being a help.
The control meter. You want a custom build step, specific region placement, or your data somewhere a managed platform will not put it. When you keep hitting "you cannot do that here," you have found the ceiling.
What leaving actually looks like
Less than people fear. A modern web app is a build output and a runtime. Moving it to your own box means running that same build on a VPS, putting a reverse proxy in front, and pointing DNS at it. That is a day of work the first time and an hour every time after, because the pattern repeats.
The parts people worry about, TLS and a global edge, you solve by putting a CDN in front, which I walk through in how to put Cloudflare in front of your own server. You keep the edge network. You just stop renting the compute behind it. And you set up a git-push deploy so shipping feels the same as it did before, which I cover in git push deploy on your own box.
When NOT to leave
I will argue the other side, because leaving too early is its own mistake.
If you have one app, spiky and unpredictable traffic, and no interest in ever touching a server, stay. The managed platform's autoscaling and zero-ops story is worth real money at that stage, and your time is better spent on the product. I made the honest case for staying in when managed hosting is the right call.
Do not leave because self-hosting is a badge. Leave because the numbers or the walls made the decision for you. Principle is a bad reason to take on operational work. Evidence is a good one.
Do it before you are trapped, not after
Here is the timing trap. The longer you stay, the more of your app gets built around the platform's specific primitives: their edge functions, their storage, their image handling, their environment model. Each one is a thread stitching you in. By the time the bill hurts, leaving is a rebuild instead of a move.
So make the call while the exit is still cheap. Keep your app portable from the start: a standard build, a database you could run anywhere, no hard dependence on a single vendor's proprietary features. That portability is the whole point of owning your stack, and it is the test I apply before signing anything, which I detail in what no vendor lock-in actually requires.
The move I made
I run my portfolio on my own fleet, front-ended by a CDN, deployed by git push. Adding an app costs me almost nothing marginal, because the platform is already there. That is only possible because I did not let any single app get welded to a vendor I would later have to pry it off of. I built that owned platform into a product, HostSSH, precisely so the move off convenience hosting is a pattern instead of a heroic migration.
Leave Vercel when the meters tell you to, not a day sooner and not a year later. Watch the bill, watch the walls, keep your app portable, and the exit stays a short walk instead of a long climb.