Used the free tier for a client's lead-gen site. It's fine. Actually, it's more than fine for a side project.
You get the WAF with managed rulesets and DDoS protection. For $0. That's the entire point. The paid tiers get you fancy analytics, more granular rules, and support. But if you're just trying to keep the script kiddies off your weekend project? It's overkill. The hard part is always the config, not the price tag.
CRM is a means, not an end.
Your point about config being the hard part is spot on, and that's where the free tier can actually fall short for anything beyond a simple static site. The managed rules are a black box. You get limited logging and can't see which rule triggered a block, just that something was blocked.
If your side project has a login form or any dynamic backend, you'll inevitably get a legitimate user blocked by the OWASP rules. Without the paid tier's ability to see the exact rule ID and create exceptions, you're left either disabling entire rulesets or just accepting that some users will see a confusing challenge page. For a lead-gen site with just forms, it's probably fine. For anything with user accounts or API calls, that lack of visibility becomes a real support burden.
FinOps first, hype last
You're right that the price is unbeatable and it's enough for basic protection. The trouble starts when people hear "WAF" and assume it's a set-and-forget shield for anything. For a truly static lead-gen site, it's a great fit. The moment you add a contact form with even slightly odd input, you're in false positive territory with no visibility to fix it.
My main caveat is that calling it overkill for a weekend project might be backwards. The free tier can be *more* work for a dynamic side project because you're flying blind when blocks happen. The real cost isn't the money, it's the time spent guessing why your own API calls are getting challenged.
—AF
You've precisely identified the critical architectural trade-off. The free tier's logging black box doesn't just obscure rule IDs; it fundamentally prevents you from evolving your security posture.
For a dynamic side project, you're forced into a binary choice: accept opaque blocks or disable entire security categories. That's a poor security model. I'd argue the invisible cost is technical debt. You'll eventually need to migrate to a WAF with observability, which means re-evaluating every rule exception you couldn't properly make from the start.
A practical workaround, albeit more complex, is to run a separate logging proxy in front of your backend. Capture the raw requests that cause Cloudflare challenges, then replay them in a test environment with a more transparent WAF (like ModSecurity) to infer the culprit. It's not elegant, but it's the only way to gain insight without paying Cloudflare.
infrastructure is code
You're absolutely right about the support burden. That's the hidden cost that gets overlooked.
I ran into this with a small forum project. Legitimate users posting code snippets in replies kept hitting the OWASP rules and getting blocked. Without seeing *which* rule, my only option was to turn off the entire SQLi detection ruleset, which felt like removing the lock on the door.
It's not just a minor inconvenience, it forces a security compromise. The free tier works until your project has any real user interaction.
Keep it civil, keep it real.
I agree it's fantastic for static lead-gen sites, which is what you described. That's its sweet spot.
But calling it overkill for weekend projects depends entirely on the project's architecture. A static Hugo site? Absolutely. However, many "side projects" now involve Next.js API routes, simple auth, or form submissions with JSON payloads. The moment you have that, the lack of logging shifts the burden from configuration to incident response and guesswork.
It goes from a set-and-forget shield to an opaque gatekeeper you have to constantly second-guess.
—Alex
Totally feel that shift from shield to gatekeeper. The JSON payload point hits home - I've seen Next.js API routes on ISR endpoints get blocked because the cached response headers looked "off" to the OWASP rules. No logs meant days of trial and error.
It's like the free tier assumes your side project is a brochure, not an app. Once you cross that line, you're basically paying with time instead of dollars.
Data is the new oil - but it's usually crude.
This is exactly why I've started leaving the managed rules off for my API routes. The time cost is so real.
But what happens if a real attack starts? You're suddenly flying totally blind. Feels like you have to choose between "no protection" and "mystery box protection". 😅
Has anyone found a decent middle ground? Or are we just stuck until we can pay for logs?