For a long time, my default reflex for publishing anything web-related was pretty automatic: repo, Vercel, domain, done. And to be clear, I still think Vercel has one of the best deployment experiences ever built for frontend work. You import a project, it detects the framework, gives you preview deployments per branch, and five minutes later you have something online.

But the more I have moved small APIs, redirects, scheduled jobs and static sites with a bit of logic, the more obvious it becomes that Cloudflare Workers is playing a different game. I am not saying “better for everything”, because that almost never exists. I am saying that for a lot of modern projects, the combination is very hard to beat: cheap, fast, global, and with a bindings ecosystem that fits really well with how I build today.

What I like about Workers

The basic idea is simple: you write a function that runs close to the user, on Cloudflare's network, and responds without you thinking too much about servers. That already sounds good, but the real fun starts when you connect the pieces: Workers Static Assets for serving a site, R2 for files, KV for simple data, Durable Objects for coordinated state, Queues for background work, Cron Triggers for scheduled tasks, and D1 if you want managed SQLite.

That changes how I think about small products. Instead of thinking “I need a backend”, I often think “I need a tiny Worker with two bindings”. For webhooks, internal APIs, RSS endpoints, build tasks or personal tools, that model is very comfortable.

Then there is the pricing, which is where Cloudflare becomes especially interesting. Today, the Workers free plan includes 100,000 requests per day. The paid plan starts at USD 5 per month per account and includes 10 million monthly requests plus 30 million CPU milliseconds. Beyond that, extra usage is USD 0.30 per million requests and USD 0.02 per million CPU milliseconds. Cloudflare also does not charge separately for Workers data transfer. For small and medium projects, that is a huge relief.

Compared with Vercel

Vercel is still incredibly convenient, especially if you work with Next.js and want previews, deep framework integration and a polished experience for teams. I would not call it bad, because that would be unfair. If I were building a SaaS tomorrow that was heavily centered on the Next.js App Router and I wanted a team to move quickly, Vercel would still be on my shortlist.

The difference is the mental model and the billing model. Vercel Pro costs USD 20 per user per month and includes usage credit, but then more dimensions enter the picture: function invocations, active CPU, provisioned memory, transfer, edge requests, image optimization and so on. It has spend controls, yes, but the bill becomes harder to estimate once the project starts moving.

With Cloudflare Workers, the starting cost feels more predictable. It does not make me think about developer seats for something that is often just me maintaining a tool. And if the project grows, the per-million request price is still very reasonable.

The downsides, because there are downsides

Workers is not Node “as is”. It has improved a lot, but you are still in a runtime with its own rules. There are memory limits, bundle size limits, and some Node ecosystem packages simply do not fit without changes. If your app depends on native binaries, obscure Node APIs, or libraries designed for a classic server environment, you may end up fighting the platform.

You also have to get used to wrangler, bindings, and the debugging workflow. Local development works well, but it does not always have that ultra-smooth “import it into Vercel and forget it” feeling for every framework. And for full Next.js apps with all their specifics, Vercel has an obvious advantage: it is their home turf.

One more important point: Workers bills active CPU, not traditional waiting time. That is great for many I/O-heavy APIs, but it does not mean Workers is the ideal place for heavy CPU jobs, large processing tasks or anything that wants tons of memory. For those cases, pick another piece.

Where I would use it without thinking too hard

I would use Workers for small APIs, webhooks, static sites with light SSR, smart redirects, lightweight proxies, scheduled jobs, internal tools, bot endpoints, RSS feeds, validators, mini dashboards and personal projects that I want to keep cheap for years.

I also really like it for products that start small. That stage where you do not know whether something will get 200 visits or 200,000 is exactly where a cheap global platform prevents a lot of premature decisions.

My honest summary

I like Cloudflare Workers because it does not make every idea feel like infrastructure. It feels more like a fast notebook for publishing logic close to the user. Vercel still feels superior when the project is very Next.js, very team-based, and very frontend-productivity-driven. But for small tools, APIs and sites with a little backend, Workers feels like one of the best deals in dev right now.

And the best part is that you do not have to marry a platform. You can keep the frontend wherever the DX feels better and move specific pieces to Workers when it makes sense. In my case, every time I do that, I end up wondering why I did not do it sooner.

Sources I checked