What Cloudflare's Free Tier Actually Does for a Self-Hosted App

Someone recommends putting Cloudflare in front of a self-hosted app in almost every thread about VPS deployment, and almost nobody follows it up with what that actually means. "Cloudflare's free tier" gets said like a complete sentence, as if it's obviously either everything or nothing. It's neither. I run my own stack — a Contabo box, Coolify, a handful of Next.js apps and a Payload CMS — entirely behind Cloudflare's free plan, and it genuinely does more than $0 has any right to do. It also stops well short of what people assume, and the gap between those two facts is where self-hosters get burned.

This is a list of what's actually in the box, checked against Cloudflare's own documentation in September 2026, because free-tier feature lines move around every year and last year's blog post about this is already slightly wrong. If the hard part of what cloudflare's free tier actually does for a self-hosted app for you is organisational rather than technical, XenGrowth's operator guides is worth reading.

What do you get for $0, specifically?

Authoritative DNS, first. Point your domain's nameservers at Cloudflare and every A, CNAME, and MX record you'd otherwise pay a registrar's DNS panel to manage badly is now managed well, with an API, for free, permanently — this isn't a trial tier, it's the actual product Cloudflare built its business on top of. Universal SSL comes with it: a certificate issued and auto-renewed for your domain with no manual renewal, no certbot cron job, no 90-day expiry countdown to remember. That alone replaces a genuinely annoying piece of server maintenance.

Proxying traffic through Cloudflare's network — the orange cloud toggle — gets you unmetered DDoS protection at the network layer, a global CDN sitting in front of your one small origin server, and, as of the current free plan, a free managed WAF ruleset that blocks a real set of known attack patterns without you writing a single rule. Basic Bot Fight Mode is in there too: it fingerprints traffic that matches known bot patterns and issues a computational challenge, which meaningfully cuts down scraper and script traffic hitting a box that has no business serving that volume of requests. None of this is a teaser for a paid plan. It's the free plan, doing what it says.

• Authoritative DNS with an API — no per-record fee, no trial window

• Universal SSL, auto-renewed, no certbot cron job to babysit

• Unmetered DDoS protection at the network edge

• A global CDN cache in front of your origin

• A free managed WAF ruleset covering common attack patterns

• Basic Bot Fight Mode against known bot signatures

• Enough traffic analytics to see what's actually hitting the box, by country and by status code

Does Cloudflare actually hide my origin server?

Not by default, and this is the single most misunderstood part of the free tier. Proxying a DNS record means visitors reach Cloudflare's edge IP instead of yours, which is real and useful — but it only hides the origin from someone doing a casual DNS lookup. Your real IP is still sitting in old DNS history, in mail server headers if you're sending email from the same domain, in any subdomain you forgot to proxy, and in the certificate transparency logs for any SSL cert ever issued directly against that IP. Anyone motivated enough to look — and a scanner sweeping IPv4 ranges doesn't even need to be motivated — can often find it anyway. For the the operations side of this angle, see The XenGrowth resource library.

The part Cloudflare can't do for you is the part that actually matters: making your server refuse connections that didn't come through Cloudflare's network. That's a firewall rule you write yourself — the exact same ufw setup covers — restricting inbound 80/443 to Cloudflare's published IP ranges instead of the whole internet. Skip that step and someone who finds your real IP just connects to it directly, walks straight past every WAF rule and every bot check, and the free tier's protection was never actually protecting anything on that path. This is the gap I mean when I say the free tier does less than people assume: it's not that the features are missing, it's that half of "hiding your origin" is a step Cloudflare was never going to take for you.

How do I actually restrict my origin to Cloudflare's IPs?

Cloudflare publishes its IP ranges — both IPv4 and IPv6 — at a stable URL, and the fix is to pull those ranges into your own firewall rules and allow inbound 80/443 only from them, denying everything else on those ports. On the box I run this on, that's a ufw rule set generated from Cloudflare's published list rather than typed by hand, because the ranges do occasionally change and a stale allowlist quietly turns back into an open port. This is maybe fifteen minutes of setup, and it's the difference between "Cloudflare is proxying my traffic" and "Cloudflare is the only way to reach my server," which are not the same claim even though they get used interchangeably.

It's also worth saying plainly: this step is not a Cloudflare feature at all. It doesn't appear anywhere in the free-tier feature comparison because it isn't something Cloudflare ships — it's server configuration you do on your own box, using data Cloudflare happens to publish. I bring it up here specifically because most write-ups of "Cloudflare for self-hosting" stop at the orange cloud toggle and never mention that the toggle alone doesn't close this gap.

What does the free tier not include?

