Daniel sent us this prompt about Cloudflare's free tier and the eternal tension between locking everything down and actually being able to use your own stuff. He's been using their DNS, their registrar, their Access product, and now R2 for podcast hosting. And he's wrestling with something I think every self-hoster hits eventually — you add Cloudflare Access in front of Home Assistant, and suddenly your webhooks break, your MCP servers can't connect, and you're spending Saturday afternoon debugging service tokens instead of doing literally anything else.
This is the self-hosting tax. You start with "I'll just add a layer of security," and three hours later you're reading documentation about header injection and wondering where your life went. But the question is genuinely interesting — can you get reasonable security with just Cloudflare's free WAF rules, without touching the Access product at all, and avoid all that complexity? And I think the answer is mostly yes, with some important asterisks.
Mostly yes with asterisks is basically the unofficial subtitle of every Cloudflare product page.
So let's start with the cascade diagram Daniel mentioned, because understanding that is the prerequisite to everything else. Cloudflare processes rules in a specific order, and if you don't know that order, you will absolutely write rules that don't do what you think they do. The request comes in, and the first thing that hits it is the DDoS protection layer — that's at the edge, before anything else. If it's a volumetric attack, it gets dropped there. Then you hit the IP firewall, then custom WAF rules, then rate limiting, then managed rules, and finally the origin server. That sequence matters enormously.
If I write a custom rule that says "allow this IP" but I've also got rate limiting that would throttle that same IP, which one wins?
The allow wins because custom rules are evaluated before rate limiting in the pipeline. But here's where it gets subtle — if you write a custom rule that blocks a request, it never reaches rate limiting at all. And that's the key design principle. Cloudflare evaluates from most specific to most general. Your custom rules are specific. Rate limiting is broad. Managed rules are the broadest net. So a block at the custom rule level is final — it never sees the later stages.
Which means if you're trying to build a defense-in-depth setup, you actually want to be careful about where you put your blocks. Because an early block is efficient, but it also means you never get the telemetry from later stages about what that request would have triggered.
And that's the tension Cloudflare's architecture forces you to confront. Do you want to block early and save compute, or do you want to log and learn? For a home user on the free tier, I'd argue you want to block early because you're not doing threat analysis on your Home Assistant logs on a Tuesday evening. You just want the bad traffic gone.
Let's get concrete. Daniel's asking about basic security hardening on the free plan — what are the actual rules someone should set up on day one?
First, go into your SSL/TLS settings and set the encryption mode to Full Strict. The default on some setups is Flexible, which means traffic between Cloudflare and your origin can be unencrypted. That's the security equivalent of locking your front door but leaving the window open with a welcome mat underneath it. Full Strict requires a valid certificate on your origin server, and Cloudflare won't connect without one.
The free tier supports Full Strict?
You just need a certificate on your origin. If you're using Cloudflare's origin certificate, which is free to generate, you're set. Second thing — enable bot fight mode. It's a single toggle under Security, then Bots. It injects a JavaScript challenge for confirmed bot traffic. It's not as sophisticated as the paid bot management product, but for a free tier user, it catches the vast majority of scrapers and credential stuffers.
Does it break anything legitimate?
It can break API clients that don't execute JavaScript. So if you've got a webhook endpoint that receives POST requests from services that aren't browsers, you'll want to create a skip rule for that specific path. Which brings us to the third thing — you need to understand the difference between a WAF custom rule and a configuration rule. They look similar in the dashboard, but they operate at different stages. A configuration rule can disable security features for specific paths. A WAF custom rule can allow or block traffic based on conditions. You use them together.
For Daniel's N8N webhook, you'd create a configuration rule that disables bot fight mode and maybe certain managed rules on the webhook path, and then a WAF custom rule that still validates the request in other ways — checking for a specific header, or restricting the HTTP methods to only POST.
That's the pattern. And the fourth thing is rate limiting. On the free tier, you get one rate limiting rule. Set it to block or challenge requests when the rate exceeds something reasonable for your use case. For a login page, ten requests per minute from a single IP is generous. For a webhook endpoint, you might set it higher depending on how chatty the service is. The key is that rate limiting happens after custom rules in the pipeline, so your allow rules will still let traffic through, but the rate limiter catches abuse patterns that your static rules miss.
The fifth thing?
Turn on security level. It's under Security, then Settings. Set it to medium or high. This enables Cloudflare's IP reputation database — requests from IPs with a bad reputation get challenged. It's a blunt instrument, but it's free and it catches a surprising amount of low-grade malicious traffic. Between bot fight mode, security level, and one rate limiting rule, you've got three overlapping layers of protection before you've written a single custom rule.
None of this requires Cloudflare Access. No service tokens, no identity-aware proxy, no browser isolation. Just the WAF and the edge security settings.
And that's the core of Daniel's question — is this enough? Can you skip Access entirely and still sleep at night?
Let's answer that honestly. What's the attack surface you're actually defending?
For a self-hosted Home Assistant or N8N instance, the threats break down into a few categories. There's automated scanning — bots that crawl the internet looking for exposed services and known vulnerabilities. There's credential brute-forcing — someone finds your login page and starts guessing passwords. There's application-layer DDoS — flooding your endpoint with requests to make it unavailable. And then there's targeted exploitation — someone who specifically wants to get into your instance and is willing to do research.
That last one is the boogeyman everyone worries about, but it's also the least likely for a random home user. Unless you're a journalist, an activist, or someone with a very specific adversary, the targeted stuff is not your primary threat model.
Your actual threat model is automated scanning and opportunistic attacks. And for those, the free tier WAF rules are effective. The bots scanning for exposed Home Assistant instances are not sophisticated. They're looking for default credentials on common ports. A custom WAF rule that blocks requests where the URI path contains ".env" or "wp-admin" or any of the other common scan targets will stop the vast majority of them before they ever touch your origin.
You can write those rules on the free tier?
You get five custom WAF rules on the free plan. Five is plenty for a home user. Here's what I'd write. Rule one — block any request where the hostname doesn't match your actual domain. This catches people hitting your origin IP directly, which bypasses Cloudflare's DNS. Rule two — allow only the HTTP methods your service actually uses. Home Assistant needs GET and POST and maybe WebSocket upgrade. It does not need PUT, DELETE, or OPTIONS. Block everything else.
That's a good one. What's rule three?
Rule three — block requests based on known malicious ASNs. Cloudflare lets you filter by autonomous system number. There are hosting providers and bulletproof ISPs that originate a disproportionate amount of attack traffic. Blocking them at the WAF level means you never even see those requests. Rule four — challenge requests that match common vulnerability scan patterns. git/config" or "/admin" or "/backup". These are automated probes. You can write a single rule with an OR condition that covers a dozen of these.
Rule five is your rate limiting rule on the login path.
Which leaves you with one custom rule left for whatever specific thing your setup needs. And that's the free tier. Five rules, bot fight mode, security level set to medium, and SSL set to Full Strict. That's a meaningful security posture.
Let's talk about where this falls apart. Because Daniel mentioned webhooks, and webhooks are the Achilles heel of this whole approach.
A webhook endpoint needs to receive unauthenticated POST requests from arbitrary IP addresses. By definition, it's a door you leave open. And every security layer we just described is designed to close doors.
The question becomes — if you expose a webhook endpoint on N8N through Cloudflare with just the free WAF rules and no Access, what's the actual risk?
Let's break it down. Your webhook endpoint receives a POST request. N8N processes it and triggers a workflow. The attack surface is the N8N webhook handler itself — if there's a parsing vulnerability, that's a problem. But the more realistic risk is that someone discovers your webhook URL and starts sending it garbage data, or uses it to probe whether the endpoint is vulnerable to injection attacks, or just floods it with requests to waste your compute.
The mitigation is input validation on the N8N side, plus Cloudflare's rate limiting, plus ideally a shared secret or signature check.
That's the best practice. Most webhook providers — GitHub, Stripe, Slack — they sign their payloads. Your N8N workflow should verify that signature before processing anything. If the signature doesn't match, you drop the request. That's not a Cloudflare concern, that's application logic. But Cloudflare can help by rate limiting the endpoint so that even if someone does find the URL, they can't hammer it.
What about the argument that you should just put Access in front of everything and use service tokens for programmatic access? That's the "correct" answer from a security perspective, but it's also the answer that leads to Daniel debugging service tokens on a Saturday.
Access is the right tool for human-facing services. If you're the only person who needs to access Home Assistant, put Access in front of it. The login flow is clean — you hit the domain, Cloudflare challenges you with your identity provider, you authenticate, and you're in. No Home Assistant login page exposed to the internet at all. That's better security than any WAF rule can provide.
For machine-facing endpoints, Access is a pain. Service tokens work, but now every client that needs to hit that endpoint has to include the token header. Your MCP server needs to know about it. Your webhook provider needs to support custom headers, which many don't. And if you're using a third-party service that just sends a POST to a URL with no customization, you're out of luck.
Which is why the hybrid approach makes sense. Access for the human-facing stuff — Home Assistant dashboard, your admin panels, anything with a login page. WAF rules for the machine-facing stuff — webhooks, API endpoints, anything that receives automated requests. You segment your domain by path. Everything under "/webhook" gets WAF protection but no Access. Everything under "/app" gets Access. And you write your WAF rules to be especially strict on the paths that aren't behind Access.
That's the actual answer to Daniel's question. You don't have to choose between Access and no Access. You use both, on different parts of your domain, based on whether a human or a machine is the expected client.
Cloudflare makes this surprisingly easy with the configuration rules we mentioned earlier. You create a rule that says "for paths matching /webhook/*, disable Access." Then you create WAF rules that are specific to those paths — stricter rate limiting, header validation, method restrictions. The human paths get the full identity-aware proxy treatment. The machine paths get a carefully tuned set of WAF rules.
What about Home Assistant specifically? Daniel mentioned he's using Access for it now. Can you run Home Assistant behind just WAF rules and two-factor authentication on the app itself?
You can, and plenty of people do. Home Assistant's own authentication has improved significantly — they support two-factor, they have brute force protection built in, they've had security audits. If you keep it updated, the application-level security is reasonable. Putting Cloudflare in front adds the IP reputation layer, the bot fight mode, and the ability to block known attack patterns before they reach Home Assistant at all.
You lose the "no login page exposed" benefit of Access. With Access, the Home Assistant login page never loads for an unauthenticated user — Cloudflare intercepts the request before it reaches your origin. With just WAF rules, the login page is visible to anyone who hits your domain. They can try credentials. They can probe for vulnerabilities in the login flow itself.
That's the trade-off. And it's a real one. Home Assistant has had authentication bypass vulnerabilities in the past. Every web application does. Access eliminates that entire class of attack because the application's authentication is never reached — Cloudflare handles it at the edge. But the cost is complexity. Every client that needs to talk to Home Assistant has to go through the Access flow. The mobile app supports it. Browser access supports it. But if you want to integrate Home Assistant with something that doesn't speak the Access protocol, you're back to service tokens and custom headers.
The question Daniel's really asking is — how much security is enough? And the answer depends on what you're protecting and who you're protecting it from.
Let's put some numbers on it. The Shodan search engine, which indexes internet-connected devices, shows tens of thousands of exposed Home Assistant instances at any given time. The vast majority of attacks against these are automated — scripts that try default credentials, known exploits for outdated versions, common misconfigurations. A Cloudflare WAF with bot fight mode and a few custom rules blocks essentially all of this. The attacker moves on to the next target. They're not going to spend time trying to bypass your specific setup when there are thousands of easier targets.
The "you don't have to outrun the bear" principle of home security.
You just have to be less appealing than the person next to you. And a Cloudflare-protected domain with even basic WAF rules is significantly less appealing than a naked Home Assistant instance on a residential IP.
What about the DNS and registrar angle Daniel mentioned? He said he recommends decoupling DNS from hosting, and he uses Cloudflare as both registrar and DNS provider. Is there a security hardening angle there too?
Using Cloudflare as your registrar means your domain can't be hijacked through your hosting provider's control panel. If your web host gets compromised, the attacker can't transfer your domain because it's not registered there. And Cloudflare's registrar offers free WHOIS privacy, DNSSEC support, and two-factor authentication on the account. These are basic things that some registrars charge extra for.
The decoupling point is interesting because it's one of those things that sounds boring until you need it. If your hosting provider has an outage or you decide to move, you just change your DNS records. Your email keeps flowing because your MX records are on Cloudflare, not tied to your host. Your subdomains keep resolving. The migration is a DNS change, not a rebuild.
From a security perspective, it means you can change hosting providers without ever exposing your origin IP during the transition. You set up the new origin, test it through Cloudflare's DNS, flip the record, and the old origin never needs to be publicly accessible during the cutover.
Let's talk about one more thing Daniel mentioned — the "blast radius" concept. He used that phrase specifically. If something goes wrong, how do you contain the damage?
This is where Cloudflare's free tier actually shines compared to a lot of alternatives. You can create multiple DNS records pointing to different origins. Your main website goes to one origin. Home Assistant goes to another. N8N goes to a third. They can all be on the same physical machine with different ports, or different machines entirely, but from Cloudflare's perspective they're separate backend services. If one gets compromised, the others aren't affected unless the attacker can pivot within your network.
You can set different security levels per subdomain?
That's the power of the configuration rules and WAF custom rules we've been talking about. Your blog can have a relatively permissive security posture because it's just serving static content. Your Home Assistant subdomain can be locked down much tighter. Your webhook subdomain can have rate limiting tuned specifically for the services that hit it. You're not applying one blanket policy to everything.
That's the thing about Cloudflare that I think gets overlooked in all the enterprise-focused marketing. The free tier isn't a stripped-down demo. It's a capable security platform. Five WAF rules, bot fight mode, rate limiting, IP reputation filtering, SSL enforcement, DNSSEC — that's a better security posture than most small businesses had ten years ago.
It's worth noting that the free tier exists because Cloudflare's business model benefits from having more traffic flowing through their network. Every request they process, even for free users, improves their threat intelligence. They see attack patterns earlier. Their IP reputation database gets better. The free tier users are part of the product in the best possible way — they get real security value, and Cloudflare gets better data.
Which is why Daniel's point about finally paying them for R2 storage resonated. There's almost a guilt element to it — you've been getting all this for free for years, and finally there's something worth paying for.
R2 is good value. Zero egress fees is the killer feature. For podcast hosting, where you're serving audio files to listeners all over the world, egress fees from S3 or traditional cloud storage would add up quickly. With R2, you pay for storage and the class A and B operations, which for a podcast are minimal. The bandwidth is free.
It integrates with Cloudflare's CDN automatically. Your audio files are cached at edge locations worldwide. A listener in Tokyo gets the file from a Tokyo edge node, not from your origin server in wherever your bucket is homed.
That's the part of Cloudflare's architecture that's impressive. They've built a network where adding a new service means it inherits all the network-level benefits automatically. R2 objects are cached. Durable Objects are distributed. Workers run at the edge. Everything sits on top of the same global network.
Let's circle back to the practical question, because I think we've covered the theory but Daniel's asking for a concrete recommendation. If you're self-hosting Home Assistant and N8N and you want to use Cloudflare's free tier for security without the complexity of Access, what's the actual checklist?
Step one — SSL set to Full Strict. Step two — security level set to medium. Step three — bot fight mode on. Step four — create custom WAF rules. Block requests where the hostname doesn't match your domain. Block HTTP methods you don't use. Block known malicious ASNs if you want to be aggressive about it. Challenge or block common scan paths. Step five — set up rate limiting on your login paths and your webhook endpoints, tuned to what's reasonable for your usage. Step six — enable DNSSEC in the Cloudflare dashboard. Step seven — turn on two-factor authentication on your Cloudflare account itself, because none of this matters if someone compromises your Cloudflare login.
Step eight — keep your origin software updated. Home Assistant, N8N, whatever you're running. Cloudflare stops attacks at the edge, but if there's a vulnerability in your application, and a request gets through, the WAF won't save you.
That's the part people forget. Cloudflare is a perimeter defense. It's a very good perimeter defense, but it's not a substitute for patching your software. The WAF can block known exploit patterns, but a zero-day or a cleverly crafted request can still slip through.
What about the webhook question specifically? Daniel's worried about having a webhook endpoint just out there on the internet. Is that actually safe with just WAF rules?
It depends on the webhook. If it's a GitHub webhook, GitHub signs every payload with a secret you configure. Even if someone discovers the URL, they can't send a valid payload without the secret. Your N8N workflow validates the signature before processing. That's secure. If it's a webhook from a service that doesn't sign payloads, you're relying on the obscurity of the URL and Cloudflare's rate limiting to prevent abuse. That's less secure, but for most home users, it's sufficient.
The URL-as-secret pattern. Not ideal, but widely used.
You can improve it. Generate a long random token as part of the webhook URL — "/webhook/a8f3c9d2e1b4..." — so it's not guessable. Combine that with a WAF rule that only allows POST requests to that path. Combine that with rate limiting. At that point, an attacker needs to discover the URL, figure out the expected payload format, and stay under the rate limit. That's a high enough bar for a home automation webhook.
The thing I keep coming back to is Daniel's point about frustration. He said that maximizing security often just ends up frustrating legitimate users — yourself, in this case — for very little actual gain. And I think that's the right framing. Security is always a trade-off with usability. The trick is knowing where the diminishing returns kick in.
For a self-hosted Home Assistant instance, the diminishing returns kick in somewhere around the combination we just described. WAF rules, bot fight mode, rate limiting, two-factor on the application itself, and keeping things updated. Adding Access on top of that does increase security — it eliminates the exposed login page entirely — but it also adds a meaningful usability cost. For some people that trade-off is worth it. For others, it's not.
The beauty of Cloudflare's architecture is that you can change your mind. You start with just WAF rules. If you get targeted or you just get uncomfortable, you flip on Access for the human-facing paths. You don't have to rebuild anything. The DNS stays the same. The origin stays the same. You're just changing the security policy at the edge.
That's the real power of the intermediary layer Daniel was talking about. Cloudflare sits between the internet and your origin, which means you can change how traffic is filtered without touching your application. That's a property that's hard to achieve any other way. If you're doing security at the application level — installing fail2ban on your server, configuring application firewalls, writing custom auth middleware — every change requires modifying your setup. With Cloudflare, you toggle a setting in a dashboard and it applies globally in seconds.
That's why the decoupling argument extends beyond DNS. You're decoupling your security policy from your application code. Your Home Assistant doesn't need to know about rate limiting. Your N8N doesn't need to implement IP reputation filtering. Those concerns live at the edge, and your applications just receive clean traffic.
It's the same architectural pattern that's become standard in larger deployments. A reverse proxy or API gateway handles cross-cutting concerns — authentication, rate limiting, TLS termination — and the backend services focus on business logic. Cloudflare is just that pattern implemented as a service, available for free, with a global network behind it.
Now: Hilbert's daily fun fact.
Now: Hilbert's daily fun fact.
Hilbert: In the nineteen sixties, researchers discovered that different honeybee populations perform the waggle dance with distinct acoustic dialects. The duration of the waggle phase, which encodes distance to a food source, varies measurably between colonies. A bee from one region will misinterpret the distance signals of a bee from another, effectively speaking the same language with a different accent.
Bees have regional accents. Of course they do.
I'm now imagining a bee from Munich trying to follow directions from a bee from Milan and ending up in the wrong field entirely.
This has been My Weird Prompts. Thank you to our producer, Hilbert Flumingtop. If you enjoyed this episode, leave us a review wherever you get your podcasts — it helps. I'm Corn.
I'm Herman Poppleberry. We'll catch you next time.
