The Cloudflare free plan gives you a fast DNS host, a global CDN, a universal SSL certificate, unmetered DDoS mitigation and a small allowance of firewall and rate-limiting rules, and it is genuinely good enough for most small sites.
What it does not give you is a place for your website to live. The free plan is a service that sits in front of hosting, and that single fact explains most of the confusion, both the surprised delight and the surprised outage. Here is an honest run through what is included, what the limits mean in practice, and when paying for Pro starts to make sense.
Table of contents
- What the free plan actually is
- DNS and the proxy toggle
- SSL modes: the setting that causes the most outages
- Caching, rules and the WAF allowance
- Limits you will actually hit
- When to pay, and what it is still not
- How this fits the rest of the stack
- FAQ
What the free plan actually is
Cloudflare’s plans (Free, Pro, Business, Enterprise) apply to the proxy service on a domain, not to hosting. On the Free plan you add your domain, change the nameservers at your registrar to the two Cloudflare assigns, and from then on your DNS is answered by Cloudflare and any records you mark as proxied send traffic through their network first.
The headline features on the official Free plan overview are DDoS mitigation, a free SSL certificate, the CDN and fast DNS. Those four are the real product. Everything else on the list is a smaller allowance of a feature the paid tiers sell in bulk: fewer firewall rules, fewer page or redirect rules, coarser analytics, basic support through the community rather than a ticket queue.
Note the phrase ‘in front of’. If your origin is down, the free plan shows visitors a Cloudflare error page rather than your site. If your origin is slow, the CDN can hide that for cached pages only. If you have no origin at all, then you have picked the wrong product, and the hosting side is Pages or Workers, covered in our Cloudflare hosting guide.
The upside is that the free plan is not a crippled trial. Many production sites run on it for years. The trade is support and the depth of the advanced tools, not the core routing.
DNS and the proxy toggle
Every DNS record you add has one decision attached to it: proxied (orange cloud) or DNS only (grey cloud). Proxied records return Cloudflare IP addresses to the world, so your origin IP stays out of public DNS and traffic gets the CDN and security treatment. DNS-only records return your real IP, which is what you want for mail servers, SSH hosts and anything that is not HTTP or HTTPS.
Free DNS is fast, supports the common record types, and gives you CNAME flattening at the apex, so pointing the bare domain at a hostname works. Changes propagate quickly because the records live inside the same network that serves them. If you want to understand primary versus secondary setups and why the free plan behaves as it does, see Cloudflare DNS servers, primary and secondary.
Two practical warnings. First, mail records must stay grey; proxying an MX target or a mail hostname simply breaks delivery. Second, a proxied record only proxies web ports, so a proxied hostname will not carry SSH or a database port. Put those on a grey-cloud subdomain, or better, do not expose them at all.
- Proxied (orange): HTTP and HTTPS sites and APIs.
- DNS only (grey): mail, SSH, game servers, database endpoints, anything not web traffic.
- Apex CNAME: allowed, flattened automatically.
- TTL on proxied records: managed by Cloudflare, so you cannot set it.
SSL modes: the setting that causes the most outages
The free certificate is universal SSL: Cloudflare presents a valid certificate to the browser. What you choose is how Cloudflare talks to your origin, and there are four settings.
- Off: no HTTPS at the edge. Do not use.
- Flexible: HTTPS to the visitor, plain HTTP to your origin. Easy, and the source of endless redirect loops when the origin also forces HTTPS.
- Full: HTTPS both ways, but the origin certificate is not validated, so self-signed works.
- Full (strict): HTTPS both ways with a validated origin certificate. This is the one to use.
The redirect loop deserves its own mention. With Flexible, Cloudflare requests your origin over HTTP; the origin sees an insecure request and redirects to HTTPS; Cloudflare follows and sends HTTP again; the browser eventually gives up with a too-many-redirects error. Switching to Full (strict) after your origin has a real certificate fixes it and closes a genuine gap, since Flexible leaves the back half of the trip unencrypted.
Cloudflare can also issue a free origin certificate that only its own proxy trusts, which is handy for the origin side of a Full (strict) setup, as long as you never turn the proxy off. If you ever expose the origin directly, browsers will reject that certificate. More in the Flexible mode post.
Caching, rules and the WAF allowance
By default Cloudflare caches static file types by extension: images, stylesheets, scripts, fonts. It does not cache HTML unless you tell it to, which is the safe default because dynamic HTML often contains user-specific content. On the free plan you can still write cache rules to cache HTML for public pages and bypass it for logged-in areas, within a small quota of rules.
The limits show up here more than anywhere else. Free accounts get a modest number of configuration, redirect and cache rules, a managed ruleset that covers a fixed set of common exploit patterns, and a small allowance of custom WAF rules. The exact counts change over time, so read the dashboard rather than any blog post, ours included. For what the managed ruleset does and does not catch, see our managed ruleset explainer.
Rate limiting is the feature people assume they get in bulk. The free plan includes a small number of rate limiting rules with fairly coarse matching, enough to slow down a login form or a contact endpoint. It is not a substitute for application-level throttling. We compared the options in Cloudflare rate limiting.
A cache-bypass pattern that saves people from serving one visitor’s cart to another looks like this:
Rule: bypass cache for account and checkout
When: URI path starts with /account, /cart, /checkout, /wp-admin
or: request has a cookie named session or wordpress_logged_in
Then: Cache eligibility = Bypass cacheLimits you will actually hit
The recurring complaints are not about the core features. They are about the edges. Only a limited set of file types is cached by default. Upload size through the proxy is capped at 100 MB on the free plan, which trips up media libraries and backup plugins. Custom certificates, prioritised support, image optimisation tools and advanced bot handling sit behind paid plans.
Analytics on the free plan are useful for traffic shape and threat counts but shallow for debugging; log delivery is a paid feature, so you will not have a raw request log to grep. If you need to trace a failing request, you are back to origin logs, which is one more reason to run an origin that keeps them. That gap is covered in the Logpush post.
Then there is the question of scale of attack. Unmetered DDoS mitigation on the free plan is real and covers the volumetric floods that would flatten a small server. It is less about clever application-layer abuse, where tuned rules and rate limits matter. For a small site, that is plenty; for one that is a repeat target, see our note on when scrubbing services matter.
None of these limits stop a personal site, a portfolio, a docs site or a small business brochure from running happily for years on the free tier. They start to matter when uptime and diagnostics become commercially important.
When to pay, and what it is still not
Upgrade to Pro when a specific limit costs you time or money: you need more WAF and page rules, image optimisation matters for your bandwidth, or you want faster support. Business adds a stronger uptime commitment and custom certificates. Moving up is per domain, so you can upgrade the one site that needs it and leave the hobby domains on free.
Do not upgrade to fix an origin problem. If pages are slow because the app takes two seconds to respond, more Cloudflare rules do nothing on a cache miss. If the site goes down because the server ran out of memory, the proxy only changes what the error page looks like. Fix the origin: right-size the plan, add a health check, and keep logs.
A workable rule is to treat Cloudflare as the front layer and the host as the foundation, and to spend on the foundation first. A managed web service with logs and rollback behind a free-plan proxy is a better setup than a bare VPS behind a Pro plan. The proxy’s job is to make good hosting faster and safer; it cannot make weak hosting reliable, and paying more for the layer in front never changes that.
How this fits the rest of the stack
The free plan is a very good front layer and a very poor substitute for hosting. Use it for DNS, TLS and caching, run Full (strict) to an origin that keeps its own logs, and spend your first real money on the origin. If you are working out what that origin costs as a web service plus a managed database, the RunxBuild hosting calculator shows the line items together. Then deploy the app from the RunxBuild dashboard, confirm it works on its own hostname, and switch the proxy on last. The certificate and domain side is covered in Custom domains and certificates on RunxBuild.
Useful related references:
- Cloudflare Hosting: What It Hosts vs What It Fronts
- Cloudflare Rate Limiting
- Cloudflare DNS Servers, Primary and Secondary
- Custom domains and certificates on RunxBuild
FAQ
Is the Cloudflare free plan really free?
Yes, there is no charge for the Free plan and no card is needed to add a domain. You get DNS, the CDN, universal SSL and DDoS mitigation. Paid features such as extra rules, image optimisation and priority support are on Pro and above. Some other Cloudflare products, like Workers or R2, carry their own separate usage limits.
Does the Cloudflare free plan include hosting?
No. The plans apply to the proxy, DNS and security layer sitting in front of a website. You still need somewhere for the site itself to live, either a server you rent, a managed platform, or Cloudflare’s separate Pages and Workers products, which have their own free allowances.
Which SSL mode should I choose on the free plan?
Full (strict), once your origin has a valid certificate. It encrypts both hops and verifies the origin. Flexible is the easy option but leaves the origin connection in plain HTTP and commonly causes redirect loops. Off should not be used for any public site.
Does the free plan protect against DDoS attacks?
Yes. Unmetered network-level DDoS mitigation is part of the free plan, so volumetric floods against proxied hostnames are absorbed. Application-layer abuse is handled with the WAF and rate limiting rules, which are more limited on Free, so a hostile target eventually outgrows it.
Can I run a production business site on the free plan?
Many do, especially brochure sites, blogs and small shops. The trade-offs are limited rules, shallow analytics, no log delivery and community support. If downtime is expensive, upgrade the plan for that domain and, more importantly, make sure the origin behind it is monitored and can roll back.