Where to Deploy Your App in 2026: A Reality Check

Okay so here's the thing nobody wants to admit: choosing where to deploy your code in 2026 shouldn't be this complicated, but it is. And it's not because the technology is hard—it's because everyone's selling you their version of the truth without telling you what it actually costs.

Developer and YouTuber Theo (from t3.gg) just dropped a 37-minute breakdown of deployment options that cuts through the marketing speak, and honestly? It's the conversation we should've been having years ago. No sponsors (except his CI tool), no agenda, just someone who's been burned enough times to know where the traps are.

The Starting Point Everyone Gets Wrong

Here's Theo's opening move, and it matters: "If you don't know which of these you fit under, you should almost certainly start with the serverless options." He estimates that 98% of applications can run perfectly fine on serverless infrastructure. Not 60%. Not 80%. Ninety-eight percent.

That number should change how you think about deployment. The default question isn't "do I need serverless?" It's "am I in that 2% that doesn't?" And if you're asking, you're probably not.

But starting with serverless doesn't mean all serverless platforms are created equal. That's where things get interesting.

The Cloudflare Problem

Cloudflare Workers should be the obvious choice. They're fast, they're cheap, and they run your code on an edge network that makes traditional serverless look slow. The architecture is genuinely innovative—instead of spinning up containers, they run JavaScript in V8 isolates that share resources across deployments. Cold starts are near zero. You only pay for actual CPU time, not idle wall-clock time.

So why isn't everyone using Cloudflare? Because it's not actually running Node.js.

"Every time I use Cloudflare, I run into something because of this," Theo explains. "It's not running Node.js. It's running their JavaScript engine. And because of that, a lot of things don't work." File I/O? Broken. Image optimization libraries like Sharp? Nope. FFmpeg? Forget it. PDF parsing? Good luck.

The compatibility layers help with basic stuff—crypto works now, for instance—but the moment you need to do anything that involves native code or expects a real filesystem, you're in for a bad time. "I have been to hell and back for many projects trying to get Cloudflare to let me do something that involves any code that isn't in JavaScript," Theo says, "and every single time I gave up and moved to one of the other options."

Then there's the dashboard. Theo is unsparing here: "I actually think that the entire dashboard codebase should be deleted and restarted from scratch. There is no recovery at this point." He mentions writing seven pages of single-spaced notes documenting problems, which a Cloudflare exec then presented to the entire org. They're trying to fix things, sure. But when your deployment experience requires a seven-page bug report just to be usable, that's not a minor UX issue.

Oh, and about that "cheap" pricing? It's transparent until you hit enterprise scale, at which point free things might suddenly cost money. The egress that was free on the base tier? Maybe not free anymore. Know that going in.

The Vercel Tax (And Why People Pay It Anyway)

Vercel is the opposite experience in almost every way. The GitHub integration just works. The CLI makes sense. It runs real Node.js, so your entire npm ecosystem is available. The free tier is generous. The DX is, frankly, unmatched.

"They are still by far the easiest and most consistent way to deploy most apps," Theo admits. "Basically, everything I have shipped to the web over the last few years has been on Vercel."

But then there's the bandwidth thing. You know those viral "Vercel charged me $5,000!" tweets? Almost always bandwidth. Vercel's CDN is aggressively optimized for speed, which is great for your JavaScript bundles and HTML. It's terrible for large static assets. "If you're filling up your public folder in your project with a ton of big assets like 50 megabyte video files or 10 megabyte PNGs or 5 to 10 megabyte MP3s, that's going to cost a lot," Theo warns.

His analogy is perfect: "It's almost like you're trying to use a race car to pick up groceries. Not only is it going to fit fewer groceries, it's going to use more gas and probably cost you more maintenance." Don't put big files in your public folder. Use proper file storage. Problem mostly solved.

The other cost issue is seat pricing—$20 per developer per month adds up fast. But for most projects, the compute costs are actually lower than AWS Lambda because of Vercel's concurrency model. One instance can handle multiple requests simultaneously, which changes the math significantly.

The Netlify Middle Ground

Netlify sits somewhere between Cloudflare and Vercel. It's another Lambda wrapper, but with all the nice DX stuff—good GitHub integration, solid CLI, excellent open source support. Theo's never regretted using it, which is about as strong an endorsement as platforms get from people who deploy code for a living.

The main limitation is the same one AWS Lambda has: each request gets its own instance, which isn't great for modern concurrent workloads. Netlify's solution is robust background job and queue systems, which Theo actually praises. They were ahead of Vercel on workspace features, and the pricing was surprisingly reasonable.

It's a solid default if Vercel doesn't fit and Cloudflare's compatibility issues scare you off.

When You Actually Need Servers

Most of the video focuses on serverless because, again, 98% of apps. But what about that 2%?

Theo's take on traditional VPS providers like Hetzner and OVH is... pointed. Sure, they're cheap. Sure, people on Twitter will think you're cool for using them. But: "Your account can get cancelled at any time, especially with Hetzner." He's experienced it firsthand—flagged for using a Gmail account, couldn't deploy for ages. Production environments getting taken down over random policy changes. No integrations with modern tools. You're managing your entire deployment pipeline yourself.

The transcript cuts off before covering Railway, Render, and Fly.io in detail, but the pattern is clear: the choice isn't about finding the One True Platform. It's about understanding the tradeoffs and matching them to your specific needs and constraints.

What This Actually Means

Here's what strikes me about Theo's breakdown: it's not prescriptive. He's not saying "use Vercel" or "avoid Cloudflare." He's saying understand what you're optimizing for, understand what you're willing to deal with, and choose accordingly.

Want the easiest path with the best DX? Vercel, but watch your bandwidth. Want the cheapest option and don't mind compatibility headaches? Cloudflare, but test your entire stack first. Want something reliable and boring? Netlify's right there.

The real insight is that most of the internet advice about deployment comes from people solving their specific problem right now. Theo's trying to give you the mental model to solve yours. In 2026, with deployment options multiplying and marketing budgets growing, that might be the most valuable thing anyone can offer.

Zara Chen covers technology and politics for Buzzrag.