Cloudflare in front of a self-hosted cluster: is it worth it in 2026?

The question comes back every week in a Brazilian DevOps group: "I brought up my cluster with three servers on DigitalOcean, is it worth putting Cloudflare in front?". The short answer is "almost always yes" — but the "almost" carries trade-offs that nobody mentions until the first time something breaks in production and you spend two hours debugging a cache rule that masked a 500 from the app. This post is the long version, with measurable criteria, of the decision you need to make before moving the nameserver.

TL;DR — the 200-word summary

Free Cloudflare became de facto standard for any Brazilian site with traffic: protects against DDoS without contractual limit, issues automatic SSL certificate, caches assets in over 300 cities, hides the server's origin IP and still delivers DNS with sub-10ms. For a self-hosted cluster — be it HeroCtl, Coolify, k3s or Docker Swarm — putting Cloudflare in front is an easy decision in around 90% of cases.

The remaining 10% have concrete trade-offs: additional latency of 10 to 30ms on dynamic routes, TLS terminates at Cloudflare by default (no longer end-to-end to your server), cache rules can mask subtle bugs in the app, and lock-in grows as you adopt Workers, R2 and Pages.

Worth it when: you want DDoS protection without paying; global cache to reduce bandwidth cost; hide the server IP from scanners. Not worth it when: financial/health compliance requires truly end-to-end TLS; you need p99 below 50ms on dynamic routes; the cluster already has internal CDN edge in multiple data centers. A cluster with integrated router already covers around 60% of what Cloudflare offers — combining the two is the most common path.

What does Cloudflare offer for free in 2026?

The free offering grew year over year. Today, the free plan covers what was paid plan in 2019:

• DDoS protection without contractual limit — Layer 3, 4 and 7. Cloudflare absorbs attacks of hundreds of Gbps without charging excess.
• Automatic SSL/TLS certificate — issued in minutes by Cloudflare itself, automatically renewed. Wildcard requires the Advanced Certificate Manager plan (US$ 10/month).
• Global CDN — over 300 cities in over 120 countries. Includes São Paulo, Rio, Fortaleza, Curitiba and Porto Alegre.
• Authoritative DNS — sub-10ms global average, anycast, with APIs for automation.
• Basic bot protection — blocking known bots and JavaScript challenges on suspicious traffic.
• Static asset cache — recognized extensions (CSS, JS, images, fonts) cached by default.
• Page Rules — three free rules to force HTTPS, extra cache, redirects.
• Always Online — when origin falls, Cloudflare serves the last cached version.
• Web Analytics — RUM metrics (visits, countries, browsers), no cookies.

The cutoff line is generous enough that a 10k visitors/day site runs 100% on free without any operational problem.

And what does Cloudflare charge extra for?

Four plans: Free, Pro (US$ 25/month per domain), Business (US$ 250/month per domain) and Enterprise (on consultation, generally above US$ 5k/month).

Workers and R2 have free tier independent of plan: 100k requests/day for Workers, 10 GB of storage and 1 million Class A operations/month for R2. For a modest marketing site, you can run image storage on R2 without ever reaching the bill.

Does Cloudflare add latency?

The honest question. Honest answer too: depends on the route.

For cached routes (static HTML, assets, optimized images), Cloudflare reduces latency. The user in Recife gets the content from the Fortaleza or São Paulo POP in 15 to 40ms, instead of doing round-trip to your server in New Jersey or Frankfurt. Typical savings: 150 to 250ms per request.

For dynamic routes (API, logged dashboard, checkout), traffic passes through the Cloudflare proxy before reaching your server. That adds between 10 and 30ms in normal conditions. The exact number depends on which POP the user is connected to and where the origin server is.

We measured on the public production cluster: the average response time of manage.heroctl.com/v1/nodes is 38ms without Cloudflare proxy and 51ms with proxy enabled, requesting from the same notebook in São Paulo. A delta of 13ms — perceptible in benchmark, invisible to a human.

Latency is only a dealbreaker in three real scenarios: online gaming, high-frequency financial auction, and low-latency WebSocket loads (trading, live collaboration). For the rest, the 13ms disappear in the browser render time.

Does Cloudflare break end-to-end TLS?

By default, yes. See the modes:

