Cloudflare Configuration Management: How to Keep Your Setup Secure and Optimized

Setting up Cloudflare takes an afternoon. Managing it is a job. You switch the nameservers, turn on the orange clouds, and your site is faster and safer by dinner. That’s the honeymoon. Then the zones multiply, the WAF rules accumulate, three engineers make changes for three different reasons, and your Cloudflare configuration quietly becomes one of the most consequential production systems you run, without anyone treating it like one.

This guide covers both halves of the problem: getting the foundational configuration right, and the part nobody writes about, keeping it secure, consistent, and optimized as your infrastructure scales. If you’re past initial setup and feeling the operational weight of managing Cloudflare across zones, teams, and time, the second half is for you.

Getting Your Cloudflare Configuration Right from the Start

When you add a zone, Cloudflare scans and imports your existing DNS records. Verify that import line by line, because the scan misses records, and a missing MX or TXT record surfaces as broken email two days later, not as an error at setup.

Next, set your SSL/TLS mode to Full (Strict) and treat everything below it as temporary scaffolding. Flexible mode sends traffic from Cloudflare to your origin over plain HTTP, which means your “encrypted” site is encrypted for exactly half its journey. It also produces the redirect loops that fill Cloudflare community forums. Put a valid certificate on your origin, use Full (Strict), and the whole class of problems disappears.

Then lock in the basics that cost nothing and prevent real attacks: enable DNSSEC and publish the DS record at your registrar, turn on Always Use HTTPS, and configure HSTS once you’re certain every subdomain serves HTTPS. HSTS is a promise browsers remember, so make it only when you can keep it.

Cloudflare DNS Configuration Best Practices

Most Cloudflare incidents I’ve seen trace back to DNS decisions that looked trivial at setup. Three areas deserve real attention.

Proxied vs DNS-Only Records

The orange cloud is the whole point of Cloudflare: proxied records get the WAF, CDN, DDoS protection, and your origin IP stays hidden. The grey cloud, DNS-only, gets none of that. The rule is simple: proxy everything that speaks HTTP, and keep everything else DNS-only, because the proxy only carries web traffic. Mail servers, SSH endpoints, and custom TCP services behind an orange cloud simply stop working.

The subtle failure is the reverse. One grey-cloud record pointing at the same server as your proxied site publishes your origin IP to anyone who looks, and attackers look. At that point your WAF is a door in a wall with a hole next to it: attackers can hit the origin directly and skip Cloudflare entirely.

Managing MX Records and Email Routing

Email breaks in two predictable ways on Cloudflare. First, someone proxies the hostname their MX record points to, and mail delivery dies because SMTP can’t traverse the proxy. MX targets must stay DNS-only, always. Second, that DNS-only mail record often points at the same IP as the website, which hands out the origin address you were hiding. If email and web share a server, that’s a real architectural decision to make, not a record to flip casually.

While you’re in the DNS panel, finish the job with the authentication trio: SPF, DKIM, and DMARC TXT records. Missing DMARC is one of the most common gaps I see in otherwise careful setups, and it’s the difference between your domain being spoofable and not.

Subdomain Configuration and Delegation

Subdomains sprawl. Marketing spins up landing pages, a SaaS vendor gets a CNAME, a team delegates a subdomain via NS records to run their own infrastructure. Each of these is fine. What’s not fine is losing the inventory. A CNAME pointing at a decommissioned SaaS app is a subdomain takeover waiting for someone to claim the abandoned target and serve content as you. Audit your records quarterly, delete what points at nothing, and treat NS delegations as standing grants of trust that need an owner.

WAF and Security Configuration

The WAF is where Cloudflare configuration stops being setup and becomes ongoing operations. Nothing here is set-and-forget.

Enabling and Tuning Managed Rulesets

Start with the Cloudflare Managed Ruleset and the OWASP Core Ruleset, but deploy both with the Log action first. Run them against two to four weeks of real traffic, including a peak, and build your inventory of false positives before a single request gets blocked. The OWASP ruleset in particular needs tuning: it scores requests cumulatively, and the right threshold for your application is something your logs tell you, not something you guess. Too strict and your CMS editors can’t save pages with embedded HTML. Too loose and the ruleset is decorative.

Custom Rules and Rate Limiting

Managed rules know attack patterns. They don’t know your application. Custom rules, written in Cloudflare’s expression language, encode what managed rules can’t: this admin path only accepts traffic from the office range, this API endpoint never sees browsers, this legacy path should be gone entirely.

Rate limiting belongs on the endpoints attackers actually hammer: login, password reset, checkout. Set thresholds from real traffic percentiles per endpoint, not one global number. And when a rule misfires, scope the exception to one rule on one endpoint. A skip covering an entire path is a hole, not a fix.

Bot Management Configuration

Cloudflare’s bot tooling scales with plan tier, from Bot Fight Mode up to full Bot Management with per-request scoring. Whatever tier you’re on, the operational mistake is the same: turning on aggressive challenges without checking what they break. Mobile app clients, payment webhooks, uptime monitors, and partner integrations all look bot-like, because they are bots. Yours. Review bot analytics first, keep verified bots allowed, and carve explicit allowances for your own automation before you challenge anything, or your first “security win” will be an outage ticket.

Cache and Performance Configuration

Caching is where configuration mistakes cost money instead of security, which makes them quieter and often more expensive.

Cache Rules and Browser TTL

By default Cloudflare doesn’t cache HTML, and that default protects you. The classic self-inflicted incident is a Cache Everything rule on a path serving personalized content: one user’s account page cached at the edge and served to strangers. If you cache HTML, do it deliberately, on genuinely static pages, with cookie-based bypasses for logged-in users. And keep Edge TTL and Browser TTL distinct in your head: edge cache you can purge in seconds, but a long Browser TTL lives in your users’ browsers where no purge button reaches.

Argo Smart Routing

Argo routes traffic around internet congestion and genuinely cuts latency for global audiences, but it bills per gigabyte. Turn it on as an experiment with a before-and-after measurement, not as a default, and remember that a traffic spike now has a routing surcharge attached. It’s one of the toggles that shows up on invoices months after everyone forgot who enabled it.

Image Optimization Settings

Polish with WebP conversion is close to free performance: smaller images, no code changes, minimal risk. Image resizing and transformations are a different economics, metered per use, so a template change that resizes every product photo on the fly can move your bill meaningfully. Enable the cheap wins broadly and the metered features deliberately.

The Real Challenge: Managing Cloudflare Configuration Over Time

Everything above is the part teams eventually get right. Here’s the part that stays broken: six months in, your Cloudflare configuration is no longer the one you set up. It’s the accumulation of every incident-time change, every quick fix, every “temporary” rule that shipped through the dashboard at 2 AM and never got reviewed.

The dashboard makes change effortless and memory optional. There’s an audit log that tells you who changed what, but it won’t restore anything, and configuration rollback exists only as an Enterprise feature. For everyone else, undoing a bad change means reconstructing the previous state from memory. Multiply that across zones and it compounds: a WAF rule tightened on your main zone after an attack doesn’t propagate to the other nineteen, so your zones drift apart until “our Cloudflare configuration” describes twenty different security postures.

Then there’s the human layer. One engineer understands why the rule logic looks the way it does, and when they’re unavailable, nobody touches it. And the billing layer: Argo, image transformations, and Workers usage all scale with configuration decisions nobody tracked, so the invoice becomes the first place drift gets noticed. This is the hidden cost of Cloudflare’s flexibility. Every knob is one click, and none of them remembers why it was turned.

How to Build a Cloudflare Configuration Management Practice

The fix isn’t discipline. It’s a system with five parts.

Document Your Baseline Configuration

Export your live configuration into version control, using the API or cf-terraforming, and declare it the approved state per zone. This is the reference every future change gets compared against. Without it, “did something change?” is an unanswerable question.

Track and Audit Every Change

Review the audit log on a schedule, not just during incidents, and alert on changes to high-stakes settings: SSL mode, WAF rules, DNS records. Every diff between live state and baseline should end one of two ways, reverted or formally adopted into the secure baseline. A diff that just sits there is drift with a timestamp.

Centralize Visibility Across Zones

The Cloudflare dashboard shows you one zone at a time, and drift lives in the gaps between them. Build a cross-zone view of your configuration state, whether that’s API scripts feeding an inventory or a purpose-built platform. This is the layer where tools like LELOPS fit: SENTRY continuously monitors your configuration state and flags unauthorized changes as they happen, and ADVISE lets anyone on the team ask in plain text how a zone is configured and why, instead of reverse-engineering rule logic under incident pressure.

Implement Role-Based Access Control

Retire the Global API Key from every script that uses it and replace it with scoped API tokens, limited to specific zones and permissions. Do the same for humans: least-privilege member roles, and narrowly scoped access for routine tasks like cache purges. The amount of drift a person can create is bounded by the access they hold.

Schedule Regular Cloudflare Configuration Reviews

Quarterly reviews are the floor. The real cadence is event-driven: review after every significant application release, every incident that touched the edge, and every Cloudflare feature change that affects your zones. Ten minutes comparing live state to baseline after each event beats a heroic annual cleanup every time.

See how LELOPS SENTRY monitors your Cloudflare configuration in real time: lelops.ai/product/sentry. Or ask LELOPS ADVISE anything about your Cloudflare setup: lelops.ai/product/advise.

FAQ