Cloudflare's Free Tier Is a Trap for Some Side Projects
Recently, I built a few small projects with AI. Naturally, a need arose: put them online so others can see them directly, or so I can open them anytime from anywhere.
Buying a server for deployment felt too heavy for these personal micro-sites. Looking around, many people recommended Cloudflare: free, easy to deploy, and low-maintenance. So I went through the whole process myself.
After using it, it really is sweet. Pages, Workers, and Tunnel simplify the journey from localhost to the public internet quite a bit. There's also a corresponding CLI called Wrangler, which is easy to use and can even let an AI agent handle deployment.
Of course, there are plenty of pitfalls too. Access from mainland China, free-tier limits, R2 requiring a payment card, Containers obviously costing money at a glance… After all the tinkering, I realized Cloudflare is great, but it's not a silver bullet.
This is a summary: what's genuinely sweet, what's a dealbreaker, and which scenarios it suits and which it doesn't.
First, the free stuff: what's truly free, and what costs money
Many people are drawn to Cloudflare not because Workers is cool, but because it seems like you don't need to buy a server anymore and can skip all the hassle of filing for an ICP license.
But "free" needs to be broken down. Cloudflare has many products; you first need to understand what each service does, then see which are truly free, which have usage limits, and which cost money the moment you touch them. The table below lists them in this order:
| Service | What it does | Free vs Paid |
|---|---|---|
| CDN + DNS + SSL | Domain resolution, global acceleration, automatic HTTPS | Basically unlimited traffic, queries, and certificates |
| Pages | Host frontends / static sites, can connect to GitHub for automatic deployment | Unlimited sites, bandwidth generally not a bottleneck for personal use; free build count ~500/month, upgrade needed if exceeded |
| Workers | Run lightweight backend / API / gateway logic | Free ~100k requests/day; paid plan starts at $5/month |
| R2 | Object storage for images, files, static assets | Must bind a payment method to activate; free includes 10GB storage/month, egress traffic is free; pay-as-you-go beyond that |
| D1 | Serverless SQL database | Free ~5GB storage, daily read/write limits; charges for reads/writes and storage beyond limits |
| KV | Key-value store, suitable for config, caching, simple state | Free ~1GB, daily read/write limits; larger quotas on paid plans |
| Tunnel | Intranet penetration, securely expose local/home services to the internet | Tunnel itself is free, number of tunnels and connections basically unlimited |
| Containers | Run full Docker containers at the edge, handle heavy tasks Workers can't do | No free tier; must first activate Workers Paid ($5/month minimum), then billed by usage |
For personal blogs, demos, and small tools, the free tier is usually enough. Once you need heavy computation, high concurrency, or running containers, you start hitting your wallet.
Additionally, although R2 has a free tier, you must bind a payment method to activate it. For users in mainland China, many of the supported payment methods are unusable domestically.
The genuinely sweet parts
1. The free tier combo can actually support a small site
Domain resolution, CDN, HTTPS, static hosting, lightweight APIs, object storage, intranet penetration — all available in the free tier.
Before, setting up a small project meant: buy a VPS, install Nginx, configure certificates, open ports, bind domains, deal with ICP filing. Now the common path is: register an account, click deploy.
For personal websites and demo sites, it really saves a lot of effort. This is why many people call Cloudflare the Cyber Bodhisattva.
2. Direct GitHub connection, push code to go live
Cloudflare integrates smoothly with GitHub. Pages and Workers can both connect directly to your repository: authorize it, select the project, and every subsequent push basically triggers automatic build and deployment.
This is especially suitable for people using AI to code and iterate. The code stays on GitHub, and the live version updates along with it, no need to re-upload manually each time. This workflow is much lighter than setting up your own CI.
3. Wrangler: once installed, even an Agent can operate it
Cloudflare's official CLI is called Wrangler, and the command is wrangler.
After installing locally and logging in, deploying Workers, managing R2, viewing logs, and configuring Tunnels can all be done in the terminal. This is particularly sweet for people now using Agents like Cursor or Codex: no need to click through the Dashboard every day; just throw commands and configs at the Agent, and it can deploy, change settings, and troubleshoot for you.
4. Workers: pretty good for lightweight backends
Workers are good not mainly because they can run JS, but because deployment is hassle-free and they run close to the user. Code is deployed to edge nodes, and requests execute nearby. Tasks like login verification, simple APIs, and request forwarding are very suitable.
But its boundaries are also very rigid. Suitable for fast-in, fast-out light tasks, not for heavy lifting. For example, transcoding a video, compressing an image, running complex data processing, or using a browser to automatically scrape web pages — Workers basically can't do these things.
The reason is simple: Workers run inside a V8 sandbox, not a complete Linux server, nor a Docker container. Memory is also limited, and you can't install tools that require a full operating system or native programs. To do this kind of heavy work, you usually need another approach, or use the Containers mentioned later, which cost money.
5. Tunnel: intranet penetration is very convenient
Showing a local demo to others, accessing a home NAS externally, needing a webhook callback without exposing the origin server IP. Before, this usually meant a public IP, port forwarding, certificates, and firewalls.
Domestically, people more commonly encounter solutions like PeanutHull or NetEase UU Remote. UU Remote seems decent in recent years, relatively more stable. But they are still the vendor's own penetration channels, requiring various configurations and more or less some tinkering.
Tunnel takes a different approach: the machine actively connects out, no inbound ports are opened, the origin server IP is not directly exposed, HTTPS and protection are included by default, and it's free. Users don't need to perceive these internal details; it just works like a normal URL.
In comparison, Tunnel is more convenient. Temporarily showcasing something from your own computer, accessing a home NAS externally — for these scenarios, Tunnel is a game-changer.
The not-so-good parts
1. Access from mainland China is the biggest practical problem
If your users are mainly in mainland China, this is a hard limitation. Overseas access is often smooth, but domestically it can be slow, unstable, or even occasionally inaccessible. The gap varies significantly between different ISPs and at different times.
So: For going global, global users, or personal experiments, it's great; if users are mainly domestic and require stable access, don't expect to solve everything painlessly with just this.
2. Heavy lifting requires Containers, which cost money
As mentioned, Workers can't do heavy lifting and need Containers to fill the gap. They can fill it, but Containers have no free tier and require activating the Workers Paid plan first.
A simple comparison:
| Workers | Containers | |
|---|---|---|
| Nature | V8 isolate, lightweight edge function | Full Linux container |
| Can run | Mainly JS/TS/WASM | Python, Go, FFmpeg, libraries with C extensions |
| Startup | Almost no cold start | Cold start commonly 1–3 seconds |
| Suitable | High frequency, lightweight, low latency | Heavy tasks, special runtimes, isolated execution |
| Cost | Has a free tier | No free tier, requires $5/month minimum |
The correct usage is usually: Worker as the entry point and validator, then offload heavy tasks to Containers.
But for individual users, Containers require payment, and $5/month isn't exactly cheap for a small site.
3. Card binding and payment are unfriendly for domestic users
Services like R2 and Containers require binding a payment method to activate, even if R2 has a free tier.
The available payment methods are basically all foreign. There's no domestic Alipay, WeChat Pay, or UnionPay. Therefore, it's not friendly for domestic users, who usually need to apply for a Visa/Mastercard domestically.
This single point deters many people in China.
4. Local paths and environment require specific adaptation
A project that runs perfectly locally sometimes crashes immediately when deployed to Cloudflare. A very common reason: the code has hardcoded local paths, or reads/writes assuming a local disk and local environment by default.
Cloudflare is not your own computer. Workers and Pages don't have a freely usable local filesystem; configs, secrets, and file storage often need to be switched to platform capabilities like environment variables, KV, or R2. One set of code for local, another for online, requiring environment checks and adaptation in the code.
This isn't hard to change, but it's often forgotten before deployment. Especially for projects quickly cobbled together with AI, full of local paths, temporary files, and relative directories, you only realize the changes are needed at deployment time.
Which scenarios are suitable, and which are not
My own judgment is simple:
Suitable:
• Personal sites, documentation sites, demos, MVPs, portfolios — the free tier is basically enough • Code is already on GitHub, want push-to-deploy • Users are mainly overseas, or doing personal experiments and testing the waters for going global • Temporarily showcasing local projects externally, accessing a home NAS externally — Tunnel is more convenient
Not very suitable:
• Users are mainly in mainland China, and require instant, stable, low-latency access • Need to transcode video, run heavy computation, automatically scrape web pages, but don't want to pay for Containers • Projects heavily rely on local paths and local disk, and you don't want to adapt the environment • Heavily depend on services requiring verification like R2, but can't easily bind a Visa/Mastercard
In short, my experience is: Lightweight, going global, personal tinkering — very sweet; domestic main site, heavy tasks, heavy reliance on local environment — proceed with caution.