Cloudflare Free Tier: Everything You Can Do Without Paying a Dollar
Cloudflare's free tier handles more than most people realize. I use it across every project on PrintMoneyLab — six production services, multiple subdomains, automatic frontend deployments — and the monthly cost is $0. Not $0 for now. $0 permanently.
Most guides cover Cloudflare as a CDN. That's maybe 20% of what the free tier actually does. This post covers all of it: DNS, SSL, deployment, security, and the one configuration mistake that will break your site in a way that looks like a server problem.
DNS: One Dashboard for Everything
Every domain I own points its nameservers to Cloudflare. All DNS records — A records for servers, CNAME records for subdomains, MX records for email — live in one dashboard. Changes propagate in minutes.
What this looks like in practice with my setup:
Each subdomain points to a different backend. The blog runs on Blogspot. The API runs on Oracle Cloud. Static tools run on GitHub Pages. The flight compensation checker runs on Cloudflare Pages. One dashboard manages all of them. Adding a new subdomain takes 30 seconds.
SSL: The Setup That Takes Two Clicks (and One That Breaks Everything)
Cloudflare handles SSL certificates automatically. Add your domain, point nameservers to Cloudflare, and HTTPS just works. No certificate generation, no installation, no renewal reminders. The certificate covers your root domain and all subdomains.
The catch is the SSL mode setting. Cloudflare offers four options: Off, Flexible, Full, and Full (Strict). They sound similar. Picking the wrong one breaks your site.
I learned this during the x402 Protocol launch. I picked Full (Strict), my Oracle server had no certificate, and every request returned a 525 error. The site looked completely dead. Switching to Flexible fixed it in seconds, but finding the cause took an hour because the error message doesn't mention SSL mode.
Cloudflare Pages: Push to Deploy
This is the feature that replaced my entire frontend deployment workflow. Connect a GitHub repo, set the build command, and every push to the main branch deploys your site globally in about 90 seconds.
Setup takes under five minutes:
The free tier includes: unlimited sites, unlimited bandwidth, unlimited build minutes, preview URLs for every branch, and instant rollback to any previous deployment.
Preview URLs are worth highlighting. Every branch you push gets its own unique URL automatically. I test SpeedTap features by sharing preview URLs with friends before merging to main. No staging server to maintain. When I covered the full-stack build process in another post, the ability to test on real URLs before merging was what caught bugs before they hit users.
Rollback saved me once already. I pushed a SpeedTap update that hid the navigation bar on iOS. Instead of debugging under pressure, I opened the Pages dashboard, found the last working deployment, clicked Rollback. Fixed in ten seconds. Then I debugged calmly and pushed the corrected version when it was ready.
WAF: The Invisible Security Layer
Within hours of putting any new project online, attack logs start filling up. SQL injection probes, credential stuffing attempts, path traversal scans. None of these are targeted at me specifically — they're automated bots scanning every IP on the internet.
Cloudflare's free tier WAF (Web Application Firewall) blocks most of this before it reaches my server. I check the security analytics occasionally and see hundreds of blocked requests per day. The default rules handle common attack patterns without configuration. I've added a few custom rules through the dashboard for specific projects — rate limiting on API endpoints, geographic blocks on admin routes — but the defaults do most of the work.
Without Cloudflare, my Oracle Cloud instance would be absorbing all this traffic directly. With Cloudflare proxying in front, the server only sees legitimate requests. The load difference is measurable.
Origin Rules and Page Rules
Two features that do more than their names suggest.
Origin Rules let you change how Cloudflare routes traffic to your backend. The most common use: different subdomains to different ports on the same server. If your API runs on port 8000 and your bot webhook runs on port 8080, Origin Rules can route api.example.com to port 8000 and bot.example.com to port 8080 without Nginx.
Page Rules apply specific behaviors to URL patterns. Force HTTPS on all paths. Set aggressive caching for static assets. Bypass cache for authenticated routes. Each rule is configured in the dashboard — no server config files to edit, no deployment needed.
I use Origin Rules for port routing across multiple services on my single Oracle instance. One IP address, multiple subdomains, each hitting the right backend port. The alternative would be running Nginx as a reverse proxy, which works but adds a component to maintain.
What the Free Tier Doesn't Cover
Honest section. The free tier has limits, and knowing them prevents wasted time.
Cloudflare Workers: Serverless functions at the edge. The free tier gives you 100,000 requests per day. I haven't adopted Workers because my Oracle backend has enough capacity for current traffic, and adding another deployment target adds complexity I don't need yet. For lightweight API proxying or webhook handling, Workers would make sense.
Cloudflare R2: S3-compatible object storage with zero egress fees. Not part of the free tier in a meaningful way for production use. If you need to store and serve large files (images, media, datasets), R2 is competitively priced but not free.
Advanced WAF rules: The free tier WAF uses managed rulesets. Custom firewall rules are limited to 5 on the free plan. For most solo projects, 5 is enough. If you need complex security logic, the Pro tier ($20/month) expands this significantly.
Analytics retention: Free tier keeps 24 hours of detailed analytics. If you need longer retention, you'll need to supplement with Google Analytics or a similar tool. I run GA4 alongside Cloudflare analytics for this reason.
The Actual Monthly Savings
To put the free tier in perspective, here's what I'd be paying if I assembled the same capabilities from separate paid services:
The comparison isn't perfect — each paid service might offer more depth in its specific area. But for a solo builder running multiple projects, the breadth of Cloudflare's free tier is hard to match.
Setup Order for New Projects
If you're starting fresh, set up Cloudflare before anything else. The reason: every other piece of infrastructure assumes DNS and SSL are handled. If Cloudflare is in place first, pointing a new subdomain at a new backend takes 30 seconds. Adding HTTPS to a new service is automatic. Deploying a new frontend is one GitHub connection.
The sequence: sign up → add domain → update nameservers at registrar → wait for propagation (under an hour). After that, every new project starts with "add a DNS record" and everything else follows.
This is how my stack works, and it's the same order I described in the free tech stack overview. Cloudflare goes first because everything else sits on top of it.
More guides in this series cover Oracle Cloud setup, Claude Code workflows, and deployment automation. If you're using Cloudflare and have a setup trick not covered here, drop it in the comments.
Related guides in this series:
- Oracle Cloud Always Free ARM Instance: Setup Guide
- Building a Full-Stack App with Claude Code in One Day
- Claude Code for Non-Developers: What It's Actually Like
Disclaimer: This blog documents practical workflows based on personal experience. Nothing here is financial, legal, or professional advice.
Comments
Post a Comment