Should I Use Vercel in 2026? I Pay for My “No”
Yes, you should use Vercel. This website doesn’t - intentionally. It’s a positioning choice, not a technical one, except where data ownership is involved.
Who is speaking
I'm "The Architect". Nice to meet You!
It would be really nice to know something more about you to actually "meet", but according to sbozh.me privacy policy - we are not collecting any personal data intentionally. But guess who does?
Speaking seriously - I'm the one who will explain the technical motivations of sbozh.me platform. Below you will find my reasons to pay for my pain and VPS.
What is Vercel
Vercel is one of the best things that happened to javascript full-stack developers in the last decade.
It lets you deploy a website in minutes, often for free, with almost no configuration. You get global CDN, HTTPS, automatic builds, previews for every pull request, serverless functions, analytics, and a polished developer experience out of the box.
For many projects, Vercel removes infrastructure as a concern entirely. You write code, push it, and your site is live. Scaling, caching, and delivery are handled for you. In most cases, this is exactly what you want.
For personal projects, startups, landing pages, documentation sites, and even serious production workloads, Vercel is a rational and often optimal choice.
Why would anyone not use it?
VPS - Very Powerful Solution!
I actually prefer this abbreviation over the official one. It’s accurate. But with power comes responsibility - and unlike managed platforms, no one hides that from you.
A VPS is a Virtual Private Server. In practice, it means you rent a machine and treat it like your own. No guardrails and “magic”. Hardware, an operating system, and decisions you’re willing to live with.
You decide how the system is configured. You decide how traffic is handled. You decide what runs, when it runs, and why it runs.
Nothing is automatic - and that’s the point.
Where platforms like Vercel remove infrastructure from your concerns, a VPS makes infrastructure unavoidable. You don’t deploy to a platform; you build one. You own the network, the processes, the data flow, and the failure modes.
This is slower. More painful. Easier to get wrong.
But it also means nothing happens without your consent.
No surprise limits. Only your architecture. Clear analytics which you design. No policies changing underneath your application.
You pay with time, attention, and responsibility. And in return, you get control.
That trade-off is why this site runs on a VPS.
Pros to use Vercel for me
Spoiler: there are far more pros than cons. It's almost like there are no reasons to not use Vercel. Yes, I would pay a bit more, but it's not a question when you are building your personal startup, right?
I will build this topic simply by enumerating things that sbozh.me is not having yet, but would have with Vercel
- Content Delivery Network
- User interface for deployments and rollbacks
- Clear backup strategy
- Security backed by multiple world-known companies
- Infrastructure sponsored by Tech Leaders across the world
- My Web App image build faster (~3.5 min vs ~0.5 min with Vercel)
- It's currently not possible to create
sourceMapbecause of memory limits on my VPS (I guess wouldn't be a thing with Vercel) - I would save roughly 18 hours on solving deployment issues for sbozh.me*
If sbozh.me were only about publishing content quickly and reliably, this post would end here.
Which makes the situation uncomfortable.
Because despite all of this, I still chose not to use it.
I chose to build a sandcastle I can maintain myself,
instead of living in a permanent one I don’t control.— The Founder
Pros to Use a VPS for Me
In practice, my infrastructure would not stop at Vercel anyway.
sbozh.me already relies on several self-hosted services: Directus as a CMS, Umami for analytics, and GlitchTip for error tracking. Each of these could be outsourced - but they aren’t, and that choice is intentional.
Data Ownership
If you read the Terms of Service and Privacy Policy of platforms like Vercel carefully, you will find nothing shocking - and that’s the point. The model is fair. The pricing is generous. And yes, free usage is subsidized by data.
For me, the open questions are not about pricing, but about ownership. Analytics, logs, traffic patterns, build artifacts, and sometimes even intellectual property become part of someone else’s system.
That is my strongest “no”.
With a VPS, data stays where I put it. Nothing is collected by default. Nothing leaves the system unless I explicitly allow it. This aligns with both my personal preferences and the privacy guarantees of this site.
Learning Curve
sbozh.me is about building in public.
I want to show how systems evolve, scale, and occasionally break. While doing that, I’m also learning. At some point, this setup will include orchestration, automation, and eventually a Kubernetes-like environment - not because it’s required, but because it’s educational.
I don’t just want to use a platform like Vercel.
I want to understand how such platforms are built.
A VPS makes that unavoidable.
Demonstration
Maintaining this platform is also a form of demonstration.
Configuring a deployment on Vercel is efficient - but it’s not very interesting to me. Designing infrastructure with Terraform, automating provisioning, and being able to recreate the entire system on a different VPS within minutes is.
This approach reflects how I think about systems, trade-offs, and long-term maintainability. If you find the scripts useful, feel free to copy them.
They exist to be shared.
Conclusion
If you would ask any Software Architect about how you should deploy Next.js app - 99.9% would answer Vercel.
But I'm here to get you sbozhed and that's why we will use a Very Powerful Solution.
— The Architect
Attribution
- Initial draft structured with ChatGPT (GPT-5.2).
- Refined with Anthropic Claude Opus 4.5.
- Image prompt by Claude, generated with Midjourney.
"*" - Not 18 hours on this specific issue - but Vercel includes most of what I self-host out of the box, so infrastructure debugging would be minimal.