Everyone's Talking About Edge Computing, I'm Still on a $6/Month VPS — Here's Why

If you follow dev Twitter or infrastructure newsletters lately, you’d think a VPS was Stone Age technology. Everyone’s talking about edge functions, deploys running across hundreds of locations at once, faster cold starts, stories about latency dropping dramatically after moving from a single server to a global edge network. I’ve read enough of that to start wondering if I’m behind. So I went back and checked what my projects actually need, and the honest answer is: no, I’m not behind on anything. I just don’t have the problem edge computing was built to solve.
The problem edge computing solves is specific: global latency for traffic that’s actually global. If you’ve got an app with users spread across five continents and 200ms genuinely affects conversion or user experience, edge is the right call. But my clients, and this site of mine, run traffic that’s overwhelmingly from one region — Indonesia for most of my client work, and even for this blog the traffic isn’t large enough for cross-continent latency to be a real problem. Putting compute closer to the user solves a scale problem I don’t have.
Cost isn’t a simple “edge is cheaper” story either. Some edge function providers have free tiers that look appealing at first, but once traffic grows, billing based on invocations and compute-time gets genuinely hard to predict. My $6-a-month VPS is a flat rate — I know exactly what I’ll pay next month regardless of traffic, as long as I stay under capacity, and I never wonder “will this month cost more because of a spike.” For a solo developer on a tight budget, that predictability has its own value that rarely factors into per-request cost comparisons.
What I dislike most: debugging gets a lot harder once compute is spread across many locations. On a VPS, if something breaks, I SSH in, tail -f the log, reproduce it locally if I need to, everything lives in one place I fully control. On edge functions, debugging goes through a third-party observability layer, cold starts that vary by which region got hit, and an environment I can’t always reproduce exactly on my machine. A trade-off that rarely comes up in articles that only focus on latency benchmarks.
Vendor lock-in is real too, even though it’s not talked about openly very often. Code written for one edge functions platform is often not portable to another without a rewrite, because runtime APIs differ, compute limits differ, environment variable handling differs. A VPS is deliberately boring — Linux, Nginx, whatever language I want — and if I don’t like the provider, I move without rewriting a single line of application code. For a solo dev with no team to handle a major migration if a provider changes policy, that’s a freedom I’m not eager to give up.
This isn’t a blanket objection to edge computing. If I worked on a project with genuinely global traffic, or a technical requirement that needs compute close to the user — a latency-sensitive real-time feature for users spread across continents, say — I’d seriously consider it. It’s an observation, not ideological resistance: the dev tooling hype cycle often implies you’re behind if you’re not on the newest thing, when for most projects at my scale it’s a solution to a problem I don’t necessarily have.
There’s a factor that doesn’t get acknowledged enough: a single VPS taught me more about infrastructure fundamentals than any managed platform has. Configuring Nginx myself, managing TLS certificates myself, setting up a firewall myself — work a more abstract edge platform can hide from you. But because I did it myself, I understand what’s actually happening when something breaks, instead of trusting a provider dashboard that says “everything’s fine” when something’s actually wrong at a layer I don’t control.
I also suspect part of this hype is driven by companies that need a growth story for investors, not purely developer need. Nothing wrong with that — companies do need to grow — but it means I read edge provider marketing with the same skepticism I’d read anyone else’s marketing. “Everyone’s moving to the edge” is an easy claim to make and a hard one to verify, and I haven’t found concrete data suggesting it’s true for most use cases that look like mine.
I actually benchmarked cold starts myself before writing this, rather than trusting marketing claims. I deployed one simple endpoint to a free tier of an edge functions platform and compared its response time against an equivalent endpoint on my VPS, both tested against traffic from Indonesia. When the edge function was “warm,” it was fast, sometimes even a touch faster than my VPS. But when a real cold start happened — an endpoint that isn’t hit often — the latency was noticeably worse than my VPS, which is always on and always warm. For traffic that isn’t constant, like mine, an always-on VPS turned out more consistent than an edge function whose performance depends on how often it gets called.
I also talked to a few other freelancers who’ve moved to edge, and their reasons often weren’t purely technical. Some moved because the tooling ecosystem is what their team or client already expected, not because of a concrete technical problem a VPS couldn’t solve. Valid for them — if your working ecosystem is already heading that direction, going along makes sense. But that’s different from the claim that edge is objectively better for everyone, which doesn’t hold up, at least not for projects that look like mine.
I’m still on a VPS not because I’m reluctant to learn something new, but because it’s still the right fit for the scale and needs of my projects right now. If that changes — a client with genuinely global traffic, a real latency requirement — I’ll reevaluate without any pride attached. But until then, a boring, predictable $6-a-month VPS I can debug myself still wins.