Cloudflare Free: Make Your Domain Legit, Fast & Secure — A Practical Checklist


What you get for $0 (high‑impact highlights)

• Authoritative DNS with global anycast
• Universal SSL/TLS certificates (DV), Auto-renew
• CDN caching + Brotli/Gzip compression
• DDoS mitigation (L3/4/7) when proxied (orange cloud)
• HTTP/2 and HTTP/3 (QUIC) support
• WAF Managed Rules (free ruleset) + basic firewall
• Bot Fight Mode (basic bot protection)
• Bulk & Single Redirects (for www→apex, legacy URLs)
• Email Routing (free inbound forwarding) + DMARC Management
• DNSSEC (sign your zone)
• Transform Rules (add security headers)

Step‑by‑step setup (15–30 minutes)

1) Add your domain → change nameservers at your registrar to Cloudflare’s.
2) Proxy only web traffic you want protected/accelerated (orange cloud). Leave mail-related DNS records (MX, mail.) unproxied (gray cloud).
3) Enable DNSSEC → copy DS record into your registrar.
4) SSL/TLS → set mode to “Full (strict)” after you install a valid cert on origin (or use Cloudflare Origin CA).
5) Edge certificates → Universal SSL ON.
6) Enforce HTTPS → Always Use HTTPS ON + Automatic HTTPS Rewrites ON. (Fix mixed content if any.)
7) HSTS → enable only after your site is 100% HTTPS; start at max‑age=1 day, then increase.
8) Protocols → enable HTTP/3 (QUIC).
9) Performance → enable Brotli compression (default), and default CDN caching. Consider simple Cache Rules later.
10) Redirects → configure www→apex (or vice versa) and any old URL patterns using Single Redirects or Bulk Redirects.
11) Security → turn on WAF Managed Rules and Bot Fight Mode.
12) Email → set up Email Routing for hello@yourdomain → your inbox, add SPF/DKIM/DMARC (and enable DMARC Management).
13) Headers → add or verify security headers via Transform Rules (see examples).

Minimum viable security settings (safe defaults)

• SSL/TLS: Full (strict)
• Always Use HTTPS: ON
• Automatic HTTPS Rewrites: ON
• HTTP/3 (QUIC): ON
• WAF → Managed Rules: ON (Cloudflare Managed Ruleset + Free Managed Ruleset)
• Bot Fight Mode: ON (monitor for false positives)
• DNSSEC: ON
• HSTS: start low (e.g., 1 day), includeSubDomains=off initially

Performance basics (no knobs required)

• CDN caching on by default for static assets
• Brotli/Gzip compression automatically applied
• HTTP/2/3 multiplexing and connection reuse

Redirect recipes

A. Force www → apex (or the reverse) with a Single Redirect rule.
B. Bulk legacy URLs → use Bulk Redirects via a list (CSV import available).

# Example (Bulk Redirects list CSV)
source_url,target_url,status
https://old.example.com/blog/(.*),https://example.com/blog/$1,301
https://example.com/old-doc,https://example.com/new-doc,301

Note: use wildcards with Single Redirects; use lists for many static mappings.

Add security headers with Transform Rules

# Response header transforms (examples)
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Referrer-Policy: no-referrer-when-downgrade
Permissions-Policy: camera=(), microphone=(), geolocation=()

Tip: test HSTS carefully; once preloaded, rollbacks are slow.

Turnstile (free CAPTCHA replacement)

Protect forms/logins without messing up UX. Two‑minute setup:

<!-- HTML -->
<script src="https://challenges.cloudflare.com/turnstile/v0/api.js" async defer></script>
<form action="/signup" method="POST">
  <div class="cf-turnstile" data-sitekey="YOUR_SITE_KEY"></div>
  <button>Sign up</button>
</form>

// Server (pseudo):
// verify response token by POSTing to https://challenges.cloudflare.com/turnstile/v0/siteverify

Email: forwarding + authentication

• Email Routing: create hello@yourdomain and forward to your real inbox.
• Add SPF (TXT), DKIM (from your sending provider), and DMARC (TXT). Enable DMARC Management to visualize reports.
• If you do not send mail from the domain, publish a “reject all” DMARC policy.

WAF & Bot protection quick start

• Security → WAF → enable Cloudflare Managed Ruleset (and Free Managed Ruleset) in Block or Challenge.
• Security → Bots → enable Bot Fight Mode. If you see issues, reduce to “Managed Challenge” or add exceptions.

Verifying it works

• SSL: visit https://yourdomain — certificate should be issued by Cloudflare.
• HTTP/3: check DevTools → Protocol h3 (or use curl: curl -I --http3 https://yourdomain).
• Redirects: try http://www.yourdomain → should 301 to HTTPS canonical.
• DNSSEC: use a DNS checker to confirm DS records propagate.
• Security: Cloudflare dashboard → Security → Events (watch WAF/Bot actions).

Common footguns

• Using “Flexible” SSL mode (don’t) — enables HTTPS to users but HTTP to your origin; use Full (strict).
• Proxying mail (MX/IMAP/SMTP) — leave mail hostnames unproxied (gray cloud).
• Turning on HSTS before your site is fully HTTPS.
• Breaking APIs with over‑aggressive WAF rules — start in Log/Simulate, then tighten.

Appendix: One‑time origin cert (if you lack a valid cert)

Cloudflare → SSL/TLS → Origin Server → Create certificate → Install on your origin → Set SSL mode to Full (strict).


Taylor Swift

“I keep my side of the street clean.”

Comments

Post a Comment

Popular posts from this blog

Learning to Automate My Side Projects with SWE-agent + GitLab

Image
I wanted to share something I built. I managed to connect SWE-agent with my self-hosted GitLab so that Issues can drive automation—and I think it’s kind of cool. (Currently, it isn’t directly supported in SWE-Agent, but there is an issue ( https://github.com/SWE-agent/SWE-agent/issues/760 ) on GitHub to add support. Why wait? ^_^) I’ve been tinkering with SWE-agent in the homelab while between roles. SWE-agent doesn’t natively support GitLab, but that wasn’t going to stop me—I wired it into my self-hosted GitLab instance so Issues drive the automation end-to-end. The Flow I Built 1. Start with an Issue. When I create an Issue, I describe the task in plain language. For example: “create `/taylor-swift` route that responds with JSON key lucky=13.” 2. Label the intent. Add the label `run:swe` and tag the model (in my case: `model:qwen3-coder-30b-a3b-instruct` from LM Studio). There is also a label swe:in-progress so that the pipeline does not pick up in-progress issues. If the pipeline ne...
Read more

Ship-Ready Web Essentials: Search, Sitemap, Metadata & Icons (SvelteKit)

This guide is a pragmatic, production-minded checklist and how-to for hardening a SvelteKit landing site so it’s discoverable by search engines, understandable by AI crawlers, and delightful on modern devices. It includes file locations, example contents, and verification steps. Everything here works even if you only have a single landing page today. Branding note: this document uses a fictional brand (“Example Store”) and domain (example.com). Replace these with your own values when you implement. Quick To-Do Checklist • Serve a real XML sitemap at /sitemap.xml and reference it in robots.txt. • Add a lightweight, server-rendered /search?q=… endpoint (backs JSON-LD SearchAction). • Place ai.txt (allow/deny AI crawlers) and .well-known/security.txt (vuln-reporting). • Wire canonical Open Graph/Twitter tags and og.png for social previews. • Add platform icons (apple-touch-icon.png, safari-pinned-tab.svg) and site.webmanifest. • Harden app.html with meta theme-color (light/dark), color-sc...
Read more

Kubernetes Secrets Management — SOPS + age (GitOps‑friendly)

Image
  Owner: Platform Engineering Audience: Devs & Ops Status: Adopted This document captures the exact process we use to manage Kubernetes secrets with Mozilla SOPS and the age encryption tool. It includes why we chose this approach, how to work with secrets day‑to‑day, and trade‑offs versus other methods. Executive Summary We store Kubernetes Secret manifests in Git encrypted at rest using SOPS with an age public key.  SOPS encrypts your secret values with AES‑256‑GCM , which is industry gold standard. In SOPS you can not swap AES‑256‑GCM out. The age private key lives only in protected CI variables. CI decrypts the manifests at deploy time and applies them with kubectl. No in‑cluster controllers, CRDs, or webhooks are required. Why this approach Top benefits: • Zero in‑cluster installs (no CRDs/controllers to run or break). • GitOps‑native: encrypted YAML sits in the repo; diffs remain readable (metadata & keys stay visible). • Cloud‑agnostic: age works anywhere; no ...
Read more