• Flexible (NEVER use this) — TLS only between client and Cloudflare. Cloudflare → server connection is plain HTTP. Vulnerable to interception on the inner leg.
• Full — TLS between client and Cloudflare, and separately between Cloudflare and server. But Cloudflare accepts invalid/self-signed certificate at the server. Risk of man-in-the-middle between Cloudflare and origin.
• Full (strict) — TLS on both legs, and Cloudflare requires valid certificate at origin. This is the minimum reasonable configuration.
• Strict (SSL-Only Origin Pull) — Cloudflare verifies that the origin's certificate was issued by a public valid CA for the hostname. More secure than Full strict.

In all these modes, Cloudflare decrypts traffic in the middle of the path. They see request body, headers, cookies — everything. For most cases that is acceptable (the contract with Cloudflare is clear), but in strict compliance (health, financial, government) it can break audit requirements.

The real exit for end-to-end:

• Authenticated Origin Pulls — Cloudflare presents a client certificate when connecting to your origin; the server only accepts connections from that chain. Still decrypts in the middle, but at least only Cloudflare can reach your origin.
• Cloudflare Tunnel + mTLS client at the endpoint — for internal apps, Tunnel replaces public IP and requires client certificate.
• Gray cloud (DNS only) — disables proxy. You lose DDoS protection, cache, WAF — but get direct client-server connection with truly end-to-end TLS. It is a valid option when compliance commands.

Will I get locked-in to Cloudflare?

Depends exclusively on which features you adopt. Let's go layer by layer:

• DNS — trivially reversible. Moving nameserver takes 24 to 48h of propagation and nothing breaks. Zero lock-in.
• Proxy + cache + WAF — reversible in hours. You disable the orange cloud, adjust DNS to point directly to the server, reconfigure WAF on your origin (if any). Low lock-in.
• Workers — real lock-in. The Workers API is proprietary; rewriting to Lambda@Edge or Fastly Compute@Edge costs days to weeks depending on the code. It is not the worst case, but count on rework.
• R2 Object Storage — API S3-compatible, so code keeps working. But R2 doesn't charge egress (S3 charges US$ 0.09/GB), so moving to another provider makes the bill more expensive. Economic lock-in, not technical.
• Pages — moderate lock-in. Build process is custom; rewrite to Vercel/Netlify/generic static host takes an afternoon, but requires.
• Zero Trust — high lock-in. Policies, identity, tunnels: complete rewrite to Tailscale/Twingate/equivalent.

The operational recommendation is: use the Cloudflare core (DNS + proxy + WAF + Page Rules) without hesitation — you can revert in a day. Adopt Workers/R2/Pages only with clear awareness that you are accepting lock-in proportional to the value that feature delivers.

Minimum recommended configuration for self-hosted cluster

Practical sequence, no secret:

1. Create a Cloudflare account and add the domain. The site will scan your current DNS records and copy them to the new zone.
2. Change the nameservers at the registrar (Hostinger, Registro.br, GoDaddy, wherever you are). Wait 4 to 48 hours for propagation. Verify with dig NS heroctl.com +short.
3. DNS records of the cluster: create an A record for the root domain pointing to the IP of the server receiving traffic, and a wildcard A record * pointing to the same IP. Mark both with proxy enabled (orange cloud).
4. SSL/TLS mode: configure Full (strict). That requires the cluster to have a valid certificate. The HeroCtl integrated router issues Let's Encrypt automatically — works out of the box.
5. Always Use HTTPS: ON. Redirects any HTTP to HTTPS at the edge.
6. HSTS: 6 months, include subdomains, no preload for now. Preload is a definitive decision — you can't undo it quickly if something breaks.
7. Page Rule for cache of static assets: *heroctl.com/static/* → Cache Level: Cache Everything, Edge Cache TTL: 1 month.
8. WAF managed ruleset (Pro+): enable the Cloudflare Managed Ruleset and OWASP Core Rule Set in Block mode for high-score rules.
9. Security Level: Medium. Low lets too many bots through; High challenges legitimate people.
10. Bot Fight Mode: ON on the free plan. Controls basic scrapers without asking the human for CAPTCHA.

After applying all of that, run curl -I https://yourdomain.com and confirm: header cf-ray present, header server: cloudflare, header strict-transport-security with long max-age.

When is Cloudflare NOT worth it?

Four scenarios where the recommendation changes. They matter more than they seem.

Cluster with robust internal CDN/edge. If you already run in four or five geographically spread regions, with proximity-based DNS balancing and local cache in each region, Cloudflare's CDN adds latency without gain. Worth running gray cloud (DNS only) and keeping the rest direct.

Financial or health compliance with mandatory end-to-end mTLS. LGPD by itself doesn't require this; but specific audits (PCI-DSS Level 1 with custom requirements, strict HIPAA certifications, banking frameworks) may require encrypted traffic to never be decrypted at a third party. Since Cloudflare decrypts in the middle of the path, doesn't pass.

Purely internal apps (intranet/closed B2B SaaS). Free Cloudflare doesn't cover advanced Zero Trust. For an app that exclusively serves employees, Tailscale or native WireGuard deliver more with less.

Small sites without traffic and without public enemy. Personal blog of 200 visits/month, without payment form, without sensitive data. Direct DNS at Hostinger/Registro.br + Let's Encrypt from the integrated router serves perfectly. Adding Cloudflare is unnecessary ceremony.

How does Cloudflare interact with a high availability cluster?

Here the design matters. A cluster with three or more nodes serves traffic on all of them — there is no single "main" node. The pragmatic configuration is:

• DNS round-robin with health: register A records for the IP of all nodes that run the router. Cloudflare does health check (Pro+) and removes a broken node from rotation automatically.
• Cloudflare failover: ~30 seconds to detect a dead node and remove from rotation (configurable to 5 seconds on Enterprise).
• Internal cluster failover: the HeroCtl integrated router reroutes traffic between healthy nodes in around 5 seconds. New coordinator election happens in ~7 seconds when the leader node falls.

Combined, real downtime perceived by the user stays below 40 seconds in the worst case (Cloudflare detects + cluster reacts). Without Cloudflare, stays at ~7 seconds (cluster alone). With Cloudflare and aggressive monitoring configuration (Pro+), back to ~10 seconds. The choice is clear: if you don't need DDoS protection, the cluster alone is already faster. If you need it, Cloudflare adds 30s of detection in exchange for protection against attacks.

Comparison table: 12 decision criteria

The line that decides for most is "DDoS Layer 7 + hides IP". These two alone justify the free plan. Paid lines only make sense with high-volume traffic or formal WAF requirement.

Does free Cloudflare have a traffic limit?

There is no contractual bandwidth limit on the free plan for normal web traffic through the proxy. But there are three practical limits worth mentioning:

• Section 2.8 of the Terms of Service: the free plan is for sites whose main content is HTML, and Cloudflare reserves the right to ask for upgrade if you use the service primarily to serve video or large files. In practice, they rarely act on this — but if you become a host for 50TB/month of pirated videos, expect to receive an email.
• Workers free: 100k requests/day. Above that, Workers Paid (US$ 5/month) with 10M requests included.
• R2 free: 10GB of storage, 1M Class A operations/month, 10M Class B operations/month. Above, US$ 0.015/GB-month.

Can I use Cloudflare DNS without the proxy?

Yes — "DNS only" mode (gray cloud). You use Cloudflare DNS (fast, free, anycast global) but traffic goes directly to your server without passing through the proxy. You lose DDoS, cache, WAF, IP hiding — keep only the DNS infrastructure. Useful when: compliance prohibits decryption at third parties; you only want fast DNS without touching the traffic path; you are testing before activating the proxy.

Does free WAF block SQL injection?

Cloudflare Free has Bot Fight Mode and automatic mitigation rules for obvious patterns, but doesn't have the complete OWASP Managed Ruleset. For reliable blocking of SQL injection, XSS, known RCE patterns, you need the Pro plan or higher. Alternative: run ModSecurity or your own WAF at your origin — works, but adds CPU and configuration.

Does Cloudflare have a datacenter in Brazil?

Yes. In 2026 there are five Brazilian POPs: São Paulo (two POPs), Rio de Janeiro, Fortaleza, Curitiba and Porto Alegre. Typical latency from any city in the Southeast to a POP stays below 20ms. The Fortaleza POP serves the Northeast very well because of the submarine cables that land there (EllaLink, Monet, GlobeNet). For the North, it is still a longer path — Manaus reaches Fortaleza in 80 to 120ms.

How do I migrate nameservers from Hostinger to Cloudflare?

Four steps. Takes less than an hour active, plus up to 48h of propagation:

1. Cloudflare: add the domain. The wizard scans your current DNS and creates the corresponding records in the new zone. Check that everything was copied — MX, TXT (SPF/DKIM/DMARC), CNAME, A. Copy errors here cause email taken down for a week.
2. Cloudflare: it gives you two nameservers (something like kim.ns.cloudflare.com and walt.ns.cloudflare.com). Note them.
3. Hostinger: panel → Domains → your domain → Nameservers → "Use custom nameservers" → paste the two from Cloudflare. Save.
4. Wait for propagation. Verify with dig NS yourdomain.com +short. When the Cloudflare nameservers appear, the domain is under their management. DNS records continue to be edited on the Cloudflare panel from here on.

Important: while propagation happens, part of the users still resolves via Hostinger. Don't turn off the old zone until you confirm 100% of resolvers have already switched (24 to 48 hours is safe).

Where does TLS terminate? Does E2E break?

In proxy mode (orange cloud), TLS terminates at Cloudflare. They re-establish another TLS connection to your server (in Full strict mode). Technically: decrypts, processes, re-encrypts. For truly end-to-end: gray cloud (DNS only) or Cloudflare Tunnel with custom configuration. For most applications, "truly end-to-end TLS" is less important than it seems — the attack this protects against (interception in the middle of the network) requires an attacker already inside the Cloudflare network, an unrealistic scenario.

Cloudflare Workers vs serverless from my cloud — when is it worth it?

Workers are good for: edge computing where latency <50ms matters (geo-routing, A/B testing, header rewrite); lightweight request/response transformation; auth at the edge (validating JWT before reaching origin). They are not good for: workloads with more than 30 seconds of runtime; heavy integration with relational databases (cold start latency of DB driver kills); code that needs libraries that depend on filesystem or process. AWS Lambda remains better for long-runtime workload; Workers win at the edge. Use both, don't replace one with the other.

Can I use Cloudflare R2 with a self-hosted cluster?

Yes — R2 is S3-compatible at the API level. Your app uses aws-sdk configured with R2 endpoint and R2 credentials; code keeps the same. Economic advantage: zero egress fee. You can serve heavy downloads (installers, product videos, backups) directly from R2 without paying for outgoing bandwidth. Disadvantage: documented durability is 99.999999999% (11 nines), same as S3, but R2's operational history is shorter. For critical hot path, some teams prefer to keep S3 and use R2 only for cold storage and static delivery.

Origin fell — does Always Online solve it?

Partially. Always Online serves the last cached version of HTML pages when the server is offline. But: only works for routes that were being cached; only serves the static version (without updated dynamic data); only lasts while Cloudflare keeps the snapshot (usually a few days). It is a good safety net for static blog and marketing. Doesn't replace real cluster high availability — for a dynamic app, what solves it is the cluster having three nodes and automatic election when one falls.

Closing — combining Cloudflare with self-hosted cluster

The combination we recommend for 90% of cases is: self-hosted cluster with three or more nodes (real high availability) + Cloudflare Free at the edge (DDoS, cache, IP hiding). The cluster takes care of internal routing, automatic certificates, failover between nodes in seconds. Cloudflare takes care of public protection, global cache and IP obfuscation. The two layers complement each other — they don't compete.

To start from scratch with this combination:

curl -sSL get.heroctl.com/install.sh | sh

You end up with a functional cluster on three nodes, automatic Let's Encrypt certificate on the domain you choose, web panel to submit jobs, real high availability. Then add Cloudflare Free in front of the domain and configure as per the "Minimum configuration" section of this post. Total time: an afternoon.

More reading along this line:

• Docker deploy in production: from compose to cluster — how to leave docker compose up and reach real high availability, with the intermediate steps.
• Observability without Datadog: stack for a startup — metrics, logs and tracing without paying US$ 2,000/month for an observability SaaS.

Cloudflare is one of the few tools where the free tier is so good that refusing is stubbornness. But like any infra choice, the hard part is understanding exactly where the boundary lies — and, primarily, where it passes through your application's encrypted traffic.