Deploy Global Infrastructure for Free on Cloudflare

The most expensive part of shipping your first product is usually the part before you write any product code. You decide to validate an idea, and the internet tells you to learn AWS, stand up an EC2 instance, configure nginx, containerize with Docker, wire up a reverse proxy, and manage TLS certificates. By the time the environment is ready, the momentum that made you want to build the thing is gone. A lot of good ideas die in the setup, not the execution.

There's a category of tooling that erases most of that, and it's worth understanding not just as a convenience but as a genuinely different deployment model. Cloudflare Workers and Pages let you go from writing code to running it globally in minutes, for zero dollars — and the reason it's fast isn't that someone hid the servers from you. It's that there are no servers for you to manage in the first place.

A different model, not a cheaper VPS

The mental model most builders bring to "hosting" is the rental model: you rent a box, you're responsible for the box. Even the excellent free Oracle VPS is still, fundamentally, a box you own and maintain — you patch its OS, you configure its web server, you keep it from being reclaimed for idleness. That's the right tool for some jobs. It is not the fastest path to a public URL.

Workers is a different animal. It's serverless compute at the edge: you write a function in JavaScript or TypeScript, run one deploy command, and your code is live simultaneously across Cloudflare's network of roughly 335 edge cities. There is no instance to size, no OS to update, no nginx config, no certificate to renew. A request from a user in Tokyo runs your code on a machine in Tokyo; a request from São Paulo runs it in São Paulo. Cold starts are near-zero because the runtime is already warm everywhere.

Here's the contrast laid out plainly:

The point isn't that one is strictly better. It's that they answer different questions. A VPS answers "where does my long-running process live?" Workers answers "how do I run this code close to every user without thinking about infrastructure at all?" For a solo founder trying to validate an idea before investing in it, the second question is almost always the one you're actually asking.

Workers isn't a cheaper server. It's the absence of a server — your code runs in 335 cities and there's nothing to patch, size, or keep alive.

Where the free tier actually stops

Free tiers are only useful if you know where the ceiling is, so you can judge whether you'll hit it before it matters. Cloudflare's Workers free plan gives you 100,000 requests per day. The honest question is whether that's a real constraint for what you're building, and for a pre-product-market-fit product the answer is almost always no.

Do the arithmetic on 100k requests a day. That's roughly 3 million requests a month. If every visitor to your site triggered ten Worker invocations — a generous estimate for anything short of a chatty single-page app — you could serve hundreds of thousands of page views a month before the free tier became a wall. A product that's still figuring out whether anyone wants it does not have that traffic. By the time 100k requests a day is a real constraint, you have a real product and a real reason to pay — which is exactly the order you want those things to happen in.

This is the free-tier design that actually serves builders: generous enough that the constraint arrives only after success, not before it. You're not rationing invocations while you're trying to find out if the thing works. You're shipping freely and only meeting the meter once the meter means you've won.

Pages is the Vercel-equivalent, and it's the same primitive

Workers handles compute. Cloudflare Pages handles the frontend, and it's the piece that will feel familiar to anyone who's used Vercel or Netlify. You connect a GitHub repository, and every push triggers an automatic build and deploy. It supports the frameworks you'd expect — React, Vue, Next.js, Astro, and the rest — and it generates a preview URL for every pull request, so you can review a change at a real link before it merges. If you've ever wanted git push to be your entire deploy pipeline, this is that.

The detail that ties the whole platform together, and the one most people miss, is this: Pages Functions and Workers are the same underlying primitive. When you add server-side logic to a Pages project — an API route, a form handler, a piece of dynamic rendering — you're writing a Worker. Cloudflare just calls it a Pages Function because it lives inside a Pages project. Same runtime, same edge network, same execution model.

That collapses a distinction that other stacks keep rigidly separate:

• Pages serves your frontend — the HTML, CSS, and client-side JavaScript.
• Pages Functions, which are Workers, serve your backend API.
• Both live in one project and deploy together, in a single push.

There's no separate backend service to stand up, no CORS dance between a frontend on one host and an API on another, no second deploy pipeline to maintain. Your frontend and your backend are one project, one deploy, one URL space. The front half is static assets served from the edge; the back half is a Worker handling /api/*; and they ship in the same wrangler deploy or the same git push.

Why this matters for how you build

The deeper consequence of all this is about sequencing, not cost. When standing up infrastructure is a multi-day project, you tend to do it once, commit to it heavily, and build a lot before you've learned whether the direction is right — because re-doing the infrastructure is painful. When infrastructure is one command away, you can afford to be wrong. You can ship a thing, watch it fail to get traction, and throw it away without mourning the setup work, because there was no setup work.

For an AI-native solo founder, that changes the tempo of building. You're generating code quickly with agents; the bottleneck was never writing the code, it was everything around getting it live. Remove the deployment friction and the loop tightens to: have an idea, build it, put it in front of people, learn, repeat — with each turn of the loop measured in minutes of infrastructure work, not days. The platform stops being something you configure and starts being something you barely notice.

• Reach for Workers/Pages when you want something public fast, you don't want to own a server, and your workload is request-shaped (APIs, sites, webhooks, edge logic).
• Reach for a VPS when you need a long-running process, a full OS, a persistent daemon, or software that expects a traditional Linux box.
• Use both without guilt — a Pages frontend talking to a Worker API, with heavier or stateful jobs on your free Oracle box. They compose.

The old advice — learn AWS, configure nginx, containerize everything — was never wrong, exactly. It was just answering a question a first-time builder wasn't ready to ask yet. The question you're actually asking is "how do I get this in front of people this afternoon?" Cloudflare's answer is: write the code, run one command, and it's live in 335 cities for free. Everything else is a problem for after you've found out whether anyone wants it. And finding that out is the next piece — a real, working page, live worldwide, in half an hour.

---

Part of the Vibe-entrepreneurs series on solo builder infrastructure. Next: Build a Waitlist Page in 30 Minutes, Zero Servers. See also Oracle's Always-Free Tier: The Server Everyone Forgets and Ship a Static Site With Nothing But git push. More builder insights.