Can a 100K-User Startup Really Run for $0 on Cloudflare?
When developers hear “100K users”, our brain usually starts building infrastructure before the product even exists.
A backend server.
A database.
Cloud storage for images, PDFs and uploads.
CDN.
Monitoring.
Maybe Docker. Maybe Kubernetes, if we are feeling extra ambitious.
And suddenly our startup with zero customers already has an infrastructure diagram that looks like Netflix.
But for the right kind of application, you may not need most of that.
A startup with around 100K monthly users can potentially fit inside Cloudflare’s free tier.
Not every startup. And definitely not 100K people hammering your API every day.
But for a normal SaaS, admin platform, inventory system, internal tool or CRUD-heavy product?
It is worth doing the math before renting a server.
First, what exactly is a Cloudflare Worker?
If you normally build Node.js backends, think of a Cloudflare Worker as backend code that runs when a request comes in.
POST /api/orders
↓
Cloudflare Worker
↓
Validate request
↓
Read / write data
↓
Return response
The important part is that you do not manage the server running it.
Serverless does not mean servers disappeared.
It means managing those servers became Cloudflare’s problem.
You do not have to maintain a VPS, configure Nginx, keep Node alive with PM2, patch the OS or manually add more servers when traffic grows.
You write the logic.
Cloudflare runs it.
Then there is D1
Your backend still needs somewhere to keep data.
Cloudflare D1 is a serverless SQL database built around SQLite.
So this still looks familiar:
SELECT *
FROM orders
WHERE company_id = ?
Users, products, orders, inventory, permissions, settings — a lot of normal business application data can fit naturally here.
But serverless does not remove engineering.
A bad query is still a bad query.
Free infrastructure does not make bad SQL free.
Indexes and database design still matter.
Files? That is where R2 comes in
Images, PDFs, invoices, exports and user uploads do not need to sit inside your database.
Cloudflare R2 can handle those files.
So now the architecture starts looking surprisingly simple:
Frontend
↓
Workers
↓
┌───────────────┐
↓ ↓
D1 R2
Data Files
Cloudflare can also serve your frontend and static assets through its network.
For many applications, that is already most of the core infrastructure.
But can it really handle 100K users?
Here is where the headline needs some honesty.
“100K users” by itself does not tell us much about infrastructure.
Imagine an application with:
100,000 monthly users
Maybe around 10,000 use it on an average day.
If each active user generates around five dynamic API requests:
10,000 × 5
= 50,000 Worker requests/day
Cloudflare Workers Free currently allows 100,000 requests per day.
That traffic pattern can fit.
But change the application to 100K daily users making 20 API calls each:
100,000 × 20
= 2,000,000 requests/day
Completely different story.
So instead of asking:
Can Cloudflare handle 100K users?
Ask:
How many requests, database reads, writes and files will those users actually generate?
That is what really decides your infrastructure.
I started thinking about this while building a supply-management system
Recently I built a 15+ module supply-management system that is now used internally by a client’s team.
It has the normal things you would expect from a business application — different modules, business logic, database operations, user roles and day-to-day workflows.
I built it around Cloudflare Workers and related Cloudflare services.
And while building it, one thing became very clear:
A lot of applications do not actually need a traditional server.
Sometimes we choose one simply because that is the architecture we are already familiar with.
You also do not need to migrate your existing backend
This is one part of Workers that I think gets overlooked.
Maybe your application already looks like this:
React
↓
NestJS / Express
↓
PostgreSQL
That is fine.
You do not have to rewrite everything.
A Worker can sit in front of your existing application:
User
↓
Worker
↓
Existing API
And there are some genuinely useful things you can move there.
For example, you can cache safe, read-heavy API responses so every request does not have to reach your backend again.
That can reduce latency for users and reduce load on your existing server.
You can also use a Worker to:
validate JWTs or API tokens before forwarding requests
receive webhooks
transform headers or request URLs
proxy or combine third-party APIs
handle redirects
expose lightweight API endpoints
run scheduled tasks
That does not mean moving your complete authentication system or all your business logic into a Worker.
Sometimes the Worker is simply an extra layer that takes repetitive or edge-friendly work away from your main backend.
And that is a much easier way to start experimenting with Cloudflare.
Then there is the vibe-coding problem
We are living in the vibe-coding era.
Tell an AI:
“Build me a SaaS.”
And it will happily give you a frontend, backend, database, storage and deployment setup.
Sometimes you end up paying for four different services before understanding why you need any of them.
The problem is not AI.
The problem is stopping after:
“How do I build this?”
Ask another question:
“Does this application actually need this architecture?”
Could the frontend be mostly static?
Could the APIs run inside Workers?
Could D1 handle the data?
Could files live in R2?
Do I really need PostgreSQL?
Does this workload need a long-running server at all?
Do not only ask AI to build your idea. Ask whether your idea fits the architecture.
That question can save a surprising amount of unnecessary infrastructure.
So, is this Cloudflare stack right for every app?
No.
I would not blindly choose this architecture for CPU-heavy processing, massive databases, extremely write-heavy workloads, huge analytics pipelines, video processing or applications that depend heavily on PostgreSQL-specific features.
Workers are not a VPS.
D1 is not PostgreSQL.
And free tiers still have limits.
But for dashboards, SaaS products, inventory systems, internal tools, APIs and many normal business applications, this stack deserves to be considered much earlier than it usually is.
The real takeaway
I am not saying:
“Cloudflare can run every 100K-user startup for free.”
It cannot.
I am saying something more useful:
100K users does not automatically mean expensive infrastructure.
Before spinning up servers and five different cloud services, calculate what your application actually does.
Requests.
Reads.
Writes.
Storage.
CPU.
Then choose the architecture.
Sometimes the infrastructure you actually need is much smaller than the one you imagined.