Three things bite people specifically, and none of them are edge cases. First, caching: the free plan's maximum cacheable object is 512 MB, and a free zone can't set an edge cache TTL below 2 hours via rules — so if your self-hosted app is serving a media library through Cloudflare's cache on the free plan, you're hitting a hard object-size ceiling, not a vague terms-of-service gray area. Second, the granular control people remember as "Page Rules" isn't there anymore in that form: legacy Page Rules were migrated to separate cache, redirect, and configuration rules, and Free gets a single-digit allowance in each category — 5 firewall/custom rules total. One app on one subdomain barely notices. Anyone running more than a couple of domains on one box notices immediately once a second app needs its own cache behavior. There is a longer treatment of AI agents and marketing automation in XenGrowth on governed AI marketing workflows.

Third — and this is the one that actually costs money if you get it wrong rather than just annoys you — Super Bot Fight Mode is Pro and above. Basic Bot Fight Mode challenges obvious bots with no configuration; Super Bot Fight Mode adds allowlisting for your own legitimate bots (payment webhooks, uptime monitors, search crawlers you want indexing you) and per-path rules. On the free plan, a legitimate integration that looks bot-like to Cloudflare's heuristics gets challenged the same as a scraper, and you can't carve out an exception without upgrading. I hit this once with an uptime monitor that started failing checks because Cloudflare decided its request pattern looked automated — which, correctly, it was.

Is the free tier still worth it if it stops there?

Yes, without much hesitation, for the specific shape of setup I'm describing: one person, one small VPS, a handful of apps that don't need per-path rate limiting or a media CDN. The free tier replaces a certificate renewal cron job, a chunk of DDoS exposure that would otherwise land directly on a €5.50/month box with no capacity to absorb it, and a meaningful slice of bot traffic — for the cost of a DNS change. I've measured what the CDN layer alone does to bandwidth and latency on this stack, and it's a bigger number than the "it's just a free CDN, how much can it matter" framing suggests, worth its own separate post rather than a paragraph here.

It's worth being honest about the counterfactual too. None of this replaces having a competent server configuration underneath it — Cloudflare's WAF blocks known attack signatures, not a badly configured app that trusts input it shouldn't. A free CDN in front of a server with an open database port is still a server with an open database port; the free tier adds a layer, it doesn't substitute for the layers under it. I'd rather a reader come away from this thinking "free tier plus a hardened origin" than "free tier instead of a hardened origin," because the second version of that sentence is exactly how people end up finding out the hard way what their real IP was the whole time.

Where it stops being enough is legible in advance, which is the useful part: the moment you need more than 5 firewall/custom rules, a bigger cacheable object than 512 MB, a shorter edge cache TTL than the 2-hour floor, or bot exceptions for your own integrations, you'll know exactly why you're paying, because you'll have hit the specific ceiling rather than a vague sense that "free" wasn't enough. That's a better position to upgrade from than most software's free tier leaves you in. On AI search, GEO and discovery specifically, XenGrowth on building one SEO and GEO content system is worth reading.

The free tier isn't a limited trial of the real product — it's the real product, minus the knobs a one-person setup mostly doesn't need yet.

What about analytics — is the free tier's data actually usable?

Enough to answer the questions a one-person setup actually asks day to day: requests by country, response codes over time, how much of your traffic Cloudflare's cache served versus passed through to origin, and a rough bandwidth-saved figure. It's not the retention window or the granularity a team debugging a specific incident at 3am would want, and it's noticeably shallower than what Business and Enterprise tiers unlock. But for the question I actually ask it — "did that traffic spike come from real users or a bot sweep, and did the cache absorb it" — free-tier analytics answers it every time I've needed it to. I don't think I've ever wished for more granularity than what's already there for a single small VPS; I've wished for longer retention, which is a smaller complaint than it sounds.

What would actually make me pay for Cloudflare?

Running more than one app that each need distinct cache and rule behavior on the same domain would do it — that's the 5-rule ceiling, and it's the most concrete of the free-tier limits because it's a hard number, not a vague quality gap. A legitimate integration getting mistaken for a bot with no way to allowlist it would do it too, since Super Bot Fight Mode exists specifically to solve that. Serving meaningful video or audio through the cache would push me to a plan that's actually licensed for it rather than quietly hoping Cloudflare doesn't audit the traffic. None of those apply to the stack I actually run today, which is exactly why the free tier is still the right call — not because paying would be wrong, but because nothing on the box currently needs what paying buys.

That's the actual test, and it generalizes past Cloudflare: a free tier is worth using exactly as long as its ceiling is higher than what you're currently doing, and worth paying past exactly when it isn't. The mistake isn't picking the free tier. It's not knowing where its edges are until you've already hit one in production.

Further reading from XenGrowth

• The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.

• XenGrowth on governed AI marketing workflows — what you'll learn: how the teams running AI marketing agents keep them governed and measurable.

• XenGrowth on building one SEO and GEO content system — what you'll learn: how search and AI-answer visibility get run as a single content system.

Where this work meets go-to-market

The operational playbooks that sit alongside what cloudflare's free tier actually does for a self-hosted app live with XenGrowth, who work on the commercial side of this.