Serverless Is the Deepest Lock-In There Is

Serverless is sold as the ultimate freedom: no servers to manage, infinite scale, pay only for what you use. It is actually the deepest form of vendor lock-in in the whole cloud, because a serverless app is not portable code that happens to run on a provider. It is code welded to that provider's specific primitives, and prying it off is a rewrite, not a migration. I will make that case plainly, because the trap is real and most people walk into it smiling.

The tell is simple. Ask any serverless setup one question: could you run this on a different provider next month without rewriting it? For a truly serverless architecture, the answer is almost always no.

Why serverless locks you in deeper than a VPS ever could

A VPS is generic. It runs Linux, it runs your code, and any other VPS anywhere runs it the same way. Moving is copying files. There is nothing provider-specific to leave behind.

Serverless is the opposite by design. Your functions are wired into one vendor's event system, their function runtime, their identity model, their managed queue, their proprietary database, their API gateway. None of that exists anywhere else. Your business logic gets scattered across a dozen managed services that only speak to each other inside one account. The "no servers" promise is true; what they do not say is that you traded a server you could move for an architecture you cannot. That is the exact pattern I warn about in spot vendor lock-in before you sign.

The freedom is real until you want to leave

Give serverless its due. The developer experience early on is genuinely good. You deploy a function, it scales, you do not think about capacity. For a spiky workload at small scale, that is a real gift.

The bill for that gift comes due in two ways. First, at scale, per-invocation pricing on a busy app can cost far more than a box that would run the same load for a flat monthly number, and you cannot easily leave to fix it because leaving is the rewrite. Second, the vendor now sets your terms: pricing changes, deprecations, region availability, all decided by them, and your only leverage is a rewrite you will never prioritize. A dependency you cannot walk away from is not a tool. It is a landlord, which is why I insist on servers that cannot be held hostage.

What owning the same capability looks like

You can have most of the good parts without the trap. The genuinely useful thing about serverless is not the proprietary event mesh; it is that you do not want to babysit infrastructure. Fine. Get that from an owned stack instead.

A VPS with a process manager gives you always-on services without server babysitting. A job runner or a cron system on your own box handles the background and scheduled work that serverless functions cover. A reverse proxy routes requests. Your logic lives in ordinary code on a machine you control, using standard databases and standard queues that exist everywhere. You get the outcome, low operational effort, without pinning your architecture to one company. That is the whole argument I lay out in PaaS versus a self-hosted VPS.

When serverless is still the right call

I am not a zealot, so here is the fair boundary. If you have a genuinely spiky, unpredictable, low-volume workload, and the function is small and isolated, serverless can be the right tool. A webhook handler that fires a few times a day does not need a box. The lock-in on one tiny isolated function is cheap to undo.

The danger is not the single function. It is building your whole application out of them, until the architecture itself is the vendor's product and your code is just filler between their services. Keep serverless at the edges for isolated tasks. Never let it become the foundation. Where to draw that line is the same judgment I apply in the self-host versus managed cloud decision.

Own the foundation, rent the edges

The rule I run my portfolio by: own the load-bearing parts, rent only the swappable ones. My apps live on boxes I control, on standard databases, deployed by standard tooling. Anything I rent has to pass one test, could I replace it in a week without touching my core code. Serverless as a foundation fails that test completely, which is why it is not under any of my products.

I built my hosting stack, HostSSH, specifically so operators can get the low-ops feeling serverless sells without accepting the lock-in it hides. The point of owning your stack is that leaving is always a short walk. Serverless makes leaving a rewrite, and a rewrite you will never do is just permanent capture with better marketing.