Speed up your Dargo site with Cloudflare CDN

What you'll get out of this

• Faster page loads worldwide. Static assets (CSS, JS, images, fonts) served from a Cloudflare edge near the visitor instead of from your device.
• Lower bandwidth usage on your Dargo allowance. Cached requests never touch your device, so the traffic doesn't count against your monthly free tier.
• Free DDoS protection at the edge — Cloudflare absorbs floods before they reach you.
• Free image optimization (Polish + Mirage on Cloudflare's free plan) that converts your images to WebP / AVIF on the fly.
• An "Always Online" cached page shown to visitors when your home internet briefly drops.

When this applies (and when it doesn't)

This guide is for custom domains — sites you've added to Dargo at blog.your-domain.com or your-domain.com after pointing DNS at us.

The free *.mydargo.com subdomains already run through Cloudflare on our side — there's nothing for you to add. If you're happy on a Dargo subdomain, you can skip this guide.

You'll also want to skip this for apps that are essentially admin panels with no public traffic — Nextcloud for a family of four, n8n for personal automations, a self-hosted Bitwarden. Caching for those mostly creates surprise login bugs without buying you much, since there's no real traffic to absorb.

Step 1 — Add your domain to Cloudflare

1. Create a free Cloudflare account if you don't have one.
2. Click Add a Site, paste your domain (the root — your-domain.com, not blog.your-domain.com), pick the Free plan.
3. Cloudflare will scan your existing DNS and show you the records it found. Confirm.
4. At your domain registrar (Namecheap, GoDaddy, Porkbun, etc.) change your domain's nameservers to the two that Cloudflare gave you. Save.
5. Wait for Cloudflare to verify — usually under an hour, sometimes a few. You'll get an email.

This step changes who answers DNS queries for your domain. Cloudflare becomes your DNS host. Your domain registrar stays your registrar (renewals, ownership) — nothing else changes there.

Step 2 — Point the domain at your Dargo device

If you haven't yet added the custom domain to Dargo, do that first — sign in to my.dargo.net, open the app you want public, click Add custom domain, and the portal shows you the IPv4 address to point at.

Now in the Cloudflare DNS dashboard for your domain, create an A record pointing the hostname (apex your-domain.com, or a subdomain like blog.your-domain.com) at that IPv4. Dargo doesn't hand out a CNAME target — same A record for both apex and subdomains.

Critically: keep the orange cloud (proxy) ON for that record. That's what tells Cloudflare to actually sit in front of the request rather than just resolve DNS and step out of the way. The orange cloud is the whole point of the CDN.

Click Verify back in the Dargo portal once DNS has propagated (a minute or two). When the portal shows the domain as verified, an HTTPS certificate is auto-issued on Dargo's side too.

Step 3 — Set SSL mode to Full (strict)

This is the only step that has more than one wrong answer. In Cloudflare's SSL/TLS → Overview:

• Flexible — visitors get HTTPS but Cloudflare talks to your origin over HTTP. Don't use this. Most apps assume their connection is secure end-to-end and will misbehave (Ghost, WordPress, Discourse all break in subtle ways under Flexible).
• Full — Cloudflare talks to your origin over HTTPS but doesn't check the cert. Works but lets a man-in-the-middle on the path swap certs without anyone noticing.
• Full (strict) — Cloudflare talks to your origin over HTTPS and verifies the cert is real. Use this. Dargo issues a real Let's Encrypt cert for your custom domain, so strict verification passes.

Hit Save. Your site is now served over HTTPS end-to-end, with Cloudflare's TLS at the edge and Dargo's Let's Encrypt cert behind it.

Step 4 — Turn on the speed features

These are all toggles on Cloudflare's free plan:

• Speed → Optimization → Auto Minify for HTML, CSS, JS. On. Shaves bytes off every response.
• Speed → Optimization → Brotli. On. Better compression than gzip; modern browsers all support it.
• Speed → Optimization → Rocket Loader. Off. It defers JS in ways that break a lot of apps. Leave off.
• Speed → Optimization → Polish (image optimization). Lossy. Auto-converts your images to WebP for browsers that support it. Big bandwidth win for any image-heavy site.
• Caching → Configuration → Browser Cache TTL. 4 hours. Tells visitors' browsers to keep cached pages for 4 hours so they don't even hit Cloudflare on a refresh.

Step 5 — The admin-path gotcha

Cloudflare's default caching is conservative — it only caches things it's confident are static (images, CSS, JS, fonts). HTML is not cached by default. That's the safe default, but it also means you're not getting much speedup on the HTML pages themselves.

If you want Cloudflare to cache HTML too, you absolutely have to bypass the cache for admin paths first, or you'll log into your admin panel and see another user's session, or get logged out every page navigation. The pattern is the same for every app:

• Ghost: bypass /ghost/* and any /p/* preview paths.
• WordPress: bypass /wp-admin/*, /wp-login.php, and any path matching /?*preview=*.
• Discourse: bypass /admin/*, /u/*, /session, and any path with ?_=* (XHR cache-buster).

In Cloudflare go to Caching → Cache Rules → Create rule:

1. Name: "Bypass cache for admin paths"
2. Match: (http.request.uri.path matches "^/ghost/") — adjust to your app's admin prefix
3. Then: Bypass cache
4. Save and deploy.

Now (and only now) create a second Cache Rule to do cache HTML for the public side of the site:

1. Name: "Cache HTML edge"
2. Match: (http.request.method eq "GET" and http.host eq "blog.your-domain.com")
3. Then: Cache eligible, Edge TTL 2 hours, Browser TTL 4 hours
4. Save.

The order matters — the bypass rule must run before the cache rule. Cloudflare evaluates rules top-down; drag the bypass row above the cache row.

How to verify it's working

Open your site in an incognito window and load any page. Open DevTools → Network → click the main HTML request → look at the response headers. You're looking for:

• cf-cache-status: HIT — Cloudflare served from cache (best case). On the first visit you'll see MISS followed by HIT on the second.
• cf-cache-status: BYPASS on admin paths — that's the bypass rule working as intended.
• cf-cache-status: DYNAMIC on POST requests (logins, comments) — also expected. Never cache POST.

For a more thorough check, plug your URL into PageSpeed Insights and compare before/after. The biggest wins are usually Largest Contentful Paint (heavy images suddenly load fast) and Time to First Byte (HTML cached at the edge is delivered in tens of milliseconds globally).

The "Always Online" backup

In Caching → Configuration, turn on Always Online. When Cloudflare can't reach your Dargo device (your home internet briefly drops, you're moving the box, your ISP has a hiccup), it serves the last cached copy of each public page instead of an error. Visitors see your content instead of "this site can't be reached." When your device comes back, Always Online stands down automatically.

This is the same feature we recommend in the FAQs for anyone with unreliable home internet.

What this costs

Nothing. The Cloudflare Free plan covers everything in this guide: CDN, DDoS protection, free TLS, Polish lossy image optimization, Always Online, unlimited Cache Rules, Brotli, Auto Minify. The Free plan is also genuinely free forever — Cloudflare's business model is selling enterprise features and resale traffic, not nickel-and-diming small sites.

Common questions

Will Cloudflare see my visitor data?

Yes — all of it. Cloudflare terminates TLS at their edge to be able to cache anything at all, so by definition they see request URLs, headers, and (where uncached) response bodies. If that's a dealbreaker for the app — health data, legal documents — skip Cloudflare for that subdomain and run it directly off Dargo.

Does Cloudflare work in front of Ghost / WordPress / Discourse / [my app]?

Yes for all of those, provided you set up the admin-path bypass rule (Step 5) first. Both Ghost and WordPress have official Cloudflare integration docs you can crib from. Discourse needs the bypass + a separate rule for XHR paths — we noted those above.

What about apps that use WebSockets or Server-Sent Events?

They work. Cloudflare's free plan supports WebSocket proxying for orange-clouded records. The cache rules in Step 5 don't affect upgrade connections.

How does this interact with Dargo's bandwidth billing?

Cached requests never touch your device, so they don't count against your free monthly traffic allowance. A blog that gets 95% of its load served from Cloudflare's cache would use 5% of the bandwidth the same blog would use without CDN — that's a meaningful margin if you're flirting with overage.

Can I do this for the *.mydargo.com subdomains too?

No — those are already proxied by Cloudflare on Dargo's account, and you can't add them to your own. If you want your own CDN-layer control, point a custom domain at the app and configure Cloudflare on that.

What to do next

Pick the most public-facing app on your Dargo device, walk through Steps 1–5, then run a PageSpeed Insights check before flipping any of the speed toggles, do that, and run it again. The before/after gap is usually striking — and from there, the rest of the apps follow the same recipe.