Cloudflare Product Cheat Sheet

Powered by Pagescloudflarequickreference Access@cloudflare.com policy Workerscheatsheet-chatbot Workers AIllama-4-scout-17b AI Gatewaycheatsheet-chatbot Durable ObjectsPresence

Quick lookup during calls — search the sidebar, jump to talk tracks, scan reference cards.

Customer Quick Reference

Just starting outFree — DNS + basic security + CDN
Growing site / businessPro — WAF + perf + rate limiting
E-commerce / paymentsBusiness — PCI + image opt + priority support
Can't afford downtimeEnterprise — SLA + Bot Mgmt + API Shield + 24/7
API-heavy SaaSEnterprise — API Shield + Bots + RL + Workers
VPN replacementZero Trust (Access + Gateway), per-seat
Multi-office / global netMagic WAN + Magic Transit (replaces MPLS)
Video / mediaStream + CDN + R2
AI-powered appWorkers AI + AI Gateway + R2 + Workers

Plan Comparison Expand all sections Collapse all

Data sourced from cloudflare.com/plans (Application Services). Pricing: Free $0 · Pro $20/mo annual ($25 monthly) · Business $200/mo annual ($250 monthly) · Enterprise custom (annual contract).

Core Features 14 features
FeatureFreeProBusinessEnterprise
Fast, Easy-to-use DNS✓✓✓✓
Unmetered DDoS Protection✓✓✓✓
CDN✓✓✓✓
Universal SSL Certificate✓✓✓✓
Free Managed Ruleset✓✓✓✓
Web Application Firewall (WAF)✓✓✓✓
Lossless Image Optimization—✓✓✓
Accelerated Mobile Pages (AMP)—✓✓✓
PCI DSS 4.0 Compliance——✓✓
Uptime SLA——100%100%
Uptime Service Credits——1x10x (Std); 25x (Premium)
Single Sign-On (SSO) Support✓✓✓✓
Network Prioritization———✓
Role-based Account Control✓✓✓✓
Support 1 feature
FeatureFreeProBusinessEnterprise
Support Options Community forums + docs Tickets + Community forums Tickets + Chat + Community forums 24×7×365 Tickets + Chat + Phone + Community forums
Rules & Routing 1 feature
FeatureFreeProBusinessEnterprise
Cloudflare Rules 70 rules + 10K Bulk Redirects 225 rules + 25K Bulk Redirects 450 rules + 50K Bulk Redirects 2,700 rules + 1M Bulk Redirects
Security 7 features
FeatureFreeProBusinessEnterprise
Bot Mitigation Simple bots Easy-to-detect bots Sophisticated bots + basic analytics All bots, anomaly detection, custom CAPTCHAs, advanced analytics
API Schema Validation Up to 5 schemas Up to 5 schemas Up to 10 schemas 10+ schemas
API Shield———Custom Pricing
Client-Side Security Script monitoring Script monitoring Resource monitoring + alerts Malicious resource detection + code change alerts + positive blocking
AI Security for Apps———Custom Pricing
L3 Network DDoS (Magic Transit)———Custom Pricing
China Network Access———Custom Pricing
Platform 1 feature
FeatureFreeProBusinessEnterprise
Cloudflare for SaaS <100 hostnames free, $0.10/additional <100 hostnames free, $0.10/additional <100 hostnames free, $0.10/additional Custom Pricing

Quick Lines for Common Questions

"What's the difference between Pro and Enterprise?"
Say"Enterprise gives you an SLA, Bot Management, API Shield, and a human to call at 2am. Pro is great protection — Enterprise is protection with guarantees."
"Do you charge for attack traffic?"
Say"No, never. Unmetered DDoS on every plan."
"How is Workers different from Lambda?"
Say"Workers run at the edge (not a region). Sub-ms cold starts. V8 isolates, not containers."
"Can you replace our VPN?"
Say"Yes — Cloudflare Access. Users authenticate to apps, not the network. No VPN client."
"How is R2 different from S3?"
Say"No egress fees. Global read performance. Integrated with Workers."
"What's your SLA?"
Say"Pro is best-effort. Enterprise is 100% uptime with service credits."
"Can we test before committing?"
Say"Yes — Bot Management runs in log-only mode first. Workers has a generous free tier. Most products can be piloted before purchase."

Zero Trust Dashboard Map

Quick reference for the most-used sections of the Zero Trust dashboard at one.dash.cloudflare.com. Covers what customers actually ask about — not every menu item, just the common ones.

one.dash.cloudflare.com
Zero Trust has its own dashboard — separate from the main Cloudflare dashboard. Click "Zero Trust" in the main dashboard's left nav, or go directly to the URL above.
  • Insights & Logs → Logs — every authentication, every Gateway DNS/HTTP/Network decision, every Access app load. The investigation workhorse. Filter by user, app, action, time. Logpush exports to SIEM.
  • Team & Resources → Users / Devices — active users in your org, registered devices, posture check status. Where you'd look to confirm somebody's actually onboarded.
  • Team & Resources → Application library — catalog of supported SaaS apps with pre-built Access integrations (Salesforce, M365, Slack, etc.).
  • Networks → Connectors — Cloudflare Tunnels (outbound origin connections), WARP Connectors (cloud/virtual sites). Where you create new tunnels.
  • Networks → Routes — IP ranges and hostnames routed through tunnels. The map of "what does this tunnel expose."
  • Access controls → Applications — the big one. List of all protected apps (self-hosted, SaaS, private network, infrastructure). Add new apps here.
  • Access controls → Policies — reusable Allow/Block/Bypass rules. Build once, apply to multiple apps.
  • Access controls → Service credentials — service tokens for non-human access (CI/CD pipelines, automation).
  • Traffic policies → Firewall policies — Gateway DNS, Network, and HTTP filtering rules. The "what employees can/can't reach on the internet" controls.
  • Traffic policies → Resolver policies — custom DNS resolution rules (route specific domains to specific resolvers).
  • Traffic policies → Egress policies — control which IP your traffic exits from. Enterprise + Dedicated Egress IPs required.
  • Cloud & SaaS findings — CASB results. Misconfigurations in your SaaS apps (M365, Google Workspace, Salesforce) and data exposure findings.
  • Email security — opens the Email Security portal. Threats blocked, detection settings, allow/block lists.
  • Data loss prevention → Profiles — DLP rules (PII, PCI, custom regex). Reference these from HTTP policies to scan outbound traffic.
  • Browser isolation — Remote Browser Isolation settings. Per-policy or always-on isolation configs.
  • Reusable components → Lists — saved lists of domains, IPs, URLs, hashes referenced by policies. Edit a list, every policy using it updates.
  • Reusable components → Posture checks — device requirements (OS version, disk encryption, EDR, etc.). Reference these in Access policies.
  • Integrations → Identity providers — Okta, Entra, Google, SAML, OIDC. Configure once; reference in Access policies.
  • Integrations → Cloud & SaaS — connect M365, Google Workspace, Salesforce, etc. for CASB scanning.
  • Settings → WARP Client — device enrollment rules, deployment profiles, install URLs. Where you control the WARP rollout.
  • Settings → Authentication — global identity provider settings, login methods, MFA enforcement.
The dashboard layout shifts over time. If a customer can't find an item, search Cmd+K in the dashboard or check the Cloudflare docs for the current path.

Talk Tracks Expand all deep dives Collapse all

Each product has a Deep Dive dropdown below the talk track — click to expand for technical detail, anticipated questions, industry angles, pricing, gotchas, and dashboard navigation paths.

Dashboard nav legend: ZONE = per-domain settings (each domain you manage)  •  = global settings (apply across your whole account)
Cloudflare's dashboard layout shifts over time — verify menu paths before critical demos.

CDN / Caching All Plans

What
Caches static content (images, CSS, JS, video) at the edge.
Why
Faster load times, origin offload, lower bandwidth costs.
How
First request fetches from origin → cached at PoP → served from edge after. Cache Rules give surgical control.
Say"Okay so think about it like this — normally when somebody visits your website, their browser has to talk to your server, which might be sitting in one city somewhere. If the visitor is on the other side of the world, that's a long round trip. What we do is keep copies of your stuff — your images, your videos, your scripts — in 330 cities around the world. So when a visitor hits your site, they're actually grabbing it from the city closest to them, which is way faster. That's called a CDN, or content delivery network. The cool part is your server doesn't have to do as much work, so you can handle way more traffic without buying bigger servers, and your bandwidth bill goes down. Most customers end up serving 70 to 95% of their traffic from us instead of their origin."
Customer Scenario The setup:A regional news site — heavy traffic spikes when big stories break, normal traffic between. Origin is two servers on a colo in Atlanta serving the whole US, no CDN. The pain:Origin keeps falling over during traffic spikes. Last election night their site went down for 40 minutes — exactly when the most readers were trying to reach them. Bandwidth bill from the colo is $7K/month and growing. Articles load slow on the west coast. What they built:Pointed DNS at Cloudflare, turned on caching with default rules, then dialed in Cache Rules to also cache article HTML for a few minutes (with smart invalidation when editors publish updates). No application changes — just DNS and config. The outcome:Cache hit ratio went from 0% to about 92%. Origin traffic dropped to a tenth of what it was. The colo bandwidth bill came down. Next election night, traffic 5x'd the previous record and origin barely noticed.
Objection: "We already use a CDN""Most CDNs do basic caching — with us you also get DDoS, WAF, and bot management in one pass. No separate CDN + security provider."
Objection: "Everything is dynamic""Even dynamic sites have static assets. And Cache Rules let you cache more than you'd think — API responses, partial pages, conditional caching."
Deep Dive — CDN / Caching
How it actually works
  • Anycast network: ~330 cities globally. The same IP routes to whichever PoP is closest to the user.
  • Tiered Caching: Edge PoP → Regional Tier → Origin. Reduces origin requests dramatically — a single regional tier holds cached objects so 20 edge PoPs don't each ask origin.
  • Cache key: Default key is URL + host. You can customize via Cache Rules to include cookies, headers, query params (or strip them) — critical for things like personalized pages, language variants, currency.
  • Cache TTL hierarchy: Origin Cache-Control headers win unless overridden. Edge TTL (Cloudflare) vs browser TTL (downstream) are independently controllable.
  • Purge: Single URL, tag-based (Enterprise), or purge-by-prefix (Enterprise). Tag-based purge is huge for CMS — purge "blog-post-123" and every page referencing that tag clears instantly.
  • Cache Reserve: Persistent R2-backed cache for assets you want to keep cached for months without ever re-fetching from origin.
Anticipated customer questions
"What's your cache hit ratio typically?"Depends on traffic profile — most sites see 70–95% on static. We give you the analytics; tune via Cache Rules to lift it.
"Can you cache HTML?"Yes — but be careful with personalized HTML. Use Cache Rules to bypass cache for logged-in users (check session cookie) and cache for anonymous.
"How fast is purge?"Global purge in <5 seconds typically. Often sub-second.
"What about cache poisoning?"Cache key controls what variations are stored. We also have rules that detect and prevent classic cache poisoning vectors (Host header tricks, etc.).
"How do you handle origin failures?"Always Online serves stale cached content if origin is down. Combined with Tiered Caching, your site stays up through origin outages.
"Can we cache POST requests?"Generally no — POST is by definition non-idempotent. For specific cases (search APIs, GraphQL), use Workers to transform into cacheable GETs.
"What about bandwidth costs?"Bandwidth out of Cloudflare is included on all plans. No surprise egress fees from CF to the user.
"Does it cache video?"Yes — HLS/DASH segments are cacheable. For dedicated video workflows use Stream.
"What about cache compliance / GDPR?"Cached objects don't contain identifiable data unless you cache personalized HTML carelessly. Cache keys + bypass rules handle compliance cleanly.
Industry angles
Ecommerce
Product pages cached aggressively; cart/checkout bypass cache via cookie rules. Catalog purges via tags.
Media
HTML caching with short TTL for breaking news; image/video segments cached long. Cache Reserve for archive content.
SaaS
Static assets at edge; API responses cached with stale-while-revalidate via Workers.
Gaming
Patch files via Cache Reserve — multi-GB downloads pulled once from origin, served globally for months.
Healthcare
Static portal assets cached; patient data routes bypass cache entirely with explicit rules.
Pricing notes: CDN bandwidth is included on every plan. Cache Reserve and Tiered Cache topology features are Enterprise. Cache analytics granularity increases with plan tier.
Gotcha: If your origin sends Cache-Control: no-cache or private on responses, we honor it — you'll see low hit ratios until you fix origin headers or use Cache Rules to override.
Gotcha: Query strings are part of the default cache key. Tracking params (utm_*, fbclid) fragment your cache catastrophically — use Cache Rules to strip them.
Gotcha: Vary header from origin can also fragment cache. Watch for Vary: User-Agent — it creates a separate cached copy per browser.
Where to find it in the dashboard
Zone Caching
Pick your domain first, then click Caching in the left sidebar.
  • Overview — high-level cache hit ratio, bandwidth saved, total requests cached.
  • Configuration — Browser Cache TTL, Always Online, Crawler Hints, Development Mode (bypass cache for 3 hours during testing).
  • Cache Rules — the main place to control what gets cached and how. Surgical control over cache key, edge TTL, and per-rule behavior.
  • Tiered Cache — enable Smart Tiered Caching (single regional tier) or Generic Global Tiered Cache (ENT topology).
  • Cache Reserve — persistent R2-backed cache for long-tail content.
  • Purge Cache — purge by URL, tag, hostname, prefix, or everything.

Argo Smart Routing

What
Routes web traffic across the fastest available paths on Cloudflare's network, avoiding congestion in real time.
Why
Default internet routing follows the cheapest path, not the fastest. Argo picks the path with lowest latency and packet loss.
How
Cloudflare's network monitors latency between data centers in real time. Argo routes uncacheable traffic (API calls, dynamic content) through the optimal path, not the BGP default.
Say"So you know how when you drive somewhere, Waze finds the fastest route based on real-time traffic? Argo Smart Routing does the same thing for your internet traffic. The internet's default routing is built around cost, not speed — your traffic takes the cheapest path between networks, not the fastest one. Argo flips that. We're measuring latency between our 330 data centers all the time, so when somebody hits your site, we route their traffic over the path that's actually fastest at that moment instead of whatever the default route happens to be. Customers typically see 30% faster response times on dynamic content. The bigger the distance between your users and your origin server, the more it helps. It's a paid add-on with usage-based pricing — you only pay for traffic that actually uses it."
Customer Scenario The setup:A US-based SaaS company has expanded into APAC. Their customers in Singapore, Tokyo, and Sydney use a dashboard that hits a logged-in API constantly — uncacheable, every request goes to their origin in us-east-1. The pain:APAC customers complained the app felt sluggish. Page loads were 1.5-2 seconds for them vs. 400ms for US users. Sales started losing APAC renewals to a competitor with regional infrastructure. What they built:Turned on Argo. No code changes. Cloudflare started routing the APAC-to-Virginia traffic over its measured-best path instead of the default internet routes. The outcome:APAC dashboard latency dropped ~35%. The APAC team stopped getting churn complaints about app speed. The argo bill was a tiny fraction of what regional infrastructure would have cost.
Objection: "We already use a CDN, isn't this the same thing?""No — CDN caching speeds up your static content (images, CSS, video) by storing copies near users. Argo speeds up your dynamic content (API calls, logged-in pages, anything that can't be cached) by finding the fastest path to your origin. They complement each other. CDN handles cacheable stuff; Argo handles everything else."
Objection: "What does the 30% number actually mean?""Average improvement on time-to-first-byte for uncacheable traffic, measured across all customers using Argo. Your mileage varies — the bigger the geographic gap between your users and origin, the more improvement. Customers with users in Asia hitting an origin in the US see way more than 30%. Customers with everything in one region see less."
Objection: "We can't really measure it, how do we know it's working?""Argo includes built-in analytics showing the latency improvement with Argo on vs Argo off. So you can literally see the delta. We also do an automatic A/B comparison so you don't have to set up the measurement yourself."
Deep Dive — Argo Smart Routing
How it actually works
  • Real-time path measurement: Cloudflare continuously measures latency and packet loss between every pair of data centers in our 330+ location network. That data is updated constantly.
  • Path optimization: When a request comes in, Argo picks the path through Cloudflare's network that's currently fastest end-to-end — not the BGP default path the internet would normally choose.
  • Applies to uncacheable traffic primarily: Cached content already serves from the edge so it doesn't need Argo. The big wins are on dynamic content — API calls, authenticated pages, anything Cloudflare can't cache.
  • Network-side optimization: Customer makes no code changes, no DNS changes, no configuration beyond a toggle. The Cloudflare network handles routing decisions transparently.
  • Tiered Cache pairing: Cloudflare recommends enabling Tiered Cache alongside Argo. Argo optimizes the path from edge to origin; Tiered Cache reduces how often you need to go to origin at all. Together they're more effective than either alone.
  • Now part of Smart Shield bundle: Argo Smart Routing is offered as a component of the newer Smart Shield product, which bundles Argo + Smart Tiered Cache + connection reuse + (depending on tier) Regional Tiered Cache, Cache Reserve, Health Checks, and Dedicated CDN Egress IPs. Argo is still available standalone too.
Anticipated customer questions
"What's the typical performance improvement?"~30% average on time-to-first-byte for uncacheable traffic. Higher for cross-continental traffic (users in Asia, origin in US), lower for single-region setups. Built-in analytics show the actual delta for the customer's traffic specifically.
"How does it differ from default Cloudflare routing?"Default routing uses the BGP path that the internet picks for cost reasons. Argo picks the path that's currently fastest based on real-time measurements between our data centers. Same network, different routing decision.
"How much does it cost?"Usage-based pricing per GB of traffic that uses Argo. Attack traffic mitigated by DDoS/WAF doesn't get billed. Enterprise customers can preview it as a non-contract service with full access free of metered fees during the preview.
"What if our origin is in the same region as our users?"Argo helps less when there's not much geographic distance to optimize. For pure single-region setups (everything in US East, all users in US East), the improvement is modest. For global apps, much more impactful.
"Does it work with cached content too?"Mostly for uncacheable traffic since cached content already serves from the edge. Where it helps with caching is the "edge to origin" hop on cache misses — Argo finds the fastest path for that fetch.
"What about Smart Shield — what's the difference?"Smart Shield is the newer bundled package that includes Argo Smart Routing plus origin protection features (Smart Tiered Cache, connection reuse, etc.). Argo is one component. For customers wanting just the routing optimization, standalone Argo still works. For customers wanting the full origin-performance suite, Smart Shield is the buying motion.
"How do we measure ROI?"Argo Analytics tab in the dashboard shows latency with vs without Argo on a rolling basis. You can also pair with Web Analytics or RUM tooling to correlate with conversion rate, bounce rate, etc.
"Will it improve our SEO?"Indirectly. Google ranks faster pages higher. If Argo reduces your TTFB by 30%, that's a meaningful Core Web Vitals improvement, which factors into Google's ranking signals.
"How fast can we enable it?"Single toggle in the dashboard. No DNS changes, no code changes, no waiting for propagation beyond a few minutes. You can also turn it off just as quickly to verify the impact.
"What about for API workloads?"This is actually where Argo shines the most. APIs are pure uncacheable dynamic content. If you have a mobile app calling an API in another region, Argo can meaningfully reduce response times.
Industry angles
Fintech
Trading platforms, banking apps with real-time data feeds. Latency matters for user experience and (sometimes) for transaction outcomes.
Ecommerce
Cart, checkout, search — all dynamic, all latency-sensitive. Higher conversion correlates with lower latency. Argo helps the parts of the site CDN can't.
SaaS
App backends serving global users. Multi-tenant SaaS often has origins in one region but users everywhere — exactly the gap Argo closes.
Gaming
Lobby APIs, matchmaking, real-time player state. Sub-second latency improvements meaningful for player experience.
Media
Personalized content recommendations, paywall checks, user state — all uncacheable, all latency-sensitive.
Travel / Booking
Real-time inventory queries (flights, hotels, rentals) hit backend APIs that can't be cached. Argo speeds these up directly.
Pricing notes: Usage-based — pay per GB of traffic routed through Argo. Mitigated attack traffic is excluded from billing. Enterprise customers can use it as a "preview service" — full access, no metered fees during preview. Set up usage-based billing notifications to avoid surprise bills.
Gotcha: Single-region setups (users and origin both in the same metro) see modest improvement. Don't oversell Argo to a customer whose entire footprint is in one location.
Gotcha: Cached content already serves from the edge — Argo's value is primarily on uncacheable / dynamic traffic. If a customer's site is 95% cacheable, the impact of Argo is smaller than for a customer with API-heavy traffic.
Gotcha: Usage-based billing means costs scale with traffic. For very high-volume sites, this can add up. Recommend setting up billing alerts during the trial.
Gotcha: Argo is being repositioned as part of Smart Shield. Long-term, the buying motion is moving toward the Smart Shield bundle. Standalone Argo still works, but expect Smart Shield to be the primary buying path going forward.
Gotcha: Argo only optimizes traffic that passes through Cloudflare's network. If a customer has dynamic traffic that bypasses Cloudflare (e.g., direct origin connections from mobile apps not proxied through us), Argo can't help that traffic.
Where to find it in the dashboard
Zone Traffic → Argo Smart Routing
Pick your domain first, then find Argo Smart Routing under the Traffic menu. Single toggle to enable; analytics tab to view the latency improvement.
  • Argo Smart Routing toggle — single switch to enable or disable per zone. Requires billing profile on the account.
  • Analytics — built-in comparison of latency with vs without Argo enabled. Shows the actual performance delta for your traffic.

Notifications → Usage Based Billing
Set up usage notifications so you don't get surprised by Argo billing. Cloudflare specifically recommends this.

Zone Caching → Tiered Cache
Recommended companion. Tiered Cache reduces origin requests; Argo speeds up the ones that still happen. Together they're stronger than either alone.

Load Balancing

What
Distribute traffic across multiple origin servers, data centers, or cloud regions. Health checks, failover, geo-steering, weighted routing — all from Cloudflare's network.
Why
Any production app needs to survive an origin failure. Traditional load balancers live inside one region — they don't help when that region goes down. Cloudflare Load Balancing operates from 330+ PoPs globally, routes around failures automatically, and steers traffic by geography, latency, or custom logic.
Say"Load Balancing distributes traffic across multiple origins. The classic use case: you have your app running in us-east-1 AWS and us-west-2 AWS. If us-east-1 goes down, you want traffic to fail over to us-west-2 automatically. Cloudflare runs health checks against your origins continuously, marks failed ones as unhealthy, and routes new requests to healthy origins. You can also do smart things — geo-steering (US visitors go to US origins, EU visitors go to EU origins), latency steering (always pick the fastest origin from the visitor's PoP), weighted distribution (90% to new origin, 10% to old during migration), random / round-robin for simple load spread. It works at the DNS layer for any TCP/UDP service, and at the HTTP layer with deeper integration to the rest of Cloudflare's stack. Plus the health checks are first-class — you set up monitors with custom hostnames, headers, expected response codes, retry logic, and they run from multiple regions to avoid false positives."
Customer Scenario The setup:An online learning platform runs their core app in two AWS regions (us-east-1 and eu-west-1) for redundancy. They used Route 53 health checks with DNS failover. The pain:When us-east-1 had a partial outage, DNS TTLs meant traffic kept hitting the dead region for 5-7 minutes before clients picked up the new record. They lost 4,000+ student sessions in that window. Customer success spent two days writing apology emails. What they built:Migrated to Cloudflare Load Balancing with HTTP-layer steering. Health checks run from multiple Cloudflare regions every 15 seconds. Latency-steering sends EU users to eu-west-1 and US users to us-east-1 by default. Failover happens in seconds at the edge — no DNS TTL involved. The outcome:Next time us-east-1 hiccupped, failover happened in under 30 seconds. Students barely noticed — a single dropped request, then traffic flowed to eu-west-1. No mass apology email needed.
Objection: "We use AWS ALB / NLB""AWS load balancers are great inside one region. They don't help with multi-region failover — for that you'd need Route 53 health checks + DNS failover, which is functional but limited. Cloudflare LB is purpose-built for multi-region / multi-cloud — global health checks, anycast DNS responses, faster failover (seconds vs minutes), works across providers."
Objection: "We just use DNS round-robin""Round-robin works until something fails. Then half your traffic goes to a dead origin and stays there until DNS TTL expires — usually 5+ minutes of outage. Load Balancing with health checks pulls dead origins out of rotation immediately. For any customer-facing app, the SLA difference is real."
Deep Dive — Load Balancing
How it actually works
  • Pools: Group of origin servers. Each origin has a hostname or IP, a weight, an enable/disable toggle. Pools are the load-balanced unit.
  • Monitors: Health checks. Configure HTTP path, expected status, expected response body, headers, timeout, retry, frequency. Cloudflare runs monitors from multiple regions to avoid one-region false positives.
  • Load balancers: Front-end DNS records (lb.example.com) that route to pools by policy. Per-LB: which pools to use, geo-fallback order, traffic steering policy.
  • Steering policies:
    • Off (failover): Use first healthy pool in order.
    • Geo: Map regions to specific pools (US visitors → US pool, EU → EU pool).
    • Random: Probabilistic distribution.
    • Dynamic latency: Cloudflare measures latency from each PoP to each pool, picks fastest.
    • Proximity: Geographic distance from visitor PoP to pool location.
    • Weighted random: Distribute by configurable weights — useful for blue-green / canary deploys.
    • Least outstanding requests (Enterprise): Send to pool with fewest in-flight requests.
  • Session affinity: Sticky sessions via cookie. Once user lands on a pool, stays there for configurable duration.
  • Custom rules (Enterprise): Rule-based steering — route /api/* to pool A, route everything else to pool B. Or route based on headers, geo, ASN.
  • Layer support: HTTP load balancing (default), TCP load balancing for non-HTTP services, UDP load balancing for game servers / VoIP (Spectrum integration).
  • Workers integration: Workers can dynamically pick pools / origins via Worker code, replacing the static config for custom routing logic.
Anticipated customer questions
"How fast is failover?"Health check detects failure within seconds (frequency configurable, default 60s, minimum 10s on Enterprise). Once unhealthy, removed from rotation immediately for new requests. For active sessions, depends on session affinity behavior.
"Multi-cloud — does it work across AWS / GCP / Azure / on-prem?"Yes — origins are just hostnames or IPs. Mix and match across clouds, on-prem, edge. Common pattern: primary on AWS, failover to GCP / on-prem.
"How does pricing work?"Per-pool monthly fee + per-DNS-query / per-HTTP-request usage. Pro plans include some pools/queries. Enterprise: custom commit. Cheaper than running a dedicated multi-region load balancer in any cloud.
"What about session affinity?"Cookie-based affinity supported. Visitor sticks to a pool for configured duration. Useful for stateful apps that haven't moved state out of memory. Pair with Durable Objects if you want stateful without affinity.
"Health check from where?"Multiple Cloudflare regions probe origins simultaneously. Failure requires majority of probes to fail — avoids false positives from single-region network issues.
"Can we do gradual rollouts?"Yes — weighted random steering. Start new pool at 5%, monitor, increase to 25%, 50%, 100%. Classic blue-green / canary pattern.
"HTTPS / certs?"Cloudflare terminates TLS at the edge, talks to origins over HTTPS (or HTTP for internal). Origin certs handled by Cloudflare or your provider. Same TLS story as any proxied Cloudflare zone.
"What about WebSockets / long-lived connections?"Supported. Affinity recommended for WebSockets so the connection stays on one pool. Failover during an active connection is a reconnect, not transparent.
"DNS-only mode for non-proxied zones?"Yes — Load Balancing can return different DNS answers per visitor based on geo / latency / health, without proxying traffic. Useful for non-HTTP services or compliance scenarios where proxying is restricted.
Industry angles
SaaS
Multi-region active-active for HA. Geo-steering for data residency (EU visitors hit EU pool). Blue-green deploys via weighted steering.
Ecommerce
Failover during region outages. Latency steering for global customers. Sticky sessions for checkout flow.
Fintech
Multi-region for SLA. Health checks with custom auth headers. Logpush of LB events for SRE.
Gaming
Geo-steering for low-latency matchmaking. UDP load balancing for game servers. TCP for chat / lobby.
Migration scenarios
Migrating from one cloud to another — weighted steering moves traffic gradually from old to new.
Pricing: Per-pool monthly fee plus per-query (DNS) or per-request (HTTP) usage. Pro / Business plans include some pools and queries. Enterprise: custom commit. Free tier doesn't include LB.
Gotcha: Health checks need accurate endpoints — a /health URL that returns 200 even when the app is broken is worse than no health check. Check what matters (DB connection, downstream APIs).
Gotcha: Session affinity uses cookies. If your app can't tolerate cookies (some compliance regimes) or visitors clear them, affinity breaks.
Gotcha: DNS LB cache effects — DNS resolvers cache responses for TTL. Failover via DNS is bounded by client-side TTL. HTTP LB doesn't have this issue.
Gotcha: Origin must accept Cloudflare IP ranges (or use Tunnel / Argo Tunnel). Allowlisting required for direct origin connections.
Gotcha: Geo-steering accuracy depends on visitor geolocation, which is IP-based and imperfect. Edge cases: VPN users, mobile carriers, corporate proxies routed unexpectedly.
Where to find it in the dashboard
Traffic → Load Balancing
  • Load balancers — front-end records, attached pools, steering policy.
  • Pools — groups of origins, weights, monitor assignment.
  • Monitors — health check definitions (path, headers, expected response).
  • Analytics — request volume per pool, health check success rate, failover events.
  • Custom Rules (Enterprise) — header / geo / path-based routing rules.

DDoS Protection All Plans (Unmetered)

What
Absorbs L3/L4/L7 volumetric attacks at the edge — automatic, unmetered.
Pro
Automatic baseline mitigation.
Enterprise
Adaptive DDoS (learns baseline) + SOC contact + 100% SLA + post-incident reporting.
Say"A DDoS attack is basically when somebody tries to take your website offline by flooding it with so much fake traffic that real visitors can't get through. It's kind of like a traffic jam — except somebody is sending thousands of empty cars on purpose to block the road. Here's what we do — because we have data centers in 330 cities, attack traffic gets spread out across all of them, so no single one ever gets overwhelmed. Our total network capacity is about 500 terabits per second, which is bigger than any attack that's ever existed — the biggest one we've ever stopped was 31.4 terabits. And we don't charge extra during an attack, ever. That's been our policy for over a decade. On Enterprise, you also get a 24/7 phone line where our engineers pick up during an attack, and a 100% uptime guarantee with money back if we ever miss it."
Customer Scenario The setup:A mid-sized fintech serving consumer lending decisions. Their app is on AWS with AWS Shield Standard. They've never been seriously attacked — until they were. The pain:A 1.2 Tbps volumetric attack hit them on a Tuesday afternoon. AWS Shield Standard absorbed some of it but their ALB started timing out. AWS Shield Advanced was a $36K/year commitment they'd been putting off. They had a hard outage during business hours and started getting calls from regulated customers. What they built:Moved DNS to Cloudflare the same week. Every Cloudflare zone has unmetered DDoS protection by default — no separate SKU, no contract upgrade. Origin IPs went private behind Tunnel and Authenticated Origin Pulls so attackers couldn't bypass. The outcome:The next attack — a 500 Gbps SYN flood three weeks later — never made it past Cloudflare's edge. They didn't get paged. They learned about it from the dashboard the next morning. The CFO did the math: AWS Shield Advanced would've been $36K/year, Cloudflare Enterprise contract included it.
Objection: "Is Pro enough?""For volumetric attacks, usually yes. Enterprise matters when the attack is sophisticated or when you need a human on the phone."
Objection: "We have on-prem mitigation""On-prem has fixed capacity. If the attack exceeds your pipe, you're offline anyway. Our network absorbs attacks that overwhelm any on-prem solution."
Objection: "What does an attack cost us?""Zero. Never charged for attack traffic. That's been policy for over a decade."
Deep Dive — DDoS Protection
How it actually works
  • Layer 3/4 (network): SYN floods, UDP floods, amplification attacks (DNS, NTP, memcached). Mitigated by Gatebot and dosd — autonomous systems that fingerprint attack packets at line rate and drop them in the kernel via eBPF/XDP.
  • Layer 7 (application): HTTP floods, slow-loris, request smuggling. Mitigated by flowtrackd and L7 DDoS managed rules that score request shapes and rates.
  • Anycast absorption: Attack traffic spreads across all 330+ PoPs simultaneously. A 3 Tbps attack becomes 10 Gbps per city — trivial to absorb.
  • Adaptive DDoS (Enterprise): Learns your traffic baseline per zone — request rate, geo distribution, ASN mix, URI patterns. Detects deviations even when individual requests look legitimate.
  • Network capacity: 500+ Tbps total network capacity (largest publicly disclosed). Largest mitigated attack to date: 31.4 Tbps.
  • DDoS Botnet Threat Feed (ENT): Real-time feed of attacking botnet IPs across our network — you can preemptively block IPs that hit other customers in your industry.
Anticipated customer questions
"What's the largest attack you've stopped?"31.4 Tbps. We routinely mitigate multi-million RPS L7 floods. Public Radar dashboard shows live trends.
"How fast does mitigation kick in?"L3/4 detection and mitigation typically under 3 seconds. For repeat attacks on the same target, sub-second.
"Will you ever drop legitimate traffic?"During heavy attacks, edge cases happen. Adaptive DDoS reduces false positives by learning your baseline. We also have an "alert-only" mode to validate rules before enforcing.
"What about ransom DDoS (RDoS)?"Common — extortion emails demanding crypto. We see them constantly. Don't pay. Forward the email to your account team and we'll pre-position mitigation.
"Can you protect non-HTTP services?"Yes — Spectrum (L4 TCP/UDP) for things like SSH, gaming, MQTT. Magic Transit for entire IP ranges (network-level DDoS scrubbing).
"What's your SLA for mitigation?"Enterprise: 100% uptime SLA. We don't SLA "attack-free" but we do SLA availability. Credits if we miss.
"Who do we call during an attack?"Enterprise: dedicated SOC line, 24/7. Pro/Biz: support ticket. The SOC engagement during a live attack is one of the biggest differentiators.
"How is this different from AWS Shield?"Shield Standard is included for AWS services. Shield Advanced is ~$3k/month per protected account + bandwidth charges during attacks. Cloudflare is unmetered — no surge billing when attacked.
"What about origin protection?"Use Authenticated Origin Pulls (mTLS between CF and origin) plus IP allowlisting (only accept traffic from CF IPs) — attackers can't bypass us by hitting origin directly.
"Do you do post-incident reports?"Enterprise: yes, detailed reports with attack vector, peak rates, top source ASNs, mitigation timeline. Good for board/insurance discussions.
"What about DNS attacks?"Our authoritative DNS is DDoS-protected by default — same network. We've absorbed multi-million QPS DNS floods.
Industry angles
Fintech
Targeted L7 attacks during market hours; ransom DDoS common. Adaptive DDoS critical — attackers use slow, low-volume attacks to evade thresholds.
Gaming
Spectrum protects game servers (TCP/UDP). Competitive attacks during tournaments. Sub-second mitigation matters — players notice 5s of packet loss.
Ecommerce
Attacks during peak shopping (BFCM, holidays). Combine DDoS with bot management — DDoS handles volume, bots handle scalping/inventory abuse.
Media/News
Politically motivated attacks. Adaptive DDoS detects narrative-driven traffic spikes that look like real interest but follow bot patterns.
Healthcare
Ransomware groups increasingly pair DDoS with extortion. Uptime is patient-safety critical — SLA matters here more than anywhere.
SaaS
Customer-targeted attacks (your customer is attacked, your platform suffers). Per-zone Adaptive DDoS isolates blast radius.
Pricing notes: DDoS mitigation itself is unmetered on every plan — including Free. Enterprise pricing includes Adaptive DDoS, SOC access, SLA, and Botnet Threat Feed. Magic Transit and Spectrum are separate Enterprise products for non-HTTP / network-level protection (usage-based).
Gotcha: If your origin IP is exposed (DNS history, SSL cert SANs, email headers), attackers can bypass Cloudflare. Always rotate origin IPs when onboarding and lock down origin firewall to CF IP ranges.
Gotcha: Pro/Business plans don't get the SOC line or post-incident reports. If they have compliance/board reporting requirements during attacks, that's an ENT trigger.
Gotcha: Free/Pro DDoS is "best-effort with automatic mitigation." It's effective for the vast majority of attacks but there's no SLA — discuss this honestly.
Where to find it in the dashboard
Zone Security → DDoS
For HTTP DDoS rules and analytics on a per-domain basis.
  • DDoS Overview — real-time and historical attack analytics, top attack vectors.
  • HTTP DDoS Attack Protection — managed rulesets with sensitivity controls (Low / Default / High). Per-rule overrides on ENT.
  • Adaptive DDoS Protection (ENT) — baseline-aware mitigation. Configure per-zone learning.

Security Center → DDoS
Account-wide DDoS analytics and the Botnet Threat Feed (ENT).
  • Security Analytics — cross-zone attack trends, top attackers, attack timelines.
  • L3/4 DDoS (Magic Transit / Spectrum) — network-level mitigation rules for non-HTTP traffic.

WAF (Web Application Firewall)

What
Blocks malicious requests — SQLi, XSS, RCE, OWASP Top 10.
How
Managed rules (CF-maintained) + custom rules (your logic).
Say"Think of the WAF — that stands for Web Application Firewall — as a bouncer at the front door of your website. Every request that comes in gets checked before it ever reaches your server. We're looking for the obvious bad stuff like somebody trying to hack into your database, inject malicious code, or exploit a known vulnerability. The reason this matters is most attacks aren't somebody specifically targeting you — they're automated programs scanning every website on the internet looking for weaknesses. We see attack patterns across about 20% of the web, so when a new vulnerability gets discovered, we usually have protection deployed for everyone within hours. That way your engineering team isn't scrambling to patch things at 2am every time a new exploit comes out — we handle it at the door."
Customer Scenario The setup:A mid-sized e-commerce company runs their site on AWS with a self-managed WAF appliance handling about 5 million requests a day. The security team is two people. The pain:The WAF rules were six months stale because nobody had time to tune them. When the Log4j vulnerability hit, the team spent a weekend writing custom rules. When the next zero-day hit, the team didn't catch it for three days. They were drowning in false positives that blocked real customers, and the WAF appliance kept hitting CPU limits during traffic spikes. What they built:They moved the WAF to Cloudflare's managed ruleset. Cloudflare's threat intel team writes and updates the rules — when a new CVE hits, mitigation is usually deployed across the whole customer base within hours. Custom rules cover the company-specific patterns (their internal API paths, their admin routes). The appliance got retired. The outcome:They were protected against the next two major zero-days before either security engineer had even read the news. False positive rate dropped because Cloudflare's ML-based scoring is more accurate than their static rules. The security team got their weekends back.
Objection: "We already have a WAF""Most WAFs need constant tuning, generate false positives, or miss attacks. Ours is maintained by our threat intel team and updated globally — and runs at the edge."
Objection: "We're too small to need one""Most attacks aren't targeted — they're automated scans. Size doesn't matter to bots. WAF is cheap insurance."
Deep Dive — WAF
How it actually works
  • Cloudflare Managed Ruleset: CVE-driven rules maintained by our threat intel team. Updated continuously — often within hours of a zero-day disclosure (Log4Shell, Spring4Shell, MOVEit).
  • OWASP Core Ruleset: Industry-standard ModSecurity rules with paranoia level tuning.
  • Custom Rules: Wirefilter expression language — match on any request attribute (URI, headers, body, geo, IP, ASN, JA3 fingerprint). Action: block, challenge, JS challenge, managed challenge, log, skip.
  • Exposed Credentials Check (ENT): Detects when login attempts use credentials known to be in breach corpora — real-time check against haveibeenpwned-style data without leaking the password.
  • Sensitive Data Detection (ENT): Scans response bodies for PII, credit cards, secrets — alerts if your app is leaking data.
  • Leaked Credentials, Account Takeover, Firewall for AI: Newer ENT capabilities — detect ATO patterns, classify AI bot traffic separately.
Anticipated customer questions
"How fast do you respond to zero-days?"Emergency rules typically deployed network-wide within hours. Log4Shell rule was live in <24 hours of public disclosure.
"Do you tune rules for false positives?"Each managed rule has individual sensitivity. You can override per-rule per-zone. Start with "log only" mode, see what would fire, then enforce.
"Can we write rules in code?"Yes — Terraform provider, full API. Custom rules can also be implemented as Workers for unlimited flexibility.
"Does the WAF inspect request bodies?"Yes up to a configurable limit (default 128KB, ENT can raise). Larger bodies are skipped to preserve performance.
"What about encrypted traffic?"TLS terminates at Cloudflare — we see plaintext, inspect, then re-encrypt to origin. Standard model for any cloud WAF.
"How does this compare to AWS WAF?"AWS WAF is per-rule pricing + per-request pricing — gets expensive fast. We're flat per-zone. Our managed rules are typically rated higher in Gartner / third-party benchmarks. AWS WAF lacks the threat intel scale.
"What about Imperva/F5?"Imperva and F5 BIG-IP are mature on-prem-style WAFs. We're cloud-native, edge-deployed, no hardware. Faster deployment, lower TCO, better DDoS integration. They tend to have more complex rule editors — power vs. simplicity tradeoff.
"Can we bypass WAF for specific traffic?"Yes — skip rules, custom rule with "skip" action, or rule expressions that exempt specific paths/IPs.
"What about PCI compliance?"Business plan and above are PCI compliant. WAF helps satisfy PCI DSS 6.6 (application-layer firewall requirement).
"How do we test WAF effectiveness?"We support pen-test windows. Most CVE rules can be validated with sample exploit traffic. Bug bounty programs are also a strong indicator.
"Do you protect GraphQL?"Yes — schema-aware GraphQL protection (ENT, via API Shield). Detects introspection abuse, query depth attacks, batching abuse.
Industry angles
Fintech
PCI DSS compliance, exposed credentials check critical for login endpoints, custom rules for transaction velocity.
Ecommerce
Block scrapers via custom rules + bot integration. Sensitive data detection catches accidental PII leaks in cart/order APIs.
SaaS
Multi-tenant: custom rules per customer subdomain. Schema validation via API Shield for tenant API endpoints.
Healthcare
HIPAA scope — WAF blocks injection that would access PHI. Sensitive data detection alerts if app accidentally leaks records in error responses.
Gaming
Custom rules block known cheat/scrape tools by JA3 fingerprint and user agent patterns.
Media
Block scraping of paywalled content, login abuse for shared accounts.
Pricing notes: WAF Managed Rules included on Pro+. Custom Rules: 5 on Pro, 20 on Business, unlimited on Enterprise. Advanced features (Exposed Creds, Sensitive Data Detection, Leaked Credentials Check, Account Takeover) are Enterprise add-ons or part of bundled security packages.
Gotcha: Pro WAF is significantly less flexible than Enterprise. Pro = managed rules only with basic overrides. ENT = full custom ruleset, advanced rate limiting, payload inspection limits.
Gotcha: WAF doesn't inspect WebSocket payloads after upgrade. Use Workers + custom logic for WS-specific protection.
Gotcha: If origin requires specific headers/IPs, configure those before enforcing WAF — managed rules sometimes flag uncommon legitimate traffic.
Where to find it in the dashboard
Zone Security → WAF
All WAF configuration lives under your selected domain's Security menu.
  • Custom rules — your hand-written rules. Wirefilter expressions, all actions (block, challenge, log, skip).
  • Rate limiting rules — request rate caps. Pro+ basic, ENT advanced.
  • Managed rules — Cloudflare Managed Ruleset and OWASP Core Ruleset. Per-rule overrides.
  • Tools — IP Access Rules, User Agent Blocking, Lockdown (allowlist by URL).
  • Page Shield (sometimes appears here) — JavaScript supply chain monitoring.

Security Center → Security Analytics
Cross-zone analytics — see WAF firing patterns across all your domains in one view.

Page Shield (Client-side Security)

What
Detects and prevents attacks against the browser-side of your web application — Magecart-style skimmers, malicious third-party scripts, supply-chain JavaScript attacks, and client-side data exfiltration.
Why
Modern websites load 30-100+ third-party scripts (analytics, chat widgets, A/B test tools, payment forms, tag managers). Each one is a potential attack vector. PCI DSS 4.0 mandates client-side script inventory and integrity monitoring as of March 2025. Page Shield gives you visibility, alerting, and policy enforcement for everything running in your customers' browsers.
Say"Page Shield is the client-side security product. It solves a problem most people don't think about — your website loads dozens of third-party scripts. Google Analytics, Stripe, Intercom, Hotjar, Optimizely, your tag manager, sometimes ad pixels, social widgets, customer support chat. Each one is JavaScript executing in your customers' browsers. If any of them get compromised — or someone slips a malicious tag into your tag manager — attackers can steal credit cards, harvest credentials, or inject content. The Magecart attacks that hit British Airways, Ticketmaster, Newegg — that's exactly this pattern. Page Shield connects to your zone's traffic, builds an inventory of every script and connection your site makes, monitors for changes, alerts you when something new shows up or behaves suspiciously. PCI 4.0 — which went mandatory in March 2025 — requires every merchant accepting cards in the browser to inventory and monitor client-side scripts. Page Shield is what makes that compliance achievable without manual work."
Customer Scenario The setup:A specialty e-commerce retailer (~$200M GMV, payments accepted in-browser). Their PCI auditor told them they need to comply with PCI DSS 4.0 client-side script requirements by their next assessment. The pain:Marketing had been adding tags through Google Tag Manager for years with no inventory. Nobody could answer "what scripts run on our checkout page?" or "what does each one do?" Their compliance team estimated 200+ engineering hours to manually inventory and monitor. The auditor said "miss this and you fail your assessment." What they built:Turned on Page Shield. Within 24 hours it had inventoried every script and connection across the site. Set up policies to alert on any new script or connection appearing on checkout. Used the compliance report directly in their PCI audit submission. The outcome:PCI 4.0 client-side requirement passed. Compliance team saved the 200 hours. Two months later Page Shield caught a third-party analytics tool injecting a new tracking pixel without notice — alert, investigation, removal, all before any data was exfiltrated.
Objection: "We have a WAF. Isn't that enough?""WAF protects requests going TO your server — SQL injection, XSS in form data, that kind of attack. Page Shield protects what runs IN the browser AFTER the page loads. Completely different threat model. Magecart skimmers don't touch your server — they inject into the third-party tag manager and run in customer browsers. Your WAF never sees them."
Objection: "We trust our third-party vendors""You don't have to mistrust them — you just have to acknowledge that they can be compromised. The 2018 British Airways breach hit through a compromised third-party script. The 2019 Macy's Magecart attack. Newegg, Ticketmaster, Forbes — all third-party supply-chain attacks. Page Shield is for when one of your trusted vendors gets popped without their knowledge. Detection in days instead of months."
Deep Dive — Page Shield
How it actually works
  • Reporting endpoint: Cloudflare injects a Content Security Policy (CSP) report directive on outbound HTML. Browsers report every script load + connection to Cloudflare.
  • Script inventory: Builds a continuous list of every JavaScript file loaded on your site, with source URL, hash, last seen, page paths affected.
  • Connection inventory: Tracks every domain the browser connects to (fetch, XHR, beacon, WebSocket). Surfaces unexpected exfiltration destinations.
  • Change detection: Alerts when a script's hash changes (new code deployed), when a new script appears, or when a new connection destination shows up.
  • Magecart-pattern detection: ML model trained on known skimmer patterns flags scripts behaving like card-data harvesters.
  • Malicious connection detection: Cross-references connection destinations against threat intel — flags scripts connecting to known C2 / exfiltration domains.
  • Policy enforcement (Business+): Write rules to actively block specific scripts, prevent unknown scripts from loading, or restrict connection destinations via auto-generated CSP.
  • PCI DSS 4.0 reporting: Page Shield reports map directly to PCI 4.0 requirements 6.4.3 (inventory + change detection) and 11.6.1 (tamper detection on payment pages).
Tier breakdown
  • Free: Limited script inventory visibility. No alerting. No policy enforcement. Read-only awareness.
  • Pro: Full script inventory, change alerts, basic malicious script detection.
  • Business: + connection inventory, + alerting on new connection destinations, + script integrity monitoring, + PCI 4.0 reports.
  • Enterprise: + active policy enforcement (block scripts/connections), + custom rules, + malicious resource detection with ML, + positive blocking (allowlist-only mode), + integration with custom alerting / SIEM.
Anticipated customer questions
"What's PCI DSS 4.0 saying exactly?"Two relevant requirements. 6.4.3 — every script on payment pages must be inventoried with justification and integrity verified. 11.6.1 — tamper-detection mechanism must alert on changes to payment-page headers and contents. Page Shield satisfies both. Mandatory for level 1 merchants since March 31, 2025.
"How does it find Magecart-style skimmers?"Combination of: (1) ML model trained on known skimmer behavior patterns, (2) connection destination intelligence (skimmers exfiltrate to attacker domains — those domains are in our threat feed), (3) integrity monitoring (when a known-good script's hash changes unexpectedly).
"Does it block in real-time, or just alert?"Business and below: detect and alert. Enterprise: detect, alert, AND enforce via CSP policies. Page Shield can auto-generate CSP headers to block disallowed scripts at the browser level.
"What about false positives?"Real issue — every new release of every third-party tool creates a hash change. Tuning patterns: ignore specific domains (cdn.googletagmanager.com), allowlist known vendors, set custom thresholds. Most teams refine alerts for a few weeks then stabilize.
"How does it affect page load performance?"Cloudflare injects a small CSP report directive. Browsers send reports asynchronously after page load — no impact on load time or user experience. Bandwidth overhead negligible.
"Does it require proxying our traffic through Cloudflare?"Yes — Page Shield observes HTML responses going to browsers, which only happens if your zone is proxied through Cloudflare. Won't work for DNS-only zones.
"What about SPA / single-page apps that load scripts dynamically?"Supported. Page Shield observes browser CSP reports from all script loads, including those triggered by JS after initial page render. SPAs work fine.
"Can we export findings to SIEM?"Yes on Enterprise — Logpush integration for Page Shield events. Splunk, Datadog, custom SIEMs, S3.
"vs Akamai Page Integrity Manager / Imperva Client-side Protection?"Akamai PIM and Imperva are mature client-side products with similar feature sets. Cloudflare Page Shield is competitive on detection, simpler tier model (PCI-relevant features in Business), tighter integration with the rest of Cloudflare. Trade-off: Akamai/Imperva have longer specific track record in client-side; Cloudflare is catching up rapidly.
Industry angles
Ecommerce
Mandatory for PCI 4.0 compliance if accepting card payments in browser. Magecart prevention is the #1 use case.
Fintech
Any browser-based payment or banking flow. Tamper detection on payment pages. Cross-references with anti-fraud teams.
SaaS
Multi-tenant platforms where customers add their own third-party integrations. Visibility into what their tenants are running.
Healthcare
HIPAA — patient portals that load third-party analytics, support widgets. Detect if any are exfiltrating PHI.
Government / Public sector
Compliance with USDS / GSA guidance on client-side script integrity for citizen-facing portals.
Pricing: Tiered by Cloudflare plan. Free: limited visibility. Pro: $20/mo bundle. Business: $200/mo bundle (PCI 4.0 features). Enterprise: custom (active enforcement, ML detection, positive blocking).
Gotcha: Free and Pro tiers don't satisfy PCI 4.0 requirements — customer needs Business minimum for compliance reporting.
Gotcha: Requires proxied traffic. DNS-only zones (grey-cloud records) don't get Page Shield observability.
Gotcha: Initial inventory phase produces alert volume — most legitimate third-party tools update frequently. Plan for tuning during rollout.
Gotcha: Policy enforcement (CSP blocking) on Enterprise can break sites if rolled out without staging. Always test in report-only mode first.
Gotcha: Doesn't replace endpoint security — Page Shield observes what browsers report. A truly malicious script that disables CSP reporting would be invisible (rare in practice).
Where to find it in the dashboard
Per-zone [Domain] → Security → Page Shield
  • Overview — scripts loaded, connections made, recent alerts.
  • Scripts — full inventory: URL, host, status (active / inactive / malicious), last seen, hash, pages where loaded.
  • Connections — outbound destinations from browser: domain, status, classification.
  • Policies (Business+) — auto-generated CSP, allowlists, custom enforcement rules.
  • Alerts — notification settings (email, webhook, Logpush).
  • PCI 4.0 Reports (Business+) — pre-formatted compliance reports for auditors.

Bot Management Enterprise

What
ML score 1–99 on every request. JA3/JA4 fingerprinting. Bot family detection.
Pro version
Super Bot Fight Mode — catches simple bots. Site-wide, binary.
Stops
Credential stuffing, scraping, fake signups, inventory hoarding, carding, API abuse.
Say"So here's something most people don't realize — about half the traffic on the internet isn't even real people, it's bots. Some bots are good, like Google's search bot crawling your site so you show up in search results. But most aren't — they're trying to break into accounts, steal pricing data, create fake signups, or buy up your inventory to resell. What Bot Management does is look at every visitor and give them a score from 1 to 99 — 1 means definitely a bot, 99 means definitely a real person. Then you decide what to do with that score. For example, you might say 'anybody under a 30 on my login page gets blocked' but allow them on your homepage. We also recognize specific bot tools — like that's a scraper, that's somebody using a fake browser, that's an AI training bot. The business impact is real money — stopping account takeover, protecting your pricing from competitors, keeping fake users out of your analytics, and making sure real customers can actually buy products when they go on sale."
Customer Scenario The setup:An online travel agency competing with the big OTAs. Their pricing API gets scraped constantly by competitors and price comparison sites — they have evidence competitors are undercutting them by a few dollars within minutes of their prices changing. The pain:They were also seeing credential stuffing on their login page (~50K bad attempts a day) and fake account signups eating up their welcome-bonus budget. Their security team had built basic rate limits but bots rotated IPs and evaded them. Real customers were getting blocked sometimes; bots were getting through. What they built:Bot Management running across the whole zone with different rules per surface: login page blocks under bot score 30, signup blocks under 20 and requires Turnstile, search/results pages just label and log (since search needs to be open), pricing API blocks specific known scraper detection IDs. Pairs with Advanced Rate Limiting using JA3 fingerprint as the count key, so IP-rotating bots get caught. The outcome:Credential stuffing dropped to near-zero. Fake signups dropped about 80%, saving meaningful welcome-bonus spend. Competitor scraping became unreliable enough that their prices stopped getting matched within minutes. Real customer block rate dropped because the ML scoring was more accurate than the old static rules.
Common scenariosCredential stuffing • content scraping • fake signups • inventory hoarding • carding • API abuse
Objection: "We don't have a bot problem""Most customers don't know until they look. If you have a login, pricing page, or API, bots are hitting it. The question is whether you can tell them apart from real users."
Objection: "Can't the WAF handle this?""WAF inspects request content — is it malicious? Bot Management inspects behavior — is it automated? Complementary, not overlapping."
Objection: "Pro's bot protection is enough""Pro catches scripts with default user agents and headless browsers. It won't catch bots that mimic real browsers, rotate fingerprints, or use residential proxies. If you have anything valuable behind auth, Pro isn't sufficient."
Pairs strongly with Advanced Rate LimitingBot Management identifies the bots. Advanced Rate Limiting (ARL) lets you act on them with surgical precision. With ARL on the contract, you can write rate limiting rules that reference Bot Management fields directly — bot score, bot detection IDs, verified bot status, JA3/JA4 fingerprint. So instead of just "block under score 30," you can say "throttle scrapers to 10 requests per minute, block credential stuffers entirely, allow Googlebot unrestricted, and apply a separate budget to AI crawlers." That's something most competitors can't do because their rate limiting can't reference bot signals as a counting characteristic. Common ARL + Bot Management patterns: rate limit by JA3 fingerprint to catch IP-rotating bots that keep the same TLS client; rate limit by bot score bucket so suspicious traffic gets a stricter limit than human traffic; rate limit AI crawlers by detection ID separately from other bot families.
Deep Dive — Bot Management
How it actually works
  • Bot score (1–99): ML model trained on tens of trillions of requests/month across Cloudflare's network. 1 = definitely bot, 99 = definitely human. Available on every request as cf.bot_management.score.
  • Detection signals: Multi-layer — heuristics (impossible browser combos), JA3/JA4 TLS fingerprints, HTTP/2 fingerprinting, machine learning classifier, behavioral analysis (mouse, keyboard, timing), anomaly detection.
  • Verified Bots: Curated allowlist — Googlebot, Bingbot, AhrefsBot, monitoring services. Validated via reverse DNS + ASN.
  • JA3/JA4 fingerprinting: TLS handshake produces a deterministic fingerprint per client library. Curl, Python requests, headless Chrome each have characteristic fingerprints — attackers can spoof user agents but TLS handshakes are harder to forge.
  • Bot detection IDs / families: We identify specific bot families — "PerimeterX bypass tool," "OpenAI GPTBot," "Bytespider," "Imperva probing," "stealthy headless Chrome," etc. Granular control: block scrapers, allow search engines.
  • Behavioral signals (Bot Mgmt for Enterprise): Optional JS snippet collects mouse movement, scroll, touch — feeds into score for nuanced detection on critical paths.
  • Anomaly Detection (Auto-Mitigation): Detects credential stuffing, content scraping, inventory hoarding patterns automatically.
  • AI Crawl Control (companion product): Specifically for AI crawlers — GPTBot, ClaudeBot, Bytespider, PerplexityBot, Amazonbot, Google-Extended, etc. Per-crawler allow/block/charge controls. Customers can monetize AI training access (charge OpenAI / Anthropic per crawl) or block them entirely. Free product, separate from Bot Management but uses the same identification signals.
Anticipated customer questions
"How accurate is the bot score?"False positive rate <0.01% at score <30 in our internal benchmarks. Trained on actual labeled bot traffic, not heuristics.
"What about AI scrapers (GPTBot, ClaudeBot, etc.)?"Identified specifically. You decide per-bot: allow, challenge, block. We also offer "AI Audit" — visibility into which AI bots are crawling you, with per-bot pricing controls.
"Can attackers fingerprint-spoof?"JA3 can be spoofed but consistently across an attack is hard. We layer many signals — score considers TLS, HTTP/2, behavior, history. Spoofing one signal isn't enough.
"What about residential proxies?"Our biggest moat — we see traffic from every residential ASN at massive scale. Residential proxy networks (Bright Data, Oxylabs, IPRoyal) are fingerprinted at TLS layer. Score detects them even when IP looks clean.
"How do we deploy without breaking real users?"Always start in "log only" mode. Review which requests would be challenged/blocked. Tune score thresholds. Then enforce. Typical pilot is 2–4 weeks.
"What does a challenge look like?"Managed Challenge (recommended) — invisible to humans most of the time, hard challenges (interactive) reserved for high-suspicion. No reCAPTCHA-style image puzzles by default.
"How does this compare to PerimeterX (HUMAN), DataDome, Kasada?"Comparable detection. Our differentiator is integration — same platform as WAF, DDoS, CDN. No latency penalty for additional inspection. Pricing usually more competitive at scale.
"What about Akamai Bot Manager?"Strong product. Pricing is significantly higher. We're typically faster to deploy (hours vs weeks) and the bot score is exposed in rules/Workers for flexible policy.
"Can we whitelist specific bots?"Yes — Verified Bots list is configurable per category. Allow Googlebot, block scrapers. Or custom rule: "if bot category = monitoring, skip block."
"What about mobile apps?"Mobile SDK available for stronger device-level signals. Without SDK, we use TLS + HTTP fingerprinting which catches most automated mobile abuse.
"Do you protect against scalping?"Yes — Sneakers, ticketing, limited drops are major use cases. Combine bot score with rate limiting and Waiting Room.
"What about credential stuffing?"Bot score catches the automation; pair with Exposed Credentials Check (WAF) and rate limiting for defense-in-depth.
"How is this different from Super Bot Fight Mode?"SBFM is a simplified version — three categories (definitely automated, likely automated, verified), no granular score. Pro/Biz only. No JA3 visibility, no analytics dashboard, no custom rule integration with score.
Industry angles
Fintech
Credential stuffing on login (90%+ of "login attempts" are bots), account takeover, synthetic identity creation. Score on /login is non-negotiable.
Ecommerce
Inventory hoarding, scraping (pricing, product data), carding (testing stolen cards on checkout), fake reviews. Bot Mgmt + RL + Sensitive Data Detection.
SaaS
Fake signups poisoning analytics, API abuse from free-tier scrapers, competitor scraping documentation/pricing.
Media
Content scraping (paywall bypass, AI training data theft), credential sharing detection, ad fraud (fake traffic for revenue manipulation).
Gaming
Account creation farms, gold/currency farming bots, cheat downloads. JA3 fingerprinting catches common cheat tool libraries.
Ticketing/Travel
Scalping. Major problem. Combine bot score with Waiting Room and per-session rate limiting.
Healthcare
Appointment scraping (telehealth slots), credential stuffing on patient portals.
Pricing notes: Bot Management is Enterprise only — typically priced as a separate line item based on request volume. Super Bot Fight Mode (lite version) is included with Pro and Business. Mobile SDK is part of Bot Management ENT. Bot Analytics dashboard included with ENT product.
Gotcha: Bot Management requires Enterprise plan. If a customer needs "Pro + Bot Management" — that's not a SKU. They upgrade to ENT.
Gotcha: Don't enforce blocking before piloting. Always 2–4 weeks of log-only mode to tune thresholds — every customer's traffic is different.
Gotcha: Mobile app traffic without SDK has weaker signals. Recommend SDK integration for high-value mobile flows.
Gotcha: Some "good" bots (uptime monitors, internal scrapers) score low. Add to Verified Bots / custom allowlist or whitelist by JA3.
Where to find it in the dashboard
Zone Security → Bots
Per-domain bot management — visible only if Bot Management or SBFM is enabled on the zone.
  • Configure Super Bot Fight Mode (Pro/Biz) — toggle on, choose JavaScript Detections, define actions for definitely automated / likely automated / verified bots.
  • Bot Analytics (ENT) — full bot score histogram, top bot families, top requesting ASNs, JA3 breakdowns, time-series charts.
  • Bot configuration (ENT) — enable Auto-Mitigation, configure Anomaly Detection (credential stuffing, scraping, hoarding), behavioral signals SDK.

Zone Security → WAF → Custom rules
Use the bot score in your WAF rules — e.g. cf.bot_management.score lt 30.

Analytics → Account Bot Analytics
Cross-zone bot visibility for multi-domain accounts (ENT).

Turnstile Free

What
Cloudflare's CAPTCHA replacement. Verifies humans without making them click traffic lights or fire hydrants.
Why
CAPTCHAs are bad for everyone — frustrating for real users, easy for modern bots (cheap CAPTCHA-solving services exist). Turnstile invisibly fingerprints the browser environment and only challenges when something looks off.
Say"Turnstile is what replaces reCAPTCHA on your forms. Instead of asking users to click pictures of crosswalks, it runs invisible JavaScript challenges in the background — browser fingerprinting, proof of work, behavioral signals — to tell humans from bots. Most users never see anything. The ones who fail get a simple managed challenge. It's free, unlimited use, and doesn't sell user data to ad networks like Google's reCAPTCHA does. We've had customers replace reCAPTCHA in an afternoon — same JavaScript widget pattern, same backend verification API, just point at us instead. And because we run on Cloudflare's network, latency is way better than reCAPTCHA's Google-hosted endpoints."
Customer Scenario The setup:A B2B SaaS company has a free-trial signup form using reCAPTCHA v2 ("click all the crosswalks"). Their EU expansion brought GDPR scrutiny. The pain:The legal team had been flagging reCAPTCHA for two quarters — it sends data to Google for ad targeting, which their EU customers' DPAs explicitly forbid. Plus their analytics showed a 28% drop-off on the signup form, traced back to reCAPTCHA puzzles that wouldn't validate. What they built:An engineer swapped reCAPTCHA for Turnstile in an afternoon — same widget pattern, same server-side verify call, just a different endpoint and site key. Marketing didn't even know it changed. The outcome:GDPR concern resolved — no third-party tracking. Signup form drop-off dropped from 28% to about 6% because most users now see no challenge at all. Bot signups dropped a similar amount. Free, so no procurement involved.
Objection: "We're using reCAPTCHA — why switch?""Three reasons. One, privacy — reCAPTCHA sends user data to Google for advertising. Turnstile doesn't, which matters for GDPR and CCPA. Two, user experience — Turnstile is invisible to most users. reCAPTCHA v3 is too, but v2 challenges have a 32% abandonment rate. Three, it's free with no usage limits."
Objection: "Will it actually catch bots?""Yes — and the security model is honest. Turnstile uses browser fingerprinting and behavioral signals; sophisticated attackers can bypass it just like they bypass reCAPTCHA. For login forms and high-value endpoints, layer Turnstile on top of Bot Management (score-based ML) and Rate Limiting. Turnstile is the first filter, not the only one."
Deep Dive — Turnstile
How it actually works
  • Widget on the page: Add a small JS snippet to any form. Turnstile runs background challenges (proof-of-work, browser fingerprinting, behavioral analysis) before form submission.
  • Token issued: If Turnstile thinks the visitor is legitimate, it issues a one-time token attached to the form submission.
  • Server-side verification: Your backend calls the Turnstile siteverify API with the token and your secret key. API returns success/failure with metadata (hostname, action, cdata).
  • Widget modes: Managed (default, lets Turnstile decide), Non-interactive (always invisible challenge), Invisible (no widget UI), Pre-Clearance (full-page check before showing content).
  • Pre-Clearance: A more aggressive mode where the entire page is gated by a Turnstile challenge before render. Used on sites with bot-heavy traffic where you want to filter at the front door.
  • Action and cData: Optional metadata fields. Action lets you scope tokens to specific form submissions (login vs signup vs comment). cData is custom data round-tripped through the verification.
  • Implicit and explicit rendering: Implicit auto-renders with a div class. Explicit gives JS control over when/where to render.
  • What Turnstile actually collects (per Cloudflare's Turnstile Privacy Addendum): client IP address, TLS fingerprint, User-Agent header, sitekey and associated origin (the page URL where the widget is embedded). That's the list. Cloudflare explicitly states it "does not have the ability to directly identify any individuals from any of the Signals Turnstile collects, including IP addresses." No third-party cookies. SOC 2 compliant. GDPR-compliant.
  • What Turnstile does NOT collect: The values in your form fields. Name, date of birth, phone number, email, SSN, addresses, payment info — none of it. The widget runs in an isolated iframe served from challenges.cloudflare.com and has no access to the parent page's form data. This matters for HIPAA, PCI, and any other regulated form.
Anticipated customer questions
"Is Turnstile actually free?"Yes — unlimited use, no per-request pricing, no plan tier required. Free even for non-Cloudflare customers (you don't need to proxy your site through Cloudflare to use Turnstile).
"Does it work without Cloudflare proxying our site?"Yes — Turnstile is entirely client-side widget + server-side verify API. No requirement to be on Cloudflare. Hosted on cloudflarequickreference.pages.dev? Doesn't matter, Turnstile still works.
"How do I migrate from reCAPTCHA?"Drop-in replacement pattern. Swap the script tag and div class. Swap the server-side verify URL and your secret. Both APIs return JSON with success boolean. Most teams migrate in an hour.
"What about accessibility?"Turnstile is keyboard-navigable, screen-reader-friendly, no visual puzzles required. Better baseline accessibility than reCAPTCHA v2 image challenges.
"Does Turnstile collect any of the fields on our form?"No. The widget runs in an isolated iframe served from challenges.cloudflare.com and has zero access to the parent page's form data. It cannot read names, dates of birth, phone numbers, email addresses, payment info, or anything else the user types. Per Cloudflare's Turnstile Privacy Addendum, the only Signals Turnstile collects are: client IP address, TLS fingerprint, User-Agent header, and the sitekey + page URL. That's the full list. Form fields stay on the customer's side, untouched.
"Healthcare customer asking about HIPAA and BAA — is Turnstile in scope?"Two-part answer. (1) The form data your patients enter never reaches Turnstile — it's not in the Signals list. So functionally, Turnstile isn't touching PHI. (2) HIPAA's identifier list does include IP addresses when tied to a healthcare encounter, so a strict compliance team might still want a BAA. Best response: "Form data stays with you, we never see it. Turnstile likely doesn't need to be in BAA scope, but I can confirm with our compliance team if you'd like extra coverage." Always verify with AM/compliance before formally committing on BAA scope.
"Can attackers bypass it?"Yes — any client-side challenge can theoretically be bypassed. Turnstile raises the cost of attack significantly (proof-of-work + fingerprinting + behavior) but isn't a silver bullet. Pair with Bot Management for high-value endpoints.
"What's the latency hit?"Managed mode: typically 100-500ms additional. Most users won't notice. Pre-clearance adds more (full-page gate before content render). Tune mode based on traffic sensitivity.
"Does it work in mobile apps?"Yes — Turnstile has iOS and Android SDKs. Same token-based verification flow.
"Pre-Clearance vs Managed mode — when do I use which?"Managed for typical form protection (login, signup, comment, contact). Pre-Clearance for sites under heavy scraping or where you want to gate entire content sections from bots before rendering.
"Can I customize the widget look?"Theme (light/dark/auto), size (normal/compact/invisible), language (auto-detect or specified). Logo and core layout are fixed.
Industry angles
SaaS
Signup forms, login pages, password resets, comment systems. Replace reCAPTCHA across all forms — better UX, no Google tracking.
Ecommerce
Checkout, account creation, gift card / coupon redemption. Layer with Bot Management to catch card testing.
Fintech
Account opening, KYC starts, password resets. Privacy posture matters — Turnstile not sending data to Google is a real talking point.
Healthcare
Patient portals, appointment booking. HIPAA-friendlier than reCAPTCHA (no third-party tracking).
Media / Forums
Comment systems, user-generated content submission. Pre-Clearance mode for paywalled content gates.
Pricing: Free, unlimited use. No premium tier today. No verification limits.
Gotcha: Server-side siteverify is mandatory. Client-side token alone proves nothing — attackers replay tokens. Always verify on your backend with your secret.
Gotcha: Token TTL is 300 seconds. If your form takes longer than 5 minutes to submit (unusual but possible on long forms), the token expires.
Gotcha: Tokens are single-use. Don't try to verify the same token twice — the second call returns timeout-or-duplicate.
Gotcha: Pre-Clearance is more disruptive than Managed mode — only enable it when bot pressure justifies blocking page render.
Gotcha: Customer should verify their CSP (Content Security Policy) allows challenges.cloudflare.com script + frame sources before deploying.
Where to find it in the dashboard
Turnstile
  • Sites — create a new Turnstile widget per site / domain. Pick mode (Managed / Non-Interactive / Invisible) and pre-clearance setting.
  • [Site name] → Settings — site key (public, embeds in JS), secret key (private, used for siteverify).
  • [Site name] → Analytics — challenge volume, pass/fail rate, top browsers, top countries.
  • [Site name] → Pre-Clearance — enable for full-page gating; choose challenge level.
Turnstile is a separate Cloudflare product — works without proxying your site through Cloudflare. Customer signs up for a Cloudflare account, creates a Turnstile site, gets keys, drops widget in code.

API Shield Enterprise

What
API Discovery, Schema Validation, JWT Validation, mTLS, Sequence Analytics, per-session rate limiting.
Why
Most API attacks aren't DDoS — they're subtle: malformed data, logic abuse, shadow endpoints.
Say"Quick context — an API is basically how your mobile app or your partners talk to your servers behind the scenes. They're invisible to regular users but they're actually the majority of internet traffic now, and they've quietly become the number one way companies get hacked. API Shield is built specifically to protect them. A few things it does — first, API Discovery, where we watch your traffic and tell you every API endpoint you have. Almost every customer is surprised; they think they have 15, we find 50, and the ones they didn't know about are usually the ones attackers exploit. Second, Schema Validation — you tell us what a valid request should look like, and we throw out anything malformed before it reaches your servers. Third, the really clever one — Sequence Analytics — we learn the normal order of how people use your API. So if somebody jumps straight to your 'transfer money' endpoint without ever logging in first, we catch it. Big breaches like T-Mobile and Optus happened through API abuse — this is the layer that catches the stuff that traditional security tools miss."
Customer Scenario The setup:A digital health company runs a mobile app for patients and a separate web portal. Both talk to the same backend over REST APIs. They thought they had about 60 endpoints documented. The pain:A pen-test found an undocumented internal endpoint that returned full patient records when called with a known ID — no auth check, left over from an old admin tool. The pen-testers found it in 20 minutes. Nobody on the team knew it still existed. What they built:Turned on API Discovery in log-only mode for two weeks. Cloudflare watched every request and produced an inventory — 140 endpoints, not 60. The "missing" 80 included three more zombie admin endpoints. They added Schema Validation on documented endpoints and Sequence Analytics on the patient-record flow. The outcome:The zombie endpoints were killed permanently. Schema Validation now blocks malformed requests before they hit the backend. Two months later Sequence Analytics caught a credential-stuffing attempt that skipped the login flow entirely — would've been invisible to the WAF.
Key capabilities Discovery — finds shadow APIs  •  Schema — enforces OpenAPI  •  JWT — validate at edge  •  mTLS — cert-based auth  •  Sequence — detect logic abuse
Objection: "We don't expose APIs""Most companies expose more than they think — mobile apps, partner integrations, internal tools. Discovery alone often surprises customers."
Objection: "API keys are enough""Keys identify the caller but don't validate content or detect abnormal behavior. If a key leaks, you have zero visibility. Schema + sequence analytics catch what keys can't."
Objection: "Sounds complex""Discovery is passive — just watches traffic. Schema validation starts in log-only mode. Nothing blocks until you approve it."
Deep Dive — API Shield
How it actually works
  • API Discovery: Two modes — (1) session-identifier-based (we watch session tokens/cookies/JWTs and learn endpoint patterns), (2) machine learning-based (clusters URI patterns). Surfaces shadow APIs, zombie endpoints, undocumented routes.
  • Schema Validation: Upload OpenAPI 3.0 spec. Cloudflare enforces request method, path params, query params, headers, body schema. Rejects malformed requests at the edge before they hit origin.
  • Schema Learning: If you don't have a spec, we generate one from observed traffic. Export, review, refine, enforce.
  • JWT Validation: Verify signing keys (JWKS endpoint), check expiration, validate claims. Reject invalid tokens at edge — saves origin from doing crypto on every request.
  • mTLS: Issue and manage client certificates. Enforce per-endpoint — e.g., all /admin/* requires valid client cert.
  • Sequence Analytics: Learns call patterns ("90% of users hit /login → /dashboard → /transactions in that order"). Flags deviations. Catches business logic abuse impossible to detect via static rules.
  • Sequence Mitigation: Enforce sequences — require /login before /api/transactions. Block out-of-order traffic.
  • Volumetric Abuse Detection: Per-endpoint, per-session anomaly detection. Detects "user X is calling /search 1000x more than baseline."
  • Sensitive Data Detection: Scans API responses for credit cards, SSNs, JWTs, secrets. Alerts on accidental data exposure.
  • GraphQL Protection: Query depth limits, alias batching limits, introspection control.
Anticipated customer questions
"What if we don't have an OpenAPI spec?"Schema Learning generates one from your real traffic over a few days. Export as OpenAPI, review, then enforce.
"How does Discovery work without an agent?"Cloudflare already sees every request (we're a reverse proxy). Discovery is purely analytic — we identify endpoint patterns from existing traffic.
"What about gRPC?"Supported. gRPC over HTTP/2, with protobuf-aware features in development. Most API Shield capabilities work for gRPC.
"How is this different from Salt Security or Noname?"Those are dedicated API security platforms — often deeper analytics but they sit alongside your CDN/WAF. We're integrated — one platform, one policy plane, less latency. Pricing is typically much lower at scale.
"What about AWS API Gateway?"API Gateway is an API management product (auth, throttling, billing). API Shield is API security — different problem. Customers often run both.
"Can we use this for internal APIs?"Yes — pair with Cloudflare Tunnel or Access for internal-only APIs. Schema validation + mTLS works great for service-to-service.
"What happens during schema validation failure?"Configurable: log only, challenge, or block. Most customers start with log-only and review for a sprint before enforcing.
"How do you handle versioning?"Multiple schemas per zone — /v1/* vs /v2/* can have different OpenAPI specs enforced.
"What about JWT key rotation?"We fetch from your JWKS endpoint with configurable refresh interval. Standard JWT spec behavior.
"Does Sequence Analytics need ML training?"Yes — learns from a few days of traffic. You see results in a dashboard. Mitigation is opt-in per-sequence.
"What's the OWASP API Top 10 coverage?"Direct coverage of API1 (BOLA — sequence analytics), API2 (broken auth — JWT validation), API3 (excessive data exposure — sensitive data detection), API4 (lack of resource limiting — volumetric abuse), API8 (injection — WAF + schema), API9 (improper inventory — Discovery).
"Can we export findings?"Yes — Logpush to S3/GCS/Splunk/Datadog. SIEM-friendly JSON. All schema violations, JWT failures, sequence anomalies streamed in real time.
Industry angles
Fintech
Most critical use case. mTLS for partner APIs, JWT validation at edge, sequence analytics for transaction flows (detect unusual order of operations), sensitive data detection for PCI/PII leakage.
Healthcare
HL7 FHIR APIs — schema validation prevents malformed PHI requests. mTLS for B2B integrations. Sensitive data detection critical for HIPAA.
SaaS
Public APIs are the product. Discovery surfaces shadow endpoints; schema validation prevents enumeration attacks; volumetric abuse stops free-tier scrapers.
Ecommerce
Mobile app APIs, partner integrations. Sequence analytics catches checkout flow abuse (price tampering, coupon stacking).
Gaming
Player APIs, leaderboards, in-app purchases. Schema validation blocks cheat-tool malformed requests; sequence analytics catches impossible play patterns.
Media
Content APIs, paywalled feeds. Volumetric abuse detection catches scraping for AI training data.
Pricing notes: Enterprise only. Typically bundled in Advanced API security package — pricing scales with API request volume and feature mix (Discovery alone is often included; Schema, JWT, mTLS, Sequence are part of the advanced tier). Sensitive Data Detection is sometimes a separate line.
Gotcha: Schema validation requires accurate OpenAPI spec. If your real API drifts from the spec, you'll block real traffic. Always log-only first.
Gotcha: Sequence Analytics needs session continuity — works best with consistent session identifiers (cookie, JWT, header). Stateless API patterns are harder.
Gotcha: mTLS adoption requires customer cert distribution. Plan onboarding flow before enforcing.
Gotcha: JWT validation requires public JWKS endpoint reachable from Cloudflare. Locked-down auth services may need allowlisting.
Where to find it in the dashboard
Zone Security → API Shield
All API Shield capabilities live under your selected domain's Security menu (ENT only).
  • Discovery — endpoints Cloudflare has discovered. Filter by host, method, traffic, score, "session ID source" required.
  • Endpoint Management — list of saved endpoints. Promote discovered endpoints, add manually, label with operation IDs.
  • Schema validation — upload OpenAPI 3.0 specs, configure enforcement action (log / block) per schema.
  • JWT Validation Configurations — define token validation configs (issuer, JWKS URL, claims).
  • mTLS — manage client certificate auth at the edge.
  • Sequence Analytics — view discovered API call sequences. Sequence Mitigation rules under custom rules.
  • Sensitive Data Detection — configure detection profiles (PII, PCI, credentials).
  • Settings — session identifier sources (cookies / headers / JWT claims).

Rate Limiting

What
Caps how many requests a source can make in a time window. Capability scales sharply with plan tier — and Advanced Rate Limiting (ARL) is a separate ENT entitlement, not automatic with ENT.
Free
1 rule. Path + Verified Bot only. Per-IP. 10s window. 10s mitigation. Effectively a teaser.
Pro
2 rules. Host, URI, Path, Query, Verified Bot. Per-IP. Up to 1-minute window, 1-hour mitigation.
Business
5 rules. Adds Method, Source IP, User Agent. IP with NAT support. Cache exclusion. Custom counting expression. Up to 10-min window, 1-day mitigation.
Enterprise (App Sec)
100 rules. Full request and header fields. Bot Management fields (with BM purchase). Throttle action. Up to 65,535s window, 1-day mitigation (custom via API).
Enterprise + ARL
All of ENT plus: request body fields, JSON fields, form input values, JA3/JA4 fingerprint counting, complexity-based scoring. The full product.
Say"Rate limiting is basically how you stop somebody from doing the same thing too many times in too short a window. Classic example: somebody hitting your login page a thousand times a second trying to guess passwords — rate limiting shuts them down after a few attempts. The thing customers don't always realize is that what they get depends a lot on the plan. Free and Pro give you the basics — count per IP, simple rules. Business adds more characteristics to count by. Enterprise unlocks the full WAF rule engine with hundreds of rules. But there's a separate tier above that called Advanced Rate Limiting, which is the version that actually solves the hard problems — counting by session token or JA3 fingerprint instead of IP (so it works behind CGNAT and corporate proxies), looking at the response your server sent back (so 'ten 401s from this user equals block' actually works), and even rating requests by how expensive they are to serve instead of just how many there are. If a customer has a real abuse problem they're trying to solve — credential stuffing, API abuse, expensive GraphQL queries — ARL is usually what they actually need, not basic rate limiting."
Customer Scenario The setup:A B2C platform with a public GraphQL API. Power users authenticate and run queries; the schema exposes deeply nested resolvers that can be expensive (a bad query can fan out to thousands of DB calls). The pain:Their database kept getting hammered by users — sometimes accidental (over-eager mobile app retries), sometimes intentional (scrapers). IP-based rate limits didn't work because users sat behind CGNAT and shared IPs. Per-user limits didn't work because the cheap-query attacker just stayed under the limit while sending expensive queries. What they built:Added Advanced Rate Limiting on their Enterprise contract. Rules counted by session token (not IP), and used GraphQL query complexity scoring as the count characteristic — every request's "cost" measured in resolver depth, not request count. Heavy queries got a strict budget, simple queries had a generous one. The outcome:Database load dropped about 40% within a week. The aggressive scrapers got priced out — their abusive queries hit the budget instantly. Legitimate heavy users were unaffected because their query patterns weren't actually that expensive.
Objection: "We haven't needed rate limiting yet""It's one of those things you don't need until you really do. Usually that's a credential stuffing attack, scraping incident, or somebody finding a free endpoint to abuse. By the time you need it, you want it already configured. Better to have it ready in monitoring mode and tune from there."
Objection: "Doesn't the WAF already handle this?""WAF inspects request content — is this a SQL injection, is this a known attack pattern. Rate limiting inspects frequency — is somebody doing this too many times. Same engine, different question. Most customers run both layered together: WAF catches the attack types, rate limiting catches the abusive volume."
Objection: "We have Enterprise, so we have everything""This is actually a common gotcha worth catching. Standard Enterprise gives you rate limiting with the full request and header fields, which is great. But the version with request body inspection, JSON field counting, form input counting, JA3/JA4 fingerprint counting, and complexity-based scoring is Enterprise with Advanced Rate Limiting — a separate entitlement on the contract. If their use case needs any of those advanced characteristics, we should check what their contract actually includes before promising the capability."
Objection: "Our app needs to handle bursts""Two answers. First, the period is configurable from 10 seconds up to a day — short period with high limit allows bursts; longer period catches sustained abuse. Second, you can layer multiple rules: one short-window high-limit rule for burst tolerance, one long-window strict rule for sustained abuse. That's the standard pattern for APIs that need elasticity."
Deep Dive — Rate Limiting (incl. Advanced Rate Limiting)
The tier breakdown that actually matters

The single most important thing to get right with rate limiting positioning is which capability comes with which tier. Customers (and SEs) often conflate "rate limiting" as one product, but the capability difference between Free and ENT-with-ARL is enormous. Here's the actual table:

CapabilityFreeProBusinessENT (App Sec)ENT + ARL
Number of rules125100100
Match fieldsPath, Verified Bot+ Host, URI, Query+ Method, Source IP, User AgentFull request and header fields, Bot Management fields+ Request body, JSON fields, form inputs
Counting by IP✓✓✓ (with NAT support)✓✓
Counting by Query / Host / Headers / Cookie / ASN / Country / Path————✓
Counting by JA3/JA4 fingerprint (requires BM)————✓
Counting by JSON field / body / form input————✓
Response-based counting (count on origin response code/headers)——✓✓✓
Cache exclusion——✓✓✓
Counting period max10s1 min10 min65,535s (~18h)65,535s (~18h)
Mitigation timeout max10s1 hr1 day1 day (custom via API)1 day (custom via API)
Throttle action (vs binary block)———✓✓
Complexity-based rate limiting————✓

Source: developers.cloudflare.com/waf/rate-limiting-rules. Verify before quoting specific tier limits to a customer — Cloudflare adjusts these occasionally.

What "Advanced Rate Limiting" actually unlocks

If a customer asks "what does Advanced Rate Limiting do that regular Enterprise rate limiting doesn't?" — here are the four things that matter most:

  • Body and payload inspection. Rate limit based on values inside the request body — a specific JSON field, a form input, a query parameter. Example: rate limit by the email field in a login POST body so attackers can't bypass IP limits by rotating IPs. Standard ENT can't do this; you need ARL.
  • JA3/JA4 TLS fingerprint counting. Rate limit by the client's TLS fingerprint, not IP. Catches sophisticated bots that rotate IPs but keep the same client library (Python requests, headless Chrome, curl, etc.). Requires Bot Management AND ARL on the contract.
  • Granular characteristic combinations. Standard ENT counts mostly by IP plus a couple of other fields. ARL lets you count by Query, Host, Headers, Cookie, ASN, Country, Path, or any combination — and create counting expressions that use response code or response headers. This is what makes "10 failed 401s in 60 seconds from this session = block" actually work.
  • Complexity-based rate limiting. Instead of counting requests, count cost. Your origin sends back a header with a score (1 to 1,000,000) representing how expensive that request was to serve. Cloudflare tracks the total cost per characteristic and triggers when total cost exceeds threshold. Critical for GraphQL endpoints, expensive search queries, file exports — where 100 cheap requests are fine but 5 expensive ones is abuse.
  • Surgical control over identified bots (requires Bot Management). When a customer has Enterprise Bot Management AND ARL, rate limiting rules can match on bot signals as first-class fields — cf.bot_management.score, bot detection IDs, verified bot status, JA3/JA4 fingerprint. So instead of binary block/allow on bot score, you can say "throttle scrapers to 10 req/min, block credential stuffers entirely, give AI crawlers their own budget, leave Googlebot alone." Bot Management identifies, ARL enforces. Killer combo for SaaS / ecommerce / fintech customers fighting scrapers and credential stuffing — and a real differentiator vs competitors whose rate limiting can't reference bot signals.
How it actually works (the mechanics)
  • Counter scope: Counters are maintained per data center, not globally. Multiple data centers in the same geographic location share counters. Every rule includes cf.colo.id as a mandatory characteristic automatically (added invisibly in the dashboard, must be explicit in API).
  • Counting characteristics: Tracks separate counters for each unique combination of characteristic values. Two requests with the same JWT subject from different IPs count separately if both IP and JWT are characteristics.
  • Sliding window: Window options: 10s, 15s, 20s, 30s, 40s, 45s, 60s, 90s, 120s, 180s, 240s, 300s, 480s, 600s, 900s, 1200s, 1800s, 2400s, 3600s, 65535s, 86400s. Pro caps at 60s. Business caps at 600s. ENT goes up to 65535s.
  • Mitigation timeout: Separate from the counting window. After threshold breach, the action persists for this duration regardless of subsequent traffic. Pro caps at 1h. Business and ENT cap at 1 day (custom via API on ENT).
  • Actions: Block, Challenge, Managed Challenge, JS Challenge, Log, Custom Response. Plus the Throttle action on ENT — throttles requests above the rate instead of binary block.
  • Counting expression: Business+ can use a separate counting expression from the match expression. So "match all requests to /login but only count requests that returned 401" — perfect for credential stuffing detection.
  • Account-level rate limiting rulesets (some ENT): Create rulesets at the account level and deploy to multiple zones. Useful for SaaS platforms with many customer hostnames.
  • Not designed for precise limits: There's a small delay (up to a few seconds) between detection and enforcement. Excess requests can still reach origin briefly. Counters are also per-data-center, so distributed attackers might get more total requests through than a global counter would allow. Be honest about this with customers — it's a rate limit, not a hard cap.
Anticipated customer questions
"What's the difference between Enterprise rate limiting and Advanced Rate Limiting?"Standard ENT rate limiting works on request and header fields plus Bot Management fields (if BM is on the contract). ARL adds request body inspection (JSON fields, form inputs, body content), JA3/JA4 fingerprint counting (requires BM), and complexity-based scoring. If their use case needs to count by something inside the request body or by TLS fingerprint, they need ARL — not just ENT.
"How does this work with CGNAT or mobile carriers?"Per-IP rate limiting overblocks behind CGNAT — entire households or office buildings share one IP. With ARL you count by session (cookie, JWT subject, header value) instead, which is far more accurate. This is one of the most common reasons customers move from basic rate limiting to ARL.
"Can we limit by response code?"Yes — Business plan and above. The counting expression can reference response code or response headers. Classic pattern: "10 failed 401 responses in 60 seconds from this source = block." This works because the counting expression is evaluated AFTER the response comes back.
"What's the cost during an attack?"Zero surge billing on the rate limiting itself. Cloudflare doesn't charge per blocked request. The cost is your plan tier — Pro/Business is a flat fee, ENT is contracted.
"How is this different from AWS WAF rate-based rules?"AWS WAF rate limits are per-IP only, with a 5-minute fixed window minimum, and don't support response-based or body-based counting. Ours: 10-second to 18-hour windows, multi-characteristic counting, response-based and body-based on ARL. Substantially more granular and accurate.
"Can we whitelist trusted partners or internal systems?"Yes — either via exception rules ("if header X-API-Partner = trusted-key, skip this rate limit") or by ordering rules so the trusted-partner rule with action Skip evaluates before the strict rule. Either pattern works.
"What if our app has legitimate burst traffic?"Layer two rules. Short window with high limit allows bursts (e.g., 1000 requests in 10 seconds). Long window with strict limit catches sustained abuse (e.g., 5000 requests in 1 hour). First rule lets bursts through; second rule catches anyone abusing the burst tolerance to maintain high sustained volume.
"Does this work for API key abuse?"Yes — rate limit by header value (the API key itself) on Business+, or by header value combined with response code on ARL. Per-customer limits become trivial. Perfect for SaaS API tier enforcement.
"What about GraphQL where one query can be very expensive?"This is exactly what complexity-based rate limiting (ARL only) solves. Your origin returns a header indicating the cost of each query (1-1,000,000). Cloudflare tracks total cost per characteristic. A query that runs an expensive join scores higher than a simple lookup, so you can limit "total cost per minute" instead of "number of requests per minute." Standard rate limiting can't do this.
"Can we rate limit specific bots differently?"Yes — if Bot Management is on the contract alongside ARL. Rules can match on bot score, bot detection ID (specific bot families), verified bot status, or JA3/JA4 fingerprint. Common patterns: "throttle scrapers (low bot score, not verified) to 10 req/min on the catalog, leave Googlebot alone." Or: "rate limit AI crawlers by detection ID so each one has its own budget." Bot Management identifies the bot; ARL enforces. Without Bot Management, you can match on Verified Bot status only — much less granular.
"How do we use ARL + Bot Management together against credential stuffing?"The classic pattern: counting expression matches POST to /login with response code 401, characteristic is JA3/JA4 fingerprint (because attackers rotate IPs but keep the same TLS client), threshold is something like 5 failed logins in 60 seconds, action is block for 30 minutes. The fingerprint counting catches IP-rotating bots that bypass per-IP limits, and the response-code counting only triggers on actual auth failures. Both require ARL; the JA3 counting also requires Bot Management. Without both, you're stuck with per-IP counting that overblocks behind CGNAT and underblocks rotating attackers.
"What's the maximum number of rules?"Free: 1. Pro: 2. Business: 5. Enterprise: 100. The 100 is enough for nearly every use case. If a customer needs more, that's a configuration design conversation — typically they have too many one-off rules and could consolidate.
"How accurate is the counter?"Honest answer: not perfectly precise. Counters are per-data-center, updated near-real-time with a small delay. Excess requests can leak through during the detection-to-enforcement gap. For most use cases (security and abuse prevention) this is fine. For applications needing exact limits (e.g., billing-related caps), you'd want application-layer enforcement too.
"Can we have different limits per endpoint?"Yes — each rate limiting rule has its own match expression. Different endpoint, different rule, different limit. Just stay within your plan's rule count.
"Does it slow down normal traffic?"No. Rate limit evaluation happens at the edge in the same proxy path as WAF rules — sub-millisecond overhead. It's only the requests that exceed the limit that get blocked or throttled.
Industry angles
Fintech
Failed login limits, transaction velocity, OTP request limiting. ARL critical for credential stuffing detection (count failed 401 responses by JWT subject or session cookie, not IP).
Ecommerce
Coupon attempt limits, checkout velocity (card testing), search and scrape protection. Carding attacks specifically need ARL because attackers rotate IPs constantly.
SaaS
API tier enforcement (free users 100/min, paid 10k/min — limit by API key in header). ARL needed if billing is based on complex query cost, not just request count.
Gaming
Login attempts, in-game action rate limits to prevent macros. ARL JA3 fingerprinting catches bot frameworks that rotate IPs but use the same library.
Media
Article reads per session (paywall enforcement), comment/upvote rate limits. Counting by session cookie (Business+) avoids the CGNAT problem.
GraphQL / API-heavy
Complexity-based rate limiting (ARL) is the killer feature. Without it, one $5/query GraphQL request looks identical to 100 cheap requests. With it, you cap cost not count.
Healthcare
Patient portal credential stuffing (very common attack pattern). ARL response-based counting on 401s is the standard approach.
Pricing notes: Rate limiting itself is included with each plan tier — no per-request fees, no surge billing during attacks. Advanced Rate Limiting is an Enterprise add-on entitlement, not automatic with ENT. Some Enterprise contracts include it, some don't. Always verify on the customer's actual contract before promising body/JSON/JA3/complexity-based features. Customers can preview ARL as a non-contract service to evaluate.
Gotcha — the "Enterprise" assumption: Customers (and SEs) often assume "we're Enterprise, we have everything." Standard ENT rate limiting is powerful but doesn't include body inspection, JA3 counting, or complexity-based scoring. Those require ARL specifically. Check the contract before quoting capabilities.
Gotcha — counter scope: Counters are per-data-center, not global. A distributed attack hitting 20 PoPs simultaneously could allow 20× the configured limit through in aggregate. For most use cases this is fine; for hard caps, layer application-side enforcement too.
Gotcha — CGNAT overblocking: Per-IP rate limiting overblocks legitimate users behind CGNAT (mobile carriers, corporate NAT). Always identify CGNAT-heavy user populations before deploying aggressive per-IP limits. Move to per-session counting on Business or ARL on ENT for accuracy.
Gotcha — Workers subrequest counting: If your Worker makes subrequests back to the same zone, those subrequests may count toward rate limits, causing rules to trigger sooner than expected. Document the pattern in customer Worker code.
Gotcha — verified bots: By default, rate limiting can affect verified bots (Googlebot, Bingbot, monitoring services). Applying aggressive limits to verified bots can hurt SEO. Use the Verified Bot field in your expressions to exclude them if needed.
Gotcha — counter accuracy delay: Counters update in near-real-time, not instantly. A burst within a few seconds can exceed the limit before enforcement kicks in. Don't promise customers exact precision — promise "rate limit" not "hard cap."
Gotcha — too low, too high: Limits set too low frustrate real users (false positives on legitimate burst traffic). Set too high, they don't catch abuse. Always pilot in log-only mode for a sprint before enforcing.
Where to find it in the dashboard
Zone Security → WAF → Rate limiting rules
Rate limiting lives alongside custom WAF rules — same Wirefilter rule engine, different action set.
  • Rate limiting rules — create, edit, and order rules. Configure match expression, counting characteristics, period, requests-per-period, action, mitigation duration.
  • Advanced rate limiting controls (ENT with ARL only) — body and JSON field inspection, JA3/JA4 fingerprint counting, complexity-based scoring with custom response header. Only visible if ARL is on the contract.
  • Counting expression (Business+) — separate from the match expression, allows response-code-based counting and other origin-side logic.

Zone Security → Events
See which rate limit rules are firing and how often. Filter by rule name, action taken, source IP, and characteristic values. Critical for tuning thresholds and identifying false positives.

Security Center → Rate limiting rulesets
Some Enterprise customers can create account-level rulesets that deploy to multiple zones. Useful for SaaS platforms managing rate limits across many customer hostnames.

Workers Free tier + Paid

What
Serverless JS/Wasm at the edge. Sub-ms cold starts. V8 isolates, not containers.
Use cases
Auth at edge • A/B tests • personalization • API routing • request/response transforms • aggregation.
Free
100k req/day. Paid: unlimited usage-based.
Say"Workers is basically a way to run your code on Cloudflare's network instead of having to run your own servers. The technical term for this is 'serverless,' which is a confusing name because there are still servers — they're just ours and you don't have to think about them. You write some code, push it up, and it instantly runs in all 330 of our data centers around the world. So when a user makes a request, your code runs in whichever city they're closest to, which is really fast. People use it for things like checking if a user is logged in, A/B testing different versions of their site, customizing content based on where the visitor is, or moving expensive work off their main servers. If you've heard of AWS Lambda, this is similar but much faster because of how it's built — and the pricing is simpler, you pay per request."
Customer Scenario The setup:Mid-sized ecommerce retailer running their main app in AWS us-east-1, serving customers across North America and Europe. The pain:Every visitor — including the ones in Frankfurt — round-trips to Virginia for personalization, A/B test bucket assignment, and login checks. Page load felt sluggish in EU, and the AWS bill kept climbing as traffic grew. What they built:They moved three things to Workers — the JWT validation on protected pages, the A/B test bucket assignment cookie, and the geo-based hero-image swap. Origin still serves the real product data, but the "who is this user and what should we show them" decision now happens at the edge in whichever city they're closest to. Total project was about two sprints for one engineer. The outcome:EU time-to-first-byte dropped from ~600ms to ~80ms, origin request volume fell roughly 40%, and the AWS bill on the affected services went down enough to cover the Workers spend several times over.
Objection: "We have servers already""Workers isn't a server replacement — it's about moving specific tasks (auth, routing, personalization) closer to users instead of round-tripping to origin."
Objection: "Sounds like Lambda""Similar concept, different architecture. Lambda is regional containers. Workers is global V8 isolates — faster cold starts, simpler pricing."
How this differs from regular CloudflareMost people think of Cloudflare as a passive proxy — it sits in front of your site, caches static stuff, blocks attacks, and forwards the rest to your origin. Workers is something completely different. Instead of just passing requests through, Workers lets you run YOUR code inside our network. So when a user makes a request, before it ever reaches your origin (or instead of reaching it at all), your JavaScript runs in whichever data center the user is closest to. You can authenticate them, look something up in KV or D1, call a third-party API, generate the response entirely, or rewrite the request before forwarding. The execution model is also fundamentally different from AWS Lambda — Lambda spins up a container in one region. Workers uses V8 isolates, the same engine that runs Chrome tabs, so the "spin up" is microseconds instead of seconds, and your code runs in all 330 PoPs simultaneously instead of one region. The result: customers move logic that used to require backend servers (geo-routing, A/B tests, edge auth, request transforms, full applications) to the edge where it's milliseconds from users worldwide.
Deep Dive — Workers
How it actually works
  • V8 isolates: Same engine that runs Chrome. Each isolate is a sandboxed JS context — process-light, memory-light. Spinning one up is microseconds, not seconds.
  • No cold starts (practically): Isolates pre-warmed across the network. P50 cold start <5ms; P99 typically <50ms. Compare to Lambda's 100ms–1s+ cold starts.
  • Global by default: Deploy once, runs on all 330+ PoPs simultaneously. No region selection.
  • Runtime: V8 with Workers Runtime APIs — Fetch API, Streams, WebCrypto, Web Standards-aligned. Increasingly Node.js-compatible (nodejs_compat flag exposes net, fs subset, crypto, buffer, etc.).
  • Languages: JavaScript, TypeScript natively. Rust, C, C++, Go, Python (via Pyodide/Wasm) via WebAssembly.
  • Limits: 50ms CPU time on Free, 30s on Paid (configurable up to 5min CPU on ENT bundles). 128MB memory. Sub-request limit (50 default, 1000 ENT).
  • Storage integrations: KV (eventually consistent, 60s edge cache), R2 (S3-compatible object storage), D1 (SQLite), Durable Objects (strongly-consistent state), Queues (async work), Hyperdrive (Postgres connection pooling), Vectorize (vector DB for embeddings).
  • Pricing model: Per-request + per-CPU-millisecond on Paid. Free tier: 100k req/day. Standard: $5/mo includes 10M requests/30M CPU-ms.
Anticipated customer questions
"What about Node.js compatibility?"Significant subset now — nodejs_compat flag enables fs (limited), net, tls, crypto, buffer, async_hooks, and most popular npm packages work. Express, Hono, itty-router, all run.
"Can we use our existing npm packages?"Most pure-JS packages: yes. Packages with native bindings (better-sqlite3, sharp): no. Bundlers (Wrangler, Vite) handle most of this.
"How does cold start really compare to Lambda?"Lambda: 100ms-2s+ (worse for large packages, VPC, Java/.NET). Workers: typically <5ms. Architectural advantage from V8 vs containers.
"What's the cost compared to Lambda?"Workers paid: $0.30/M requests + $0.02/M CPU-ms (10ms incl). Lambda: $0.20/M requests + $16.67/M GB-sec. For light workloads Workers is much cheaper; for compute-heavy, similar. No data egress charges.
"What about long-running tasks?"CPU time limit applies (30s standard). For longer work: Queues for async, Workflows (durable, multi-step), or Containers (for true long-running).
"How do we observe production?"Workers Observability: real-time logs (tail), metrics, traces. Logpush to Datadog/Splunk/S3. Real User Monitoring integration.
"Can we run a database connection?"Hyperdrive — connection pooling for Postgres/MySQL/MongoDB. Workers maintain pools to your DB without each isolate opening a new connection.
"What about CPU-bound work (ML inference)?"Workers AI for inference. Otherwise: 30s CPU limit per request, 5min on ENT.
"How do we handle state?"Durable Objects — single-threaded, in-memory, strongly consistent stateful actors. Ideal for game state, collaborative editing, sessions.
"Security model?"Each Worker is sandboxed in its own V8 isolate — no shared memory between tenants. Same isolation Chrome uses for tabs. SOC2 Type II, ISO 27001.
"Can we self-host the same code?"Workerd is open source — same runtime, can run locally or self-hosted. Wrangler dev uses workerd locally.
"What about deploying behind our existing app?"Workers can sit in front of any origin. Add auth/personalization/A/B testing without modifying origin. Or replace origin entirely.
Industry angles
Fintech
Authentication at edge, JWT validation, fraud signals in <10ms. PCI-compliant deployment patterns.
Ecommerce
A/B testing, personalization, cart edge logic. Replace heavy origin work with edge-cached responses.
SaaS
Multi-tenant routing — strip tenant subdomain, route to backend. Custom domain proxying. Free-tier rate enforcement.
Media
Personalization, A/B test news layouts, geographic content rules, paywall logic.
Gaming
Lobby logic, matchmaking, leaderboards via Durable Objects. Sub-ms latency to players.
Healthcare
Patient routing, BAA-compliant deployments (ENT), authentication wrappers around legacy systems.
Pricing notes: Free: 100k req/day. Standard (paid): $5/mo includes 10M req + 30M CPU-ms, overage at $0.30/M req + $0.02/M CPU-ms. Workers Paid bundles include Pages, KV, R2, D1 starter quotas. Enterprise: custom commit, higher limits, BAA/SOC support.
Gotcha: Not all npm packages work — anything with native modules (sharp, better-sqlite3, native ML libs) won't run. Check with Wrangler before promising.
Gotcha: KV is eventually consistent — writes propagate globally in seconds. For consistency, use D1 or Durable Objects.
Gotcha: No filesystem. Static assets via Workers Sites/Assets or R2.
Gotcha: Sub-request limit (50 default) — workers calling many APIs may hit this. Raise on Paid/ENT.
Where to find it in the dashboard
Compute (Workers) → Workers & Pages
Workers is account-scoped. Find it under the Compute section in the left nav.
  • Workers & Pages overview — all your Workers and Pages projects in one list.
  • Create — start a new Worker (from template or blank), connect Git, or upload code.
  • [Worker name] → Metrics — requests, errors, CPU time, response codes per Worker.
  • [Worker name] → Logs — real-time log tail and stored logs (Workers Logs / Logpush).
  • [Worker name] → Settings — environment variables, secrets, bindings (KV, R2, D1, Queues, Durable Objects, etc.), routes, triggers.
  • [Worker name] → Deployments — version history, rollback to previous deployment.

Storage & Databases
Sister products Workers use: KV (key-value store), R2 (object storage), D1 (SQL), Durable Objects, Hyperdrive, Vectorize, Queues.

Workers for Platforms Enterprise (multi-tenant SKU)

What
Workers, but for your customers' code. A multi-tenant runtime where a single "dispatch" Worker routes requests to thousands of isolated customer Workers.
Why
If you're a SaaS platform letting customers ship their own code, integrations, or storefronts, you need to run untrusted code safely and cheaply. WfP solves that.
Famous example
Shopify Oxygen — the runtime behind every Hydrogen storefront — is built on Workers for Platforms. Every Shopify merchant running Hydrogen is, under the hood, running their own Worker on Cloudflare.
Say"Workers for Platforms is what you reach for when you're a SaaS company and your customers want to run their own code. The classic example is Shopify — every merchant on Hydrogen has their own storefront, with their own custom logic, and Shopify needs to run that customer code safely without one merchant's bad code breaking another merchant's store. They could've built a sandboxing system from scratch — Vercel did, AWS has Lambda layers, Heroku had it once — but it's a massive engineering project. Workers for Platforms is the productized version. You build one 'dispatch' Worker that routes incoming requests, and each of your customers gets their own isolated Worker that you upload on their behalf. They're all completely sandboxed from each other — same isolation Chrome uses between tabs. You can run thousands or millions of these without managing infrastructure per tenant. It's basically multi-tenant Workers with the right primitives for a SaaS platform."
Customer Scenario The setup:A SaaS company runs a no-code website builder with 50,000 paying customers, each with their own custom site. The pain:Their power-user tier wants to write custom JavaScript — form validation, A/B tests, custom redirects — that runs on their site. The platform team built a sandbox using VMs, then containers, then a homegrown V8 sandbox. Every version had security holes, performance ceilings, or both. One customer's infinite loop took down a neighbor's site twice last year. What they built:They replaced the homegrown sandbox with Workers for Platforms. Their main app stayed where it was — they just added a dispatch Worker at the edge that takes incoming requests, looks up the customer's tenant ID, and routes to that customer's user Worker. Customer code is uploaded via their existing platform UI, which now calls Cloudflare's API behind the scenes. Each user Worker is sandboxed from every other user Worker by V8's isolation. The outcome:They deleted ~6,000 lines of homegrown sandbox code, killed the "noisy neighbor" outage class entirely, and unlocked a new pricing tier where customers can write real JavaScript without the platform team being on the hook for it.
Objection: "Why not just run customer code in regular Workers?""You could — but you'd hit two walls fast. First, Worker quota and billing — regular Workers are scoped to one account, so you'd need separate accounts per customer, which is unmanageable at scale. Second, you need a dispatch layer to route customer-by-customer, and WfP gives you that primitive. The pricing model is also built for multi-tenant — per-script, not per-account."
Objection: "Can't we use AWS Lambda or Vercel Functions?""Lambda containers have cold starts that kill any 'run on every request' use case — fine for batch, brutal for a storefront. Vercel Functions are great but Vercel is itself built on AWS, so you're paying their margin on top of cold-start latency. Workers for Platforms is the right primitive when you have thousands of tenants, you need sub-10ms execution, and you don't want to operate sandboxing infrastructure yourself."
Objection: "We don't want to lock our customers into Cloudflare""Customers don't have to know they're on Cloudflare — your dispatch Worker is the only public surface. Their code runs in standard Workers Runtime, which is open-source (workerd). If you ever wanted to migrate, the code itself is portable. The lock-in story here is much weaker than Lambda."
Deep Dive — Workers for Platforms
How it actually works
  • Dispatch namespace: The container that holds all your customer Workers. You can have multiple — production, staging, free-tier vs paid-tier, etc.
  • User Workers: Each customer's code, uploaded via API. Fully isolated V8 isolates. Each gets its own bindings (KV, R2, D1, secrets) if you provision them.
  • Dispatch Worker: The "router" you write. Receives every request, decides which user Worker to call, and forwards. Typical implementation: parse the hostname or path, look up the tenant, then env.DISPATCHER.get(scriptName).fetch(request).
  • Outbound Workers: Optional layer that intercepts outbound fetch() calls from user Workers — for logging, billing, blocking certain hosts, or proxying through your own infra.
  • Tail Workers: Stream logs from all user Workers to one central place for your platform's observability.
  • Limits per user Worker: Same as regular Workers — 128MB memory, 30s CPU on Paid (5min ENT), 50 sub-requests by default.
  • Custom domains: Each customer can have their own domain pointing at your dispatch Worker — full white-label support.
Anticipated customer questions
"How many user Workers can we have?"Effectively unlimited — Cloudflare has customers running hundreds of thousands of user Workers in production. Pricing scales linearly per script, so you can model it.
"How does pricing work?"Per-script subscription (small flat fee per user Worker per month) + standard Workers per-request and CPU pricing on top. Enterprise contracts roll this into a committed-use model. Talk to your AM for specifics — the math depends on tenant count and traffic profile.
"Can we restrict what customer code can do?"Yes. Outbound Workers can block or rewrite any fetch() the user Worker makes. You can deny network access, restrict bindings, limit sub-requests, and set per-tenant CPU limits. Standard pattern is allowlist of outbound hosts for paranoid platforms.
"How do customers deploy their code?"Through your platform's UI or API — you call Cloudflare's API on their behalf. Customers never see Wrangler or the Cloudflare dashboard. Most platforms add a code editor or a Git-connect flow to their own product.
"What about secrets?"Per-user-Worker secrets, managed via API. Your platform UI lets customers set their secrets (Stripe keys, etc.), you store them on the user Worker through the WfP API. Cloudflare encrypts at rest.
"Can user Workers talk to each other?"Only if you allow it — via your dispatch Worker or via service bindings. Default: each user Worker is fully isolated.
"What if a user Worker has a security bug?"It's still sandboxed by V8, so the blast radius is one user's data — not the whole platform. Same isolation as Chrome tabs. You can also kill or version-lock individual user Workers without redeploying the platform.
"How do we debug a specific customer's Worker?"Tail Workers stream logs centrally. You can also enable per-user-Worker observability and pull metrics for any tenant through the API. Most platforms build a "view logs" feature into their own customer dashboard.
Industry angles
Headless commerce
Shopify Oxygen is the textbook reference. Any platform letting merchants ship custom storefront code fits this pattern.
No-code / low-code
Webflow, Bubble-style platforms wanting to offer "drop in custom JS" without building their own sandbox.
SaaS integration platforms
Zapier-style platforms where customers write their own transformation logic between apps.
Developer platforms
API gateways letting customers run middleware. CI/CD platforms running customer build steps. Anywhere customers ship code.
Edge AI platforms
Letting customers deploy their own prompts, transformations, or agents that run at the edge in front of Workers AI.
Pricing notes: WfP is sold as an Enterprise SKU — talk to your AM. Roughly: per-script monthly fee + standard Workers per-request + CPU. The economics work when you have hundreds+ tenants with low-to-medium per-tenant traffic. If you have ten huge tenants, regular Workers in separate accounts might be cheaper.
Gotcha: WfP is an Enterprise-only SKU — not on Free or Workers Paid. If a prospect is on a Workers Paid plan exploring multi-tenant, they need to upgrade before they can use WfP.
Gotcha: Outbound Workers add latency to every fetch() user code makes. Skip them for non-paranoid use cases.
Gotcha: User Workers don't have a UI in the dashboard — they live behind the API. Customers can't browse to "their Worker" on Cloudflare. The platform builds its own UI.
Where to find it in the dashboard
Compute → Workers for Platforms
Visible only after the WfP SKU is on the account. Talk to your AM if it's not showing up for an Enterprise prospect — it's a separate entitlement.
  • Dispatch namespaces — list of all your namespaces. Create / delete / configure here.
  • [Namespace] → Scripts — list of all user Workers in this namespace. View, kill, or inspect any tenant.
  • [Namespace] → Settings — outbound Worker config, tail Worker config, limits.

Workers AI

What
Run AI inference (LLMs, image, audio) on Cloudflare's GPU network.
Why
Low latency, data stays on CF, no external provider keys to manage.
Say"Workers AI lets you build AI features into your app without having to set up servers with GPUs or send your data to OpenAI. Basically, we host all the popular open-source AI models — Meta's Llama, Mistral, Stable Diffusion for images, Whisper for transcription — and you just call them through our API. The big advantages are speed, cost, and privacy. Speed because the AI runs in our data centers close to your users instead of in some far-away region. Cost because it's a fraction of what OpenAI charges, especially for smaller tasks like classifying content, summarizing documents, or generating product descriptions. And privacy because your data stays on Cloudflare — we don't use it to train models. Most customers still use OpenAI or Claude for really complex reasoning, but use Workers AI for the everyday stuff, and the savings add up fast."
Customer Scenario The setup:A customer support SaaS handles ~2 million support tickets a month for their customers. They've been using GPT-4 to auto-classify tickets (priority, category, sentiment) and to write suggested first-response drafts. The pain:The OpenAI bill crossed $40K a month and kept growing. 80% of the spend was on simple classification — work that didn't need a frontier model. They also had a few enterprise customers asking pointed questions about whether their ticket content was leaving their region or being used to train models. What they built:They moved the classification and sentiment work to Workers AI using Llama 3.3 — kept GPT-4 only for the response drafting where quality really mattered. AI Gateway sat in front of both so they could monitor cost and latency in one place. Customer ticket data now stays on Cloudflare for the classification path. The outcome:OpenAI bill dropped about 70%. Classification latency improved because Workers AI runs close to the user. The enterprise customers got a clean answer to the data-handling question, which unblocked a deal that had been stuck on it for months.
Objection: "We use OpenAI""Not a one-for-one replacement — OpenAI is great for complex reasoning. Workers AI shines when latency matters or data privacy is a concern. Many customers use both."
Deep Dive — Workers AI
How it actually works
  • GPU network: NVIDIA GPUs deployed in 190+ cities globally. Inference routes to nearest GPU PoP.
  • Model catalog: Llama 3.1/3.2/3.3 (Meta), Mistral, Gemma, DeepSeek, Qwen, Phi, Stable Diffusion XL/Flux, Whisper, MeloTTS, BGE embeddings, Llama Guard. Growing weekly.
  • Inference patterns: Text generation, embeddings, image generation, image classification, speech-to-text, text-to-speech, translation, summarization, safety classification.
  • AI Gateway integration: Caching, rate limits, retries, fallback to other providers, real-time logs — sits in front of Workers AI or any external LLM API.
  • Vectorize: Native vector DB for RAG workflows. Store embeddings, query by similarity. Integrated with Workers AI for end-to-end RAG without external services.
  • AI Search: Managed RAG (formerly AutoRAG) — index your content (R2 buckets), get instant RAG-as-a-service.
  • Agents: Framework for building multi-step stateful AI agents. Uses Workers AI for inference, Durable Objects for state, optionally Workflows for long-running async work.
  • Workflows: Durable multi-step execution. Pair with Workers AI for content generation pipelines, AI agent orchestration, multi-stage processing with retry logic.
  • Privacy: Customer prompts/responses are not used for model training. Available in most regions (data residency considerations apply).
Anticipated customer questions
"What models are available?"Llama 3.3 70B, Mistral, DeepSeek-R1 distilled, Stable Diffusion XL, Flux, Whisper-large-v3, BGE embeddings, plus dozens more. Full catalog at developers.cloudflare.com/workers-ai/models.
"Can we run custom models?"BYO LoRA fine-tunes on supported base models. Full custom model hosting is a separate Enterprise conversation (compute provisioning).
"How does pricing work?"Per neuron — abstracted unit normalized across model size. Pay per inference. Free tier: 10k neurons/day. Most queries cost fractions of a cent.
"What about latency vs OpenAI?"Inference runs in our PoP — typically sub-200ms for 7B models, faster for smaller. Vs OpenAI's variable response times. For RAG, the storage+retrieval+inference round-trip is all on us.
"Quality compared to GPT-4/Claude?"For complex reasoning, frontier closed models still lead. For most production tasks (classification, extraction, summarization, RAG), open models on Workers AI are sufficient and dramatically cheaper.
"What about data residency?"Inference happens in our PoPs. We're working on regional pinning (data residency for inference). Today, prompts may route across regions.
"How does this work with our existing stack?"REST API, drop-in for OpenAI-compatible endpoints (some models). SDK in Workers — call env.AI.run('@cf/meta/llama-3.3-70b', {...}).
"What about AI safety / hallucinations?"Llama Guard for content safety classification. AI Gateway caches deterministic queries. RAG patterns ground responses in your data.
"Can we do RAG?"Yes — Vectorize (vector DB) + Workers AI (embeddings + inference) + R2 (source documents). Or use AI Search (managed RAG).
"What about agentic workflows?"Workflows (durable execution) + Workers AI + AI Gateway. Build multi-step agents with retries, state, observability.
Industry angles
Fintech
Document classification, KYC text extraction, customer support summarization. Data privacy critical — Workers AI keeps PII on Cloudflare.
Ecommerce
Product description generation, search query intent, image classification for catalog, personalized recommendations via embeddings.
SaaS
In-product AI features (summarize this doc, generate this email) without taking a dependency on OpenAI API keys.
Media
Auto-tagging, transcription (Whisper), translation, content moderation.
Healthcare
Limited to non-PHI use cases today — BAA discussion required. Document summarization on de-identified content, scheduling assistance.
Gaming
In-game NPC dialogue, content moderation for chat, voice-to-text for accessibility.
Pricing notes: Per-neuron pricing — model-agnostic abstraction. Free tier 10k neurons/day. AI Gateway is free (paid features coming for advanced caching/analytics). Vectorize: per-dimension stored + per-query. AI Search: per-query + storage.
Gotcha: Not every model has every region. Smaller GPU PoPs may route to larger ones, adding latency.
Gotcha: Context windows vary by model. Llama 3.3 70B: 128K. Smaller models: 8K-32K. Pick model accordingly.
Gotcha: No support for proprietary models (GPT-4, Claude) running on Workers AI — use AI Gateway to proxy those.
Gotcha: Cold start on rarely-used models can add latency on first request. Hot models (Llama 3.x) are always warm.
Where to find it in the dashboard
AI → Workers AI
Find all AI products under the AI section in the left nav.
  • Models — browse the full model catalog. Each model has docs, examples, REST API URL, pricing per neuron.
  • Playground — try models in-browser before integrating. Useful for picking the right model.
  • Analytics — neuron usage, requests by model, response times.

AI → AI Gateway
Proxy and cache for any LLM provider (Workers AI, OpenAI, Anthropic, Groq, etc.).
  • Gateways list — create one gateway per project/use-case.
  • [Gateway] → Analytics — request volumes, cache hit rates, costs by provider.
  • [Gateway] → Logs — full prompt/response log for debugging and audit.
  • [Gateway] → Settings — caching policy, rate limits, fallbacks, evaluations.

AI → Vectorize / AI Search
  • Vectorize — vector database for RAG. Create indexes, configure dimensions, query.
  • AI Search — managed RAG. Point at R2 buckets, get instant search/chat.

Workers Observability Included with Workers

What
Built-in logs, metrics, traces, and analytics for every Worker. Real-time tail, historical search, dashboards, alerts. No agent to install, no extra vendor.
Why
The moment a customer puts a Worker in production, the next question is "how do I debug it?" Workers Observability is the answer that ships with the product — no separate Datadog contract, no agent to install.
Also includes
Logpush (stream logs to S3/Datadog/Splunk), Tail Workers (programmatic log handlers), Analytics Engine (custom time-series metrics), Workers Logs (queryable log storage).
Say"Workers Observability is the part most customers don't think about until they're in production. You've shipped your Worker, traffic is flowing, and now something is slow or broken and you need to figure out why. Observability gives you all of that built in. Real-time log tail to watch requests as they happen. Stored logs you can search across the last few days. Per-Worker metrics — requests, errors, CPU time, response codes. Traces showing how requests flow through your bindings. And it's all native — you don't install an agent, you don't pay a Datadog bill per gigabyte of logs. For customers who already pay six figures a year to ingest CDN and app logs into Datadog, this is one of those 'wait, that's included?' moments. For everyone on Enterprise we also have Logpush, which streams every log line to wherever you want — S3, Splunk, Datadog, your SIEM — so you can keep your existing tooling and just stop paying to forward logs."
Customer Scenario The setup:A fintech SaaS company runs 40 Workers in production handling auth, fraud checks, and webhook delivery. They pay Datadog roughly $180K a year to ingest logs from their Cloudflare zone. The pain:Every quarter Datadog raises the bill because log volume keeps growing. Most of what they ingest is routine — request logs they only ever look at when something breaks. They want centralized observability but not at that price. What they built:They kept Datadog for their non-Cloudflare services but turned on Workers Observability for the Workers fleet. The native dashboard handles day-to-day debugging. For the security team that needs everything in Splunk for compliance, they wired Logpush to stream filtered logs (errors and security events only) instead of everything. Most "noisy" logs now live in Workers Logs and get queried directly when needed. The outcome:Datadog ingestion volume dropped about 70%, Splunk volume dropped about 50%, and the engineering team actually likes the native tail better than Datadog Live Tail because there's no lag.
Objection: "We're already paying for Datadog / New Relic / Splunk""You can keep them. Workers Observability isn't a replacement for your full APM — it's specifically for what runs on Cloudflare. Most customers keep their existing APM for non-Cloudflare services and use Observability + Logpush for the Workers fleet. Net effect: you stop paying to ingest Cloudflare logs into a third party that costs $5-15 per GB. Your existing tools stay in place for everything else."
Objection: "Is the native tooling actually good enough?""For Workers specifically, yes — it's better than third-party tools because it has direct access to runtime internals. You see actual CPU time, sub-request traces, binding-level latency, things Datadog can't see because it's outside the runtime. For non-Workers observability (your AWS services, your databases, your mobile app), keep what you have."
Objection: "What about retention?""Workers Logs retention varies by plan — typically 3 days standard, 7 days on Paid, longer on Enterprise. For compliance retention beyond that, use Logpush to S3 or your SIEM. Long-term storage is cheap when you don't pay per GB to a SaaS log vendor."
Deep Dive — Workers Observability
How it actually works
  • Workers Logs: Every console.log and HTTP request log is captured automatically. Searchable in the dashboard or via API. Default retention 3 days (longer on paid plans).
  • Real-time tail: wrangler tail or the dashboard streams logs as they happen — no lag, no sampling. Filter by status code, method, IP, header.
  • Metrics: Per-Worker dashboards — requests, errors, CPU time (P50/P90/P99), response codes, sub-request count. No setup required.
  • Traces: Distributed tracing across Workers, bindings, and sub-requests. Shows the request path from edge → Worker → KV/D1/R2/etc. → response.
  • Tail Workers: Write a Worker whose job is to receive the logs of another Worker. Use for custom filtering, routing logs to multiple destinations, or running analytics on log streams.
  • Logpush: Stream logs from any Cloudflare service (Workers, CDN, WAF, Zero Trust, etc.) to S3, GCS, Azure Blob, Datadog, Splunk, Sumo Logic, or HTTPS endpoints. Enterprise feature.
  • Analytics Engine: Write custom time-series metrics from inside a Worker. Like StatsD or Prometheus, but built-in. Query via SQL through the dashboard or API. Free up to 10M data points/day.
  • Alerts: Set thresholds on error rate, CPU time, request volume — get notified via email, PagerDuty, Slack, webhook.
Anticipated customer questions
"How much does it cost?"Workers Observability is included with Workers — no extra charge for the dashboard, metrics, or basic logs. Logpush is a paid Enterprise feature. Analytics Engine has a generous free tier (10M data points/day) and per-data-point pricing above that.
"Can we send logs to our existing SIEM?"Yes — Logpush has native connectors for Datadog, Splunk, Sumo Logic, S3, GCS, Azure, and generic HTTPS. Most customers point at the SIEM they already have.
"How does this compare to Datadog APM?"For Workers specifically, native Observability has deeper visibility (CPU time, binding traces, isolate metrics). Datadog has a wider product (RUM, infrastructure, synthetic checks, AI-assisted debugging). Most customers keep Datadog for everything else and use native Observability for Workers.
"What about PII in logs?"Logs are stored in Cloudflare — same SOC2/ISO/GDPR posture as the rest of the platform. For HIPAA, BAA is available on Enterprise. Customers concerned about PII can scrub before logging (in the Worker) or filter in Logpush before delivery.
"Sampling?"Default: no sampling, every request is captured. For very high-volume workloads, you can sample programmatically in the Worker. Logpush supports head-based sampling.
"Can we trace from our app through Workers and into our origin?"Yes — Workers Observability supports distributed tracing with W3C trace context. Pass trace headers from your origin/app, Workers will propagate them, and you can stitch the full trace in your APM of choice.
"Custom metrics?"Analytics Engine. Write any time-series data from a Worker (latency, business events, conversion rates) and query it via SQL. Free for first 10M data points/day, cheap after.
Industry angles
Fintech
Centralized audit logs via Logpush to immutable S3. Per-transaction tracing for compliance. PCI-compliant deployment patterns.
Ecommerce
Watch checkout latency in real-time during sales. Alert on conversion drop. Trace cart-to-purchase flows across Workers.
SaaS
Per-customer usage metrics via Analytics Engine. Surface in customer-facing dashboards. Bill by usage without separate metering infra.
Healthcare
BAA-covered log storage on Enterprise. Logpush to compliant SIEMs (Splunk on-prem, etc.). Tail Workers for redacting PHI before logs leave Cloudflare.
Media
Track per-article performance, A/B variant outcomes, paywall conversion. Analytics Engine for content metrics without a separate data warehouse.
Pricing notes: Workers Observability dashboard and metrics: free, included with Workers. Workers Logs storage: included on Paid (retention varies). Tail Workers: standard Workers pricing. Logpush: Enterprise feature, no per-GB ingest fees (unlike most SIEM destinations). Analytics Engine: 10M data points/day free, then per-data-point pricing.
Gotcha: Logpush is Enterprise-only. Customers on Paid see the dashboard and tail but can't stream logs out to a third party.
Gotcha: Console.log statements in tight loops can blow through CPU time on the Worker — logging is cheap but not free. For very high-throughput Workers, log selectively.
Gotcha: Analytics Engine queries are SQL-like but it's not a full SQL database — joins are limited, queries run on time-series semantics. Read the docs before building dashboards that depend on complex queries.
Where to find it in the dashboard
Compute → Observability
Account-level observability for the whole Workers fleet. Per-Worker observability lives inside each Worker's page too.
  • Workers Observability overview — fleet-wide metrics across every Worker in the account.
  • Logs — search across all Workers' stored logs.
  • Traces — distributed traces across the Worker fleet.
  • Alerts — set up thresholds and notification channels.

[Specific Worker] → Logs / Metrics
Per-Worker view — most customers live here day-to-day.

Zone or Account Analytics & Logs → Logpush
Configure Logpush destinations. Push from Workers, CDN, WAF, Zero Trust, anywhere logs are generated.

Agents

What
Cloudflare's framework for building AI agents — long-running, stateful, multi-step AI applications that can call tools, persist memory, and communicate in real-time.
Why
An "agent" isn't a single API call to an LLM. It's a multi-step system that holds context, decides what to do next, calls tools, and may run for minutes or hours. Building that on raw Workers means stitching together Durable Objects (for state), Workers AI (for inference), Workflows (for durability), Queues (for async work), and WebSockets (for real-time). The Agents framework bundles all that into one primitive.
Say"Agents is how you build AI agents on Cloudflare. The word 'agent' gets thrown around a lot, but the technical version is: an AI app that takes goals, plans steps, calls tools, holds memory, and runs for longer than a single API call. Think of a coding assistant that reads your repo, writes a PR, runs tests, and iterates. Or a customer service bot that handles a multi-turn conversation, looks things up in your database, and escalates to a human when needed. Building that on top of plain Workers means assembling Durable Objects for state, Workers AI for inference, Workflows for durable multi-step execution, Queues for async tasks, and WebSockets for real-time updates. Agents is a framework that bundles all of that — one class, one binding, one mental model. Pair it with the model of your choice (Workers AI, OpenAI, Anthropic via AI Gateway), give it tools it can call, and you've got a real agent."
Customer Scenario The setup:A logistics SaaS company wants to add an "AI dispatcher" — a multi-turn agent that helps customer ops teams handle exceptions (delayed shipments, customs holds, weather reroutes). It needs to remember the conversation, call internal APIs for shipment lookups, and sometimes wait hours for an external response. The pain:First version was built on raw OpenAI calls plus a Postgres conversation table. Memory was fragile, conversations got lost when the backend restarted, and multi-step actions that needed to wait for external systems were impossible without polling. What they built:Rebuilt on the Agents framework. One Agent class per customer-ops session. Memory persisted in the Durable Object underneath. Tool calls hit shipment-lookup, customs-status, weather-API as bindings. Long-running waits (4 hours for a customs response) used Workflows under the hood — the agent literally paused and resumed when the response came in. Same OpenAI calls, just routed through AI Gateway for observability. The outcome:Conversation continuity stopped being a bug. The agent could handle multi-day exception cases without losing context. Total infra was Cloudflare + OpenAI — one less Postgres to manage. Build time on the rewrite was ~3 weeks vs. an estimated 3-month rebuild on raw primitives.
Objection: "We're using LangChain / LlamaIndex / CrewAI""Those are application frameworks — great for prototyping agent logic. Agents on Cloudflare is the infrastructure layer underneath — state persistence, durability, edge inference, real-time messaging. Most customers run LangChain (or similar) on top of Agents for the application logic. Not a head-to-head competitor; they're complementary."
Objection: "How is this different from just using Durable Objects?""Agents is built on Durable Objects under the hood — it's the right abstraction for the agent use case. You could build agents directly on DO and many customers have. The Agents framework adds: pre-built tool-calling patterns, WebSocket session management, model adapter layer (swap between providers), memory primitives. Saves a few hundred lines of boilerplate per agent. Use DO directly if you need full control; use Agents framework if you want batteries included."
Deep Dive — Agents
How it actually works
  • Built on Durable Objects: Each agent instance is a Durable Object — single source of truth, strongly consistent, has its own storage. Survives across requests.
  • Stateful by default: Memory, conversation history, tool call results, partial state — all persisted in the agent's storage. No external DB to wire up.
  • Tool calling: Define tools as functions. Framework handles the LLM tool-calling protocol (parsing, invocation, result return). Works with any function-calling-capable model.
  • Model adapters: Plug in Workers AI, OpenAI, Anthropic, or anything via AI Gateway. Swap models without rewriting agent logic.
  • WebSockets: Real-time streaming of model output, tool calls, and intermediate state to the client. WebSocket hibernation keeps idle sessions cheap.
  • Workflows integration: For long-running multi-step processes (hours, days), call out to Workflows for durable execution with retries.
  • HTTP and RPC interfaces: Agent exposes HTTP and RPC. Worker handles request, forwards to agent instance via env.AGENT.get(id).
  • Browser Run integration: Built-in tool primitive for browser automation — agent can navigate, fill forms, scrape, take screenshots.
Anticipated customer questions
"What's the difference between an 'agent' and a chatbot?"Chatbot: stateless or simple-state Q&A. Agent: takes goals, plans steps, uses tools, holds long-term memory, may run autonomously. Continuum, not binary — a sophisticated chatbot with tools and memory is approaching agent territory.
"Use case examples?"Coding assistants (read repo, write code, run tests). Customer service bots (multi-turn, tool-calling, escalation). Research agents (web search, summarize, cite). Workflow automation (read email, extract data, file ticket). Trading agents (monitor signals, place orders within policy). Game NPCs with persistent memory.
"Pricing?"Workers Paid required. Agents is built on Durable Objects so you pay DO pricing — $0.15/M requests + duration + storage. Plus model inference costs (Workers AI per-neuron, or external provider via AI Gateway).
"Can it handle long-running tasks?"Within an agent session: yes (WebSocket hibernation makes it cheap). For really long async work (hours of background processing): use Workflows for durable execution, agent kicks off Workflow and watches results.
"How does memory work?"Two layers. Short-term: conversation context fed back into model on each turn. Long-term: agent's own SQLite storage (via Durable Object) holds whatever you persist — user preferences, prior interactions, learned facts. You decide what to remember and how to retrieve.
"What models can I use?"Workers AI models (Llama, Mistral, DeepSeek, etc.), OpenAI, Anthropic, Google Gemini via AI Gateway. Any model with function-calling support fits naturally. Models without tool calling can still work but the integration is rougher.
"Is it open source?"Framework code is open source, framework itself runs on Cloudflare's stack. SDK on npm, examples in GitHub repos.
"How does this compare to OpenAI Assistants API?"OpenAI Assistants: tied to OpenAI models, runs on OpenAI infrastructure, opinionated about tool/memory model. Cloudflare Agents: model-agnostic, runs on your infrastructure, more flexible. Pick OpenAI Assistants if you're all-in on GPT and want least-code. Pick Cloudflare Agents if you want infrastructure control or multi-model.
Industry angles
SaaS
In-product AI assistants — help users navigate, automate tasks, answer questions about their data. Agent per user / per workspace.
Customer support
Multi-turn ticket triage, knowledge-base RAG, escalation to humans. Pair with Vectorize for RAG.
DevTools
Coding assistants, automated review, repo navigation. Built-in Browser Run for headless web automation.
Internal automation
Workflow agents — read tickets, extract data, file follow-ups, summarize. Pair with Workflows for durability.
Gaming
NPCs with persistent memory and tool use. Agent per character.
Pricing: Workers Paid plan required. Durable Objects pricing applies (requests + duration + storage). Plus model inference costs. Agents framework itself adds nothing beyond underlying DO + model usage.
Gotcha: Agents inherit Durable Objects' tradeoffs — single-threaded per instance, geographic locality, WebSocket hibernation required for cost control.
Gotcha: Framework is newer (released in 2025). API surface and patterns still evolving. Lock-in considerations: agent logic is your code, but framework adapters are Cloudflare-specific.
Gotcha: Tool implementations are still your responsibility. The framework gives you the calling protocol; you write the actual tool functions.
Gotcha: Cost can run away on long agent sessions if WebSocket hibernation isn't used or model calls aren't gated. Build cost guardrails early.
Gotcha: Memory growth — agents that accumulate state forever fill up DO storage. Implement retention / summarization strategy.
Where to find it in the dashboard
Compute (Workers) → Workers & Pages → [Worker] → Settings → Bindings
  • Agent bindings — agents are bound to Workers like Durable Objects. Same binding pattern.
  • Logs / Observability — agent execution traces under the parent Worker.
Agents don't have a dedicated dashboard section — they're built on Durable Objects and surfaced under the parent Worker's settings.
What
Managed RAG-as-a-service. Point AI Search at your content (R2 bucket, website, list of URLs), it auto-indexes everything, gives you a search API and a chat API that pulls from your content.
Why
Building RAG by hand means chunking documents, generating embeddings, managing a vector database, writing retrieval logic, and gluing it to an LLM. AI Search is that whole pipeline as a single product. You give it data, you get back search + chat. Was previously known as AutoRAG.
Say"AI Search is the easy button for RAG. You know how every company wants a chatbot that knows their docs, their internal wiki, their support tickets? Doing it yourself means chunking the documents, embedding them with a model, storing the vectors, writing retrieval logic, picking an LLM, and gluing the pieces together. It's a lot. AI Search does all of that for you. Point it at an R2 bucket, a list of URLs, or your website. It crawls, chunks, embeds, indexes, and exposes a search API and a chat API. You write a query, you get answers grounded in your content with citations. It handles re-indexing as your content changes. Under the hood it's Vectorize plus Workers AI plus a managed pipeline. Customers go from 'we should build a chatbot for our docs' to a working prototype in a few hours."
Customer Scenario The setup:A property management SaaS has 8 years of help docs, internal SOPs, and procedural runbooks scattered across Notion, an old Zendesk knowledge base, and a folder of PDF training materials. Their support team takes 6 minutes on average to answer a tier-1 question. The pain:The CEO wanted a "Slack bot that knows everything we know." Their data team spent two months building a custom RAG pipeline with LangChain + Pinecone + GPT-4. It worked, sort of, but quality was inconsistent, the data team didn't have time to maintain it, and re-indexing broke every time someone updated a Notion doc. What they built:Exported Notion and Zendesk to R2 as Markdown. Dumped the PDFs in alongside. Pointed AI Search at the R2 bucket. Hooked the AI Search chat API into a Slack bot via a small Worker. Total project: about 3 days for one engineer. The outcome:Tier-1 ticket time dropped from 6 minutes to under 90 seconds. Re-indexing is automatic when files change in R2. The data team got back the two months they'd been spending on the LangChain pipeline. Pinecone got cancelled.
Objection: "We need full control over the RAG pipeline""Then Vectorize + Workers AI is your move — build chunking, embedding, retrieval, ranking yourself with the primitives. AI Search is opinionated on purpose: it's for teams that want RAG without designing the pipeline. Common pattern is start with AI Search, graduate to custom Vectorize-based pipeline once you hit limitations."
Objection: "What about hybrid search (keyword + vector)?""AI Search is moving toward hybrid — Cloudflare has signaled this as a roadmap priority. Today it's primarily vector-based. If hybrid is mandatory now, use Vectorize + a full-text engine (D1 FTS5 or external) to compose yourself."
Deep Dive — AI Search
How it actually works
  • Data source: Point at R2 bucket (for indexed documents), website URLs (auto-crawled), or upload via API. AI Search ingests, processes, indexes.
  • Auto-chunking: Documents split into semantic chunks (typically 512-1024 tokens) at logical boundaries.
  • Auto-embedding: Chunks embedded with default model (BGE family). Stored in managed Vectorize index.
  • Search API: Send a query, get top-K matching chunks with scores and source metadata.
  • Chat API: Send a query, AI Search retrieves chunks, feeds to LLM, returns answer with citations. End-to-end RAG in one API call.
  • Re-indexing: Triggered on R2 bucket changes (event notifications) or scheduled crawls (websites). Stale content updated automatically.
  • Tunable knobs: Pick LLM model (Workers AI options, or BYO via AI Gateway). Configure chunk size, similarity threshold, citation format.
  • Multiple sources: One AI Search instance can ingest from multiple sources — your R2 bucket of PDFs plus your help center website plus an external URL list.
Anticipated customer questions
"What was AutoRAG?"AutoRAG was the original product name. Renamed to AI Search to reflect that it does both search and chat, not just RAG. Same product, same docs, same pipeline.
"What file formats does it index?"PDF, markdown, HTML, plain text, common doc formats. For sites, it follows links and crawls.
"How fast is indexing?"Initial indexing of a large corpus (thousands of docs) takes minutes to hours depending on size. Incremental indexing on R2 changes is near-real-time.
"Can users see the source documents the answer was drawn from?"Yes — chat API returns citations with source URLs / R2 keys. Common UI pattern: show answer plus 'Sources' panel with links.
"Pricing?"Per-query for chat/search calls plus storage for indexed content. Free tier on Workers Paid. Verify current pricing with account team — actively evolving.
"Multi-tenant support?"Yes — create separate AI Search instances per tenant, or use metadata filtering within a single instance to scope by tenant. Multi-tenant pattern is well supported.
"What models can I use for generation?"Workers AI models out of the box. External models (OpenAI, Anthropic) via AI Gateway. Easy to swap.
"How does it compare to building with LangChain + Pinecone?"Comparable end state, fraction of the code. LangChain + Pinecone gives more control over each pipeline stage. AI Search trades that control for speed-to-prototype. Pick AI Search for first iteration; graduate to custom pipeline if you outgrow it.
"Can I customize the system prompt for chat?"Yes — configure the prompt template, citation behavior, refusal policy ('I don't know based on my sources'), tone.
Industry angles
SaaS
In-product help, docs chat, customer support automation. Point at help center + R2 bucket of internal docs.
Internal tools
Wiki / Confluence chatbots, HR Q&A, policy lookup. Ingest internal docs from R2.
Customer support
First-line bot answering from help center + knowledge base. Escalate to human when confidence low.
Sales / Marketing
Sales enablement chatbots over case studies, product docs, competitive intel. Ingest from R2 or Sharepoint sync.
Education
Course content Q&A, textbook chat, study assistants over curated corpora.
Pricing: Per-query pricing for chat/search + storage for indexed content. Workers Paid plan required. Free tier available for prototyping. Verify exact rates with account team.
Gotcha: Quality depends on chunking strategy and source content cleanliness. Garbage in, garbage out. Spend time curating the source corpus.
Gotcha: Refusal behavior must be tuned. Without it, AI Search may hallucinate answers when sources don't cover the question.
Gotcha: Re-indexing has lag — large content changes take time to propagate. Plan for it in customer-facing UI.
Gotcha: Citation accuracy depends on retrieval quality. Verify citations actually support claims — LLMs sometimes invent details not in retrieved chunks.
Gotcha: No fine-grained access control out of box. If different users should see different content, segment by metadata or use separate instances.
Where to find it in the dashboard
AI → AI Search
  • Instances list — AI Search instances. Create new, view sources, check indexing status.
  • [Instance] → Sources — R2 buckets, URLs, manual uploads. Add/remove, force re-index.
  • [Instance] → Settings — model choice, system prompt, chunk size, citation format.
  • [Instance] → Playground — test queries in dashboard before integrating.
  • [Instance] → Metrics — query volume, latency, top queries, indexing job status.

Browser Rendering

What
Headless Chromium as a service. Call a browser from a Worker — render pages, take screenshots, generate PDFs, scrape content, automate tests. Also called "Browser Run" in newer dashboards.
Why
Running headless Chrome at scale is painful — memory-hungry, fragile, hard to spin up fast, easy to abuse. Browser Rendering productizes it as a Workers binding so you don't operate any of it.
Say"Browser Rendering is headless Chromium that you call from a Worker. Why does that matter? Because tons of things only work if you can spin up a real browser — screenshots of webpages, PDF generation from HTML, web scraping that needs JavaScript to execute, end-to-end testing, social media preview images, AI agents that need to click buttons on websites. The traditional way to do this is run a Puppeteer or Playwright instance on AWS — which means an EC2 box that's always running, fighting with Chromium memory leaks, dealing with security issues, scaling it manually when load spikes. Browser Rendering is the managed version. You call it from a Worker like any other binding, you get a browser session for a few seconds, you do what you need to do, you let it go. We handle the scaling, the security, the memory. Especially hot right now with AI agents — when somebody asks an AI to 'go book me a flight' or 'screenshot this dashboard every morning,' the AI needs a real browser to do it. Browser Rendering is that browser."
Customer Scenario The setup:A marketing SaaS company sells social media scheduling. Part of the product generates auto-cropped preview images of every link a customer schedules — like Twitter card previews, but custom-branded. The pain:They run Puppeteer on 8 always-on EC2 instances to handle the screenshot load. The instances crash a few times a week from Chromium memory leaks, on-call gets paged, screenshots back up in the queue. Big customers scheduling 10K posts at once cause hour-long delays. What they built:They replaced the EC2 Puppeteer fleet with Browser Rendering called from a Worker. The Worker accepts a URL, calls Browser Rendering to grab a screenshot, applies brand styling via a Worker, writes the final image to R2, returns the URL. No persistent infrastructure — every screenshot is its own ephemeral browser session. The outcome:They killed all 8 EC2 instances. Queue delays vanished — concurrent throughput scaled with traffic instead of being capped by box count. Total monthly bill dropped by roughly 60%, and the on-call rotation finally stopped getting paged about Chromium.
Objection: "We're using Browserless / Browserbase / our own Puppeteer""Browserless and Browserbase are real competitors — they're specialist managed Chrome services and they're good. Browser Rendering wins on integration: if you're already on Cloudflare, you call it from a Worker as a binding, no separate API key, no separate vendor relationship, no separate egress. The egress story alone is meaningful — moving the screenshot from the browser to your storage doesn't leave Cloudflare, so no transfer fees."
Objection: "Can it handle complex sites with auth / SPAs?""Yes — it's real Chromium, not a stripped-down renderer. JavaScript executes, cookies work, you can set headers and inject scripts, navigate multi-step flows, fill forms. Same Puppeteer / Playwright API patterns you're used to. Anti-bot detection on some target sites can still trip headless browsers — that's a problem with the target, not the renderer."
Objection: "Can't this be abused for scraping at scale?""Yes, that's why pricing is metered and rate-limited per account. Cloudflare is also the company that runs Bot Management, so we're aware of the dual-use problem and have controls. Legitimate use cases — your own previews, your own testing, AI agents — work fine. Aggressive scraping of third-party sites gets caught."
Deep Dive — Browser Rendering
How it actually works
  • Worker binding: Bind BROWSER in wrangler.toml. Call puppeteer.launch(env.BROWSER) from inside a Worker. Standard Puppeteer or Playwright APIs work.
  • Session-based: Each call spins up a fresh Chromium session at the edge. You get a few seconds of session time per call (configurable up to longer limits).
  • REST API: Also available as a REST API for use outside Workers (mobile backends, external apps).
  • What you can do: Navigate URLs, screenshot pages (full page or selectors), generate PDFs, extract text/HTML, execute JS in the page, intercept network requests, fill forms, click elements.
  • Pairs naturally with: Workers (orchestration), R2 (store screenshots/PDFs), Workers AI (analyze rendered content), Queues (batch jobs), Workflows (multi-step browser automation).
  • Concurrency: Multiple sessions in parallel per account. Higher concurrency available on Enterprise.
  • Network: Browser sessions run on Cloudflare's network, so they're fast to fetch from Cloudflare-hosted origins or third-party sites.
Anticipated customer questions
"What's the pricing?"Per browser session, with a free tier for prototyping. Enterprise contracts include committed concurrency. Concrete numbers in the docs — generally cheaper than running your own Chromium fleet on EC2, especially when you factor in operational cost.
"Puppeteer or Playwright?"Puppeteer is first-class. Playwright is supported via the same underlying browser. Most existing automation code ports with minimal changes.
"Can sessions persist state?"Sessions are ephemeral by default. For workflows that need cookies/auth state across calls, store state in KV or D1 and rehydrate at session start. Or use a longer-running session for multi-step workflows.
"What about AI agents using this?"Major use case. Pair with Workers AI or external LLMs — the AI decides what to click, Browser Rendering executes. The Agents framework integrates well with this pattern. "Computer use" style agents (Claude, GPT-4) often use Browser Rendering as the eyes and hands.
"PDFs from HTML?"Built-in. Pass HTML or a URL, get a PDF back. Common use case for invoices, reports, contracts — anything that's HTML-templated and needs to be rendered to PDF.
"Can we automate logged-in sites?"Yes — pass cookies or auth headers when launching the session. Standard browser automation patterns.
"Geographic targeting?"Sessions run on Cloudflare's edge — by default, near the calling Worker. For specific geo targeting (test the site as a French user), you can configure session location on Enterprise.
Industry angles
AI / Agents
The "eyes and hands" for autonomous agents. Computer-use models from Anthropic / OpenAI need a browser to act on websites. Browser Rendering is that browser.
Marketing / SaaS
Auto-generated preview images, social cards, screenshot dashboards. Replace fragile Puppeteer fleets with a binding.
Ecommerce
Product page screenshots for catalogs, automated visual diffs, generating share images for marketplace listings.
Fintech
PDF generation for statements, tax docs, contracts. HTML in, PDF out, archive to R2.
Developer tools
End-to-end testing as a service. Visual regression tests. CI integrations that render and diff every PR.
Media / Publishing
Server-side rendered social previews, automated screenshot of latest articles for newsletters, archiving rendered page snapshots.
Pricing notes: Free tier for prototyping. Paid tier on session count + concurrency. Enterprise contracts include committed concurrency. Egress to R2 / Workers / other Cloudflare services is free, which adds up if you're storing lots of screenshots.
Gotcha: Chromium is heavy. Each session has real memory/CPU footprint. The benefit isn't "free Chrome" — it's "you don't operate Chrome." Budget per-session cost when planning high volumes.
Gotcha: Some sites actively block headless browsers regardless of how they're hosted. Browser Rendering can be detected as headless. If you're scraping sites that have aggressive bot protection, that's a constant cat-and-mouse — not specific to Cloudflare.
Gotcha: Session time limits exist. Long-running browser automations (15+ min) need to break into multiple sessions with state passed between them.
Where to find it in the dashboard
Compute → Browser Run
Listed as "Browser Run" in newer dashboards, "Browser Rendering" in docs. Same product.
  • Overview — usage metrics, session count, error rate.
  • Settings — concurrency limits, feature flags.
  • Logs — session logs via Workers Observability.

AI Gateway All Plans

What
A proxy that sits between your app and any AI provider — adds observability, caching, rate limits, retries, fallbacks, and cost analytics.
Why
AI usage gets messy fast — costs spike, latency varies, providers go down, prompts get duplicated. AI Gateway is the single control plane for all of that.
Works with
OpenAI, Anthropic, Google Gemini, Workers AI, Replicate, Mistral, Groq, Cohere, AWS Bedrock, Azure OpenAI, Hugging Face, and more. One line of code per provider.
Clarification: the name "gateway" is misleadingThe word makes it sound like a critical chokepoint that everything depends on. It isn't. AI Gateway is a side car, not a load-bearing wall. Better mental model: think of it as the dashcam in a car — the car drives perfectly fine without it, but when something interesting happens you're glad it was recording.

If a customer disabled AI Gateway tomorrow:
• Their site still loads, their AI features still work, the responses stay identical
• Latency basically unchanged (a few milliseconds either way)
• No cost change — AI Gateway is free
What they'd lose: logs of every prompt and response, real-time analytics, caching for repeated prompts, and the control point for adding rate limits or fallback routing later

The honest framing: "AI Gateway adds visibility and control to your AI calls. It's not required infrastructure — it's like adding observability to anything else. The reason it's worth turning on is the same reason you turn on logging: when something goes wrong, you'll want the data."
Say"AI Gateway is basically a smart proxy that sits between your application and whatever AI you're calling — OpenAI, Anthropic, Workers AI, doesn't matter. The reason this exists is that the moment you start using AI in production, you immediately run into the same set of problems. You don't know what your prompts cost, you can't see what users are actually asking, the same prompt gets re-computed a hundred times when it could've been cached, one provider goes down and your whole feature breaks, and somebody figures out how to spam your free tier into oblivion. AI Gateway solves all of that with one line of code. You get a full log of every prompt and response, real-time analytics on cost and latency, caching for repeated prompts, rate limits to stop abuse, and automatic fallback to a backup provider if the primary fails. And it's free on all plans. Most customers turn it on once and never look back."
Customer Scenario The setup:A legal-tech startup uses GPT-4 and Claude to summarize contracts for their customers. Hundreds of customers, multiple prompts per contract, costs running about $25K/month across both providers. The pain:They had no idea which customers were driving spend, which prompts were expensive, or why their bill jumped one month. When OpenAI had a 3-hour outage in March, their product was down — Claude was up, but they had no way to fail over without a code deploy. And they suspected many customers were uploading similar contracts that got summarized identically, but couldn't prove it. What they built:They added AI Gateway in front of both providers — one line of code change per call (swap the base URL). Turned on caching for identical prompts. Configured automatic fallback from OpenAI to Claude. Set per-customer rate limits to catch abuse. The outcome:Caching alone cut spend ~30% (customers really were uploading near-identical contracts). They survived the next provider outage with zero impact. They built a per-customer cost dashboard from AI Gateway logs and turned it into a paid feature.
Objection: "We already log AI calls in our app""You can roll your own observability, sure, but you're maintaining infrastructure to do what should be ambient. AI Gateway gives you a real-time dashboard, exportable logs, cost analytics, and provider failover without writing a line of telemetry code."
Objection: "We don't want to add a network hop""AI Gateway runs at the edge on the same network as your Workers, so the added latency is minimal. And if you turn on caching, repeated prompts come back faster than they would from the provider directly — usually a net latency improvement."
Objection: "Why not just use the provider's dashboard?""Provider dashboards show you their data, formatted their way. If you're using more than one provider — and most production AI apps end up there — you need unified observability. Plus their dashboards don't give you fallback routing or shared caching across providers."
Deep Dive — AI Gateway
How it actually works
  • Proxy model: Your app makes its normal AI request, but instead of pointing at api.openai.com directly, you point at your AI Gateway URL. Gateway forwards the request to the provider, returns the response, and logs everything in between.
  • One line of code change: For most providers, you swap the base URL. For Workers AI specifically (via the Workers binding), you add a gateway: { id: "..." } parameter to the existing env.AI.run(...) call.
  • Caching: Identical prompts return cached responses instantly. Cache TTL is configurable per request. You can also force-skip cache when needed. Cache hits cost nothing and return in milliseconds.
  • Rate limiting: Per-gateway request caps. Useful for cost control and abuse protection.
  • Real-time logs: Every prompt, response, tokens consumed, latency, status code. Filterable and exportable.
  • Analytics: Request volume, token consumption, cost estimates, error rates, latency distributions — across all providers in one view.
  • Request retry: If a request fails (rate limit, server error, timeout), Gateway retries automatically based on rules you define.
  • Fallback / dynamic routing: Define ordered fallback chains. "Try OpenAI first; if it fails or takes too long, fall back to Anthropic; if that fails, fall back to Workers AI Llama." Builds AI resilience without app code changes.
  • Custom metadata: Attach tags to each request (user ID, app name, environment) for slicing analytics later.
  • Logs as evaluation data: Export logs to use as training data, fine-tuning inputs, or evaluation sets for testing prompt changes.
  • WebSocket support: Streams supported for chat-style applications.
Anticipated customer questions
"How much does it cost?"Free on all plans for the basic feature set (analytics, logging, caching, rate limits, retries, fallback). Premium features may roll out at usage-based pricing — Cloudflare publishes this clearly when relevant.
"What providers does it work with?"OpenAI, Anthropic, Google Gemini (Vertex AI), Workers AI, Replicate, Mistral, Groq, Cohere, AWS Bedrock, Azure OpenAI, Hugging Face, and more being added regularly. Plus a universal endpoint for any HTTP-based AI API.
"Does it leak my API keys to Cloudflare?"No. Your provider API keys travel through Gateway encrypted and Cloudflare doesn't store them. Gateway sees the request/response payload (which is what enables analytics and caching) but credentials pass through as headers.
"What about latency overhead?"Minimal — Gateway runs at the edge, typically adds a few milliseconds. With caching enabled, cache hits actually return faster than going direct to the provider.
"How does caching work for AI?"Gateway hashes the prompt. Identical prompts within the cache TTL return the cached response. Configurable per request — useful for stable answers (summarization, classification) and skip-cache for stochastic generation.
"Can we use it without Workers AI?"Yes. AI Gateway works with any AI provider whether or not you use Workers AI. Lots of customers use OpenAI through Gateway and never touch Workers AI.
"How does fallback handle stateful conversations?"Fallback routes per-request. For chat-style flows where context matters, your app handles passing conversation history into whichever provider gets the request. Gateway doesn't manage conversation state itself.
"What's the difference between AI Gateway and Workers AI?"Workers AI runs the AI inference itself (on our GPUs). AI Gateway is the observability/control layer in front of any AI inference, including Workers AI. Different products, often used together.
"Can we export logs to our SIEM / data warehouse?"Yes — logs are accessible via API and can be exported. Useful for compliance, prompt evaluation, training data curation.
"How do we test prompt changes safely?"Use AI Gateway logs as your evaluation dataset. Replay historical prompts against a new model or new system prompt, compare outputs. Pattern is well-established now.
Industry angles
Fintech
Cost control on document analysis and customer support automation. Audit logs for regulators showing what AI was prompted with and what it said.
Healthcare
Log retention for compliance (HIPAA scope when on Workers AI). Centralized observability across multiple clinical AI tools.
SaaS
Per-customer rate limiting on AI features (free tier = 100 requests/day, paid = 10k). Cost attribution per customer via metadata.
Ecommerce
Cache product description generation, semantic search responses. Fallback so AI features don't break customer experience.
Media
Cost analytics across content generation tools. Logs for prompt optimization and quality monitoring.
Gaming
Per-player rate limits on AI chat / NPC dialogue. Fallback across providers for uptime in multiplayer scenarios.
Pricing notes: Core AI Gateway features (analytics, logs, caching, rate limiting, retries, fallback) are free on all plans. There are no per-request fees for the gateway itself — you only pay your AI provider's normal costs. Additional premium features may have usage-based pricing as they're rolled out.
Gotcha: Caching can produce stale or inappropriate responses if you cache user-personalized prompts. Use cache only for deterministic prompts (classification, summarization of fixed content) and skip-cache for personalized generation.
Gotcha: Logs include the full prompt and response by default. If users submit PII or sensitive data, those payloads sit in your logs. Consider scrubbing inputs before they hit AI Gateway, or use the logs-disabled mode for sensitive workloads.
Gotcha: Rate limits apply per gateway, not per user. For per-user limits, attach user ID as custom metadata and enforce in your application layer, or use multiple gateways for tier-based segmentation.
Gotcha: Fallback to a different provider means the response format may differ slightly. Make sure your app handles response shape variation between providers.
Gotcha: Workers AI binding integration requires the gateway ID in your code. If you change gateway IDs (e.g., move from dev to prod), you redeploy the Worker.
Where to find it in the dashboard
AI → AI Gateway
AI Gateway is account-scoped. Find it under the AI section in the left nav.
  • Gateways list — all your gateways. Create one per project, environment, or use case.
  • [Gateway] → Analytics — request volumes, cache hit rates, token counts, costs, latency over time.
  • [Gateway] → Logs — every prompt and response, filterable by status, model, time, custom metadata.
  • [Gateway] → Settings → Caching — default cache TTL, per-request overrides.
  • [Gateway] → Settings → Rate Limiting — request caps per gateway.
  • [Gateway] → Settings → Authentication — gateway-level auth (require token to call your gateway).
  • [Gateway] → Settings → Logs — toggle log capture, retention settings, custom metadata.
  • [Gateway] → Evaluations — replay historical prompts against new models / configs for testing.
  • [Gateway] → Dynamic Routing — fallback chains, retry rules.

D1 (Serverless SQL) Free tier + Paid

What
Serverless SQLite databases that live on Cloudflare's network. Query directly from Workers, no connection pooling, no servers to manage.
Why
Traditional databases require provisioning, connection pooling, and a region. D1 gives you SQL without any of that — create a database with one command, query it from any Worker, scale automatically.
Say"D1 is Cloudflare's serverless SQL database. Think SQLite — same SQL dialect, same simplicity — but distributed across our network. You create a database with one command, bind it to your Worker, and query it like any other database. The big difference from Postgres or MySQL is there's no connection management, no instance to size, no region to pick. It scales automatically and you pay per query and storage, not for an always-on instance. Most customers use D1 for app data — users, sessions, settings, posts, comments — anywhere SQLite would fit. It pairs naturally with Workers because there's no network hop between code and database. For workloads that outgrow SQLite (heavy analytics, complex joins across millions of rows), customers usually keep D1 for the simple stuff and use Hyperdrive to connect to Postgres for the complex stuff."
Customer Scenario The setup:An indie SaaS team of 3 is building a new feature — per-customer settings, audit logs, and saved searches. ~30K active customers, small per-customer data. The pain:Their main app already uses RDS Postgres in us-east-1. Adding a new schema and a new connection pool felt like overkill for what was essentially three small tables. The whole feature would've cost them ~$200/month in additional RDS capacity, and Workers had to round-trip to AWS for every query. What they built:Spun up a D1 database for just the new feature. Three tables, bound to the Worker. Queries happen at the edge with no network hop to AWS. Existing Postgres untouched. The outcome:Feature shipped in days instead of weeks. Cost on D1: well under the free tier. Query latency: a few ms instead of 80-100ms. They didn't migrate the main app — they just used D1 where it fit and kept Postgres for the rest.
Objection: "SQLite isn't a real production database""SQLite is the most-deployed database on Earth — it's in every iPhone, Android device, browser, and most desktop apps. The 'not production' reputation came from single-file-on-one-server limitations, which D1 solves by running SQLite as a managed service with replication and backup. For OLTP workloads under tens of millions of rows it's plenty. For analytics or very large datasets, pair with R2 + Data Catalog or use Hyperdrive to Postgres."
Objection: "We already have Postgres / MySQL""Then D1 isn't replacing your primary database — Hyperdrive is the better fit there. D1 shines for new apps or new microservices where you want a database without provisioning. Common pattern: D1 for new edge-native services, existing Postgres/MySQL via Hyperdrive for legacy workloads."
Deep Dive — D1
How it actually works
  • SQLite under the hood: Standard SQLite SQL dialect. Most SQLite-compatible queries and tools work unchanged.
  • Distributed reads: Primary database lives in one region, read replicas distributed globally. Reads served from nearest replica, writes go to primary.
  • Workers binding: Bind a D1 database to a Worker via wrangler.toml. Query with env.DB.prepare("SELECT ...").bind(...).all().
  • Migrations: Migration files stored alongside Worker code. wrangler d1 migrations create and apply for schema changes.
  • Backups: Automatic Time Travel — restore to any point in last 30 days. No manual snapshot management.
  • REST API: Query D1 via REST API from outside Workers if needed (mobile apps, external integrations).
  • Local development: Wrangler runs a local SQLite instance for dev with full schema parity.
  • Read replication: Currently in development for global read replicas. Today writes go to primary region; reads can be edge-cached.
Anticipated customer questions
"What size workloads is D1 good for?"Sweet spot is OLTP up to ~10GB per database. Apps with hundreds of thousands of users, social/content/SaaS app data, multi-tenant config. Above that or for complex analytics, look at Postgres + Hyperdrive or R2 Data Catalog.
"What's the SQL dialect?"Standard SQLite — JOINs, transactions, triggers, indexes, JSON functions, full-text search via FTS5. No stored procedures, no native arrays (use JSON instead). Migration from Postgres / MySQL usually straightforward for app workloads, harder for complex analytics.
"How does pricing work?"Free tier: 5M reads/day, 100k writes/day, 5GB storage. Paid: $0.001/1000 reads, $1/1M writes, $0.75/GB-month storage. No per-instance cost — pay only for usage.
"Latency vs Postgres?"From Workers: D1 reads typically faster (no network round-trip outside Cloudflare). From external clients via REST API: comparable. For write-heavy or complex queries, Postgres + Hyperdrive may outperform.
"Multiple databases per Worker?"Yes — bind as many D1 databases as you need. Useful for multi-tenant apps (database per tenant) or service separation.
"What about transactions?"ACID transactions supported. Use db.batch([statements]) for atomic multi-statement transactions.
"Backup and restore?"Time Travel restores to any point in last 30 days. Export to SQL dump for cold backup. Cross-account migration via wrangler d1 export/import.
"How does it compare to PlanetScale / Supabase / Neon?"PlanetScale: MySQL, mature, more analytics-capable. Supabase / Neon: Postgres-based, more features (RLS, real-time, edge functions). D1: simpler model, tighter Workers integration, no separate auth layer. Pick D1 when you're already building on Workers; pick the others if Postgres dialect or features are required.
Industry angles
SaaS
Multi-tenant config, user accounts, session storage, app data. Database-per-tenant pattern works well at small scale.
AI / Agent backends
Storing conversation history, agent state, prompt logs alongside Workers AI inference.
Internal tools
Admin dashboards, audit logs, internal CRUD apps where Postgres feels overkill.
Edge-native apps
Comment systems, voting, lightweight forums, configuration backends.
Pricing notes: Free: 5M reads/day, 100k writes/day, 5GB storage. Paid (with Workers Paid): $0.001/1000 reads, $1/1M writes, $0.75/GB-month. Compare to RDS / Aurora where you pay per-instance per-hour whether idle or not.
Gotcha: SQLite dialect — no native arrays (JSON only), no stored procedures, limited window functions vs Postgres. Validate query compatibility before migration.
Gotcha: 10GB practical per-database limit today. For multi-tenant apps with shared schema this can be hit; consider database-per-tenant or sharding.
Gotcha: Writes go to primary region. Global write-heavy workloads have geographic write latency.
Gotcha: Not a drop-in replacement for an existing Postgres / MySQL DB with stored procs, custom extensions, or complex analytics. Pair with Hyperdrive for those.
Where to find it in the dashboard
Storage & Databases → D1 SQL Database
  • Databases list — all D1 databases in the account.
  • [Database name] → Tables — schema browser, table data viewer.
  • [Database name] → Console — run ad-hoc SQL queries against the database.
  • [Database name] → Settings — Time Travel restore, deletion protection, location.
  • [Database name] → Metrics — read/write volume, storage, query latency.

KV (Key-Value Store) Free tier + Paid

What
Global key-value store. Read-heavy, eventually consistent. Optimized for caching, config, and lookup tables that don't change often.
Why
Workers need fast access to small data — feature flags, user preferences, API keys, redirects, A/B test assignments. KV gives you single-digit ms reads from anywhere on the planet without operating Redis or DynamoDB.
Say"KV is Cloudflare's globally distributed key-value store. Think of it like a giant dictionary stored at all 330 of our data centers — your Worker can look up a value by key in single-digit milliseconds from anywhere. It's read-optimized and eventually consistent, meaning writes propagate globally within about 60 seconds. So it's perfect for things that get read constantly and written rarely — feature flags, config, redirects, A/B test buckets, session lookups, edge caching. Not the right tool for transactional data or anything where you need a write to be immediately visible globally. For that you want Durable Objects or D1."
Customer Scenario The setup:A media company manages ~40,000 short-link redirects (campaign URLs, vanity links) plus a few hundred feature flags. They used to do redirects via a small Node service backed by Redis. The pain:The redirect service was the most painful thing they ran. Two servers, a Redis cluster, monitoring, deploys. It also lived in one region — international users paid 200ms+ for a redirect that should be instant. And it broke once a quarter at 3am. What they built:Loaded every redirect into KV (key = short slug, value = destination URL). A 30-line Worker reads the slug, looks up KV, returns a 302. Feature flags moved to KV too. They killed the Node service and the Redis cluster. The outcome:Redirects now resolve in single-digit ms anywhere in the world. Zero infrastructure to operate. Cost dropped from ~$400/month (servers + Redis) to under $20/month on KV. On-call rotation lost its most-paged service.
Objection: "We just use Redis""Redis is great if you have it. KV is what you reach for when you don't want to run Redis — no instance to size, no replication to configure, no failover to handle. Reads are ~5ms anywhere globally. Writes propagate in ~60 seconds. For your typical edge-cache / config / lookup workload, KV removes a whole category of operational work. For sub-second-write workloads or pub/sub, stick with Redis or use Durable Objects."
Deep Dive — KV
How it actually works
  • Eventual consistency: Writes propagate to all 330+ PoPs within ~60 seconds. Reads are served from local cache (fast) or origin (slower, fresher). Trades consistency for speed.
  • Key/value types: Keys are strings up to 512 bytes. Values up to 25 MiB — store JSON, text, binary blobs, anything.
  • Metadata: Each key can carry small metadata (up to 1024 bytes) — returned with list operations without fetching the full value.
  • List with prefix: List keys by prefix — enables pagination and namespacing.
  • TTL / expiration: Auto-expire keys after N seconds or at a specific timestamp. Useful for sessions, cache entries, rate limit windows.
  • Bulk writes: Bulk write up to 10,000 key/value pairs in a single API call.
  • Workers binding: Bind KV namespace to Worker. Read: env.MY_KV.get(key). Write: env.MY_KV.put(key, value, { expirationTtl }).
  • Edge caching: Reads cached at the requesting PoP for ~60s — repeated reads are sub-millisecond.
Anticipated customer questions
"How is KV different from D1?"KV: key-value, eventually consistent, optimized for reads. D1: SQL, ACID, for relational data and queries. Use KV for lookup tables and cache; use D1 when you need joins, transactions, or complex queries.
"How is KV different from Durable Objects?"KV: globally replicated, eventually consistent, read-optimized. Durable Objects: single-instance, strongly consistent, writes-optimized for coordinated state. Use KV for config; use DO for chat rooms, game lobbies, multiplayer state.
"Why is it eventually consistent?"The tradeoff for global low-latency reads. Writing to 330+ locations strongly-consistently would take 50-500ms. KV writes return immediately and propagate in ~60s. Most edge workloads don't need stronger guarantees.
"What's the latency?"Cached reads: under 1ms. Cold reads from edge cache miss: 30-60ms. Writes: ~50ms to return success; 60s to be globally visible.
"Pricing?"Free tier: 100k reads/day, 1k writes/day, 1k deletes/day, 1GB storage. Paid: $0.50/M reads, $5/M writes, $0.50/GB-month. Reads are dramatically cheaper than writes.
"What about hot keys?"Hot reads (same key many times) benefit from edge cache — practically free. Hot writes (same key updated frequently) hit the propagation system harder — consider Durable Objects instead.
"Can I query by value or non-key attributes?"No — KV is strict key-value. List by key prefix only. If you need queries, that's D1.
"Encryption?"Values encrypted at rest. TLS in transit. Per-namespace access via API tokens.
Industry angles
SaaS
Feature flags, per-tenant config, A/B test assignments, session storage, API key validation.
Ecommerce
Product config, inventory levels (eventually consistent ok), coupon validation, geo-redirect rules.
Content / Media
URL redirects, content gates, regional content variants.
AI
Prompt cache, embedding cache, model config, API rate limit counters.
Pricing: Free: 100k reads/day, 1k writes/day, 1GB storage. Paid: $0.50/M reads, $5/M writes, $0.50/GB-month. Reads cheap, writes expensive — pick the right tool for write-heavy workloads.
Gotcha: Eventually consistent. Don't use KV when a write must be immediately visible everywhere (use Durable Objects).
Gotcha: Single-key write throughput limited (~1 write/sec sustained per key to same key). For hot keys, use Durable Objects.
Gotcha: List operations are paginated (1000 keys/page). Listing millions of keys is slow and expensive.
Gotcha: Value size limit 25 MiB. For larger blobs, use R2.
Where to find it in the dashboard
Storage & Databases → KV
  • Namespaces list — all KV namespaces. Create new, view IDs (used in wrangler.toml).
  • [Namespace] → Keys — browse keys, view/edit values, set TTL.
  • [Namespace] → Bulk Import — upload key/value pairs as JSON.
  • [Namespace] → Metrics — read/write volume, storage.

Durable Objects

What
Single-instance, strongly-consistent stateful Workers. Each Object is a tiny coordinated server with its own storage.
Why
Some problems need a single source of truth — chat rooms, game lobbies, real-time collaboration, leaderboards, queues. Traditional approaches require Redis or a database with row locks. Durable Objects give you a single coordinated instance per logical thing (per chat room, per user, per game) with built-in storage.
Say"Durable Objects are how you build real-time coordinated apps on Cloudflare. Think of each Durable Object as a tiny private server that exists for one specific thing — one chat room, one game lobby, one collaborative document. It has its own storage, its own WebSocket connections, and it's the single source of truth for that thing. When two users edit the same Google Doc-style document, both connect to the same Durable Object, which serializes the edits. When 100 players join a multiplayer game lobby, the lobby is one Durable Object holding all the state. Cloudflare runs the Object on whichever data center is closest to the activity, migrates it as users move, and handles all the messy infrastructure. It's the missing piece for building real-time apps without setting up Redis + WebSocket servers + a coordinated database."
Customer Scenario The setup:A DTC sneaker brand does limited drops every Friday — 500 pairs, sold out in under a minute, customers globally hitting the same product page at the same second. The pain:Last three drops they oversold. Customers in different regions both clicked "buy" on the last pair simultaneously, the inventory database was eventually-consistent, both orders went through, and customer service had to manually email apologies. Brand damage on every drop. What they built:One Durable Object per SKU acts as the inventory counter. Every "add to cart" hits the DO with an atomic check-and-decrement — if the count is at zero, the request returns sold-out. A WebSocket connection from the product page broadcasts "SOLD OUT" to every viewer the instant the last pair goes. About 80 lines of Worker code total. The outcome:Zero overselling across the last six drops. The real-time sold-out indicator actually became part of the brand — customers screenshot the moment it flips and post it on social. Customer service complaint volume dropped to zero on drop days.
Objection: "Sounds complicated. We use Redis pub/sub.""Redis works, but you're operating it — sizing, sharding, failover, geo-replication. Durable Objects give you the same coordination primitive without the ops. Plus each Object has its own storage built in, so you don't need Redis + a separate database for persistence. Hardest part is the mental model shift — once developers get it, they wonder how they ever built real-time without it."
Deep Dive — Durable Objects
How it actually works
  • One Object per ID: Each Durable Object has a globally unique ID. All requests with the same ID hit the same Object instance, anywhere in the world. Two requests can never be in different Objects.
  • Single-threaded: Each Object processes requests one at a time — no race conditions, no locks needed. Massive throughput per Object isn't the goal; correctness is.
  • Built-in storage: Each Object has its own private SQLite database. Read/write directly with this.state.storage. Transactionally consistent within the Object.
  • WebSocket hibernation: Long-lived WebSocket connections can hibernate (not consume Worker time when idle) and wake on incoming events. Critical for cost on real-time apps.
  • Geographic locality: Object instantiated in the data center where it's first accessed. Migrates over time to where its users are. No manual region picking.
  • Naming patterns: Common patterns — Object per user (user state), per room (chat/game), per document (collaboration), per resource (rate limit counter).
  • Alarms: Schedule a callback on the Object to fire later (after seconds, minutes, hours). Replaces cron for per-Object timers.
  • Counterpart to Workers: A Worker handles a request, decides which Object to forward to (based on URL or auth), and forwards via env.MY_DO.get(id).
Anticipated customer questions
"Use case examples?"Chat rooms (one DO per room), multiplayer game lobbies (one per lobby), collaborative editing (one per doc), live polls / quizzes (one per session), per-user rate limiting at scale, leaderboards, order matching engines, lightweight pub/sub channels.
"How is this different from KV or D1?"KV: globally replicated, eventually consistent, no per-key write throughput. D1: SQL, eventually-consistent reads across replicas. Durable Objects: single instance per ID, strongly consistent, coordinated writes. Use DO when you need a single coordinator for a logical thing.
"What about throughput per Object?"Tens of thousands of requests/sec per Object is achievable. Per-Object is the unit of scale — for higher throughput, partition into more Objects (e.g. shard by user ID).
"Geographic latency?"Object location auto-migrates toward usage. Users in the same region as the Object see ~10ms; cross-region users see whatever the round-trip is. For globally-distributed users on the same Object (chat room with users worldwide), some users will be farther — that's inherent to single-coordinator architectures.
"Pricing?"Workers Paid required. $0.15/M requests + $12.50/M GB-sec duration + storage costs. WebSocket connections that hibernate consume minimal duration cost. Storage: $0.20/GB-month + $1/M write operations + $0.20/M read operations.
"WebSocket cost concerns?"Pre-hibernation: WebSocket connections billed for duration regardless of activity (expensive for idle connections). Post-hibernation: idle connections cost minimal duration. Always use WebSocket hibernation API for real-time apps with idle periods.
"What's the storage limit per Object?"Up to 10 GB per Object today. For larger per-tenant storage, partition into multiple Objects or use D1 alongside.
"Can two Objects coordinate?"Yes — Objects can call other Objects via the standard Workers RPC pattern. Common for fan-out (broadcast to multiple rooms) or hierarchical state (game world with sub-zone Objects).
Industry angles
Gaming
Game lobbies, matchmaking, real-time state, leaderboards. Each lobby / match is one Object. Hibernation makes idle lobbies cheap.
SaaS / Productivity
Real-time collaboration (docs, spreadsheets, whiteboards). One Object per document. Built-in WebSocket coordination.
Fintech
Per-account rate limits, transaction queuing, order matching. Strong consistency matters here.
AI / Agents
Agent state, conversation memory, multi-step workflow coordination. One Object per agent session.
Ecommerce
Cart state, inventory counters (strongly consistent), flash sale coordination.
How to demo Durable Objects (and bridge to each vertical)
The classic DO demo: a shared counterThe cleanest way to demo Durable Objects is a live shared counter. One page, one URL, one number. Every visitor connects via WebSocket to the same DO. Anyone clicks "+1" and the count updates for everyone in real time, across browsers, across continents, no refresh.

Why it works: it strips the pattern to one variable. The audience sees ALL the magic in 30 seconds — strong consistency, real-time broadcast, persistent state — without getting lost in "what is this app doing." About 140 lines of JS total to build. Worth the half-day investment if you demo DOs more than once or twice.

The demo script: "Pull up this URL on your phone. Click +1. Watch the number jump on my screen. Now I click +1. Watch it jump on yours. Everyone on this page is connected to one Durable Object — every click goes to that object, gets processed in order, broadcasts back to everyone." Then pivot to the customer's vertical with one of the bridges below.
This page is also a Durable Object demoLook at the top-right corner of this page. The "viewing now" badge with the green pulsing dot — that's a real Durable Object running right now. Every SE who opens this cheat sheet connects via WebSocket to a single Presence DO. The number you see is live state from that object. The "total visits" counter is persisted in the same DO's SQLite storage.

So if you want to point to a working DO without writing any new code: this cheat sheet's own badge is one. Open the page in two tabs, watch the count change. Same primitive customers buy DOs for — just protecting this internal SE tool instead of a game lobby or order book.

A shared counter IS the same pattern as every vertical above — stripped to one variable so the mechanism is visible. The bridge from "counter" to "the customer's use case" is what closes deals. Here's the one-liner for each:

Gaming
Bridge: "What you just saw is exactly how a multiplayer game lobby works. Each room is one Durable Object. Players connect via WebSocket, the lobby coordinates state, every change broadcasts. The counter has one piece of state — a real lobby has player IDs, ready states, map vote, chat. Same primitive, more fields."
SaaS / Productivity
Bridge: "This is what's behind Google Docs cursors, Figma multiplayer, Notion's real-time mode. Each document is a Durable Object. Every keystroke and cursor move broadcasts to everyone connected. The counter is one shared value — a doc is the same pattern with thousands of fields."
Fintech
Bridge: "Watch what happens when two people click +1 at the same millisecond — the count goes to 2, never back to 1. The Durable Object processed both clicks in serial order. No race condition, no double-spend. That's the exact guarantee fintech needs for order matching, transaction queuing, and per-account rate limits. The mechanic that keeps the counter correct keeps a stock exchange from filling the same order twice."
AI / Agents
Bridge: "Agents need state — what did the user say, what tool did I call, how many tokens have I spent. That state has to survive between requests and stay coordinated. Each agent session is one Durable Object. The counter is the simplest possible agent state — one number. A real agent has conversation history, tool logs, partial state. Same primitive."
Ecommerce
Bridge: "This is the pattern for flash-sale inventory. Start at 100 units. Every checkout decrements the counter. When it hits zero, no more purchases go through. Because the Durable Object processes every decrement in order, you can't oversell even if 10,000 people click Buy at the same millisecond. The counter goes up; theirs would go down. Same mechanic."
Universal one-liner (for any vertical)"A shared counter is the Durable Objects pattern with the noise stripped away. Everything customers actually build — lobbies, docs, order books, agents, inventory — is this exact mechanic with more fields. The reason you show a counter first is so the customer can see what the underlying primitive does. Then you talk about their specific use case."
Pricing: Workers Paid plan required. $0.15/M requests + duration ($12.50/M GB-sec). Storage: $0.20/GB-month + operation fees. WebSocket hibernation dramatically reduces cost for real-time apps with idle periods.
Gotcha: Each Object is single-threaded. Per-Object throughput has a ceiling — partition heavy workloads across multiple Objects.
Gotcha: WebSocket hibernation API is mandatory for cost control. Without it, idle connections rack up duration charges.
Gotcha: Object cold-start (first request that instantiates the Object) adds a few hundred ms. For latency-sensitive workloads, keep Objects warm with periodic alarms.
Gotcha: Globally-distributed users on the same Object see asymmetric latency. Design for this — e.g., regional Objects with periodic synchronization, not one global Object.
Gotcha: Mental model shift required for developers used to Redis pub/sub. Worth investing the learning curve early.
Where to find it in the dashboard
Compute (Workers) → Workers & Pages → [Worker] → Settings → Bindings → Durable Object Namespaces
  • Bindings — bind Durable Object classes to a Worker (configured in code, surfaced here).
  • [Worker] → Logs — view live logs including Object lifecycle events.
  • [Worker] → Observability — request volume, errors, duration per Worker.
Durable Objects don't have their own top-level dashboard section — they're managed as part of the Worker that defines their classes. View Object metrics under the Worker's analytics.

Queues

What
Reliable async message passing between Workers. Producers push messages, consumers pull and process — with retries, dead-letter queues, and zero egress fees.
Why
A lot of work shouldn't happen on the request path — sending welcome emails, processing uploads, calling slow third-party APIs, fanning out webhooks. Queues let you push that work off the hot path into background processing without operating SQS / RabbitMQ / Kafka yourself.
Say"Queues is Cloudflare's message queue. It's the missing piece for building event-driven apps on Workers. The pattern is — your Worker handles a request, does the part that needs to be fast (validate, write a record, return 200), and pushes the slow stuff to a queue. Then a separate consumer Worker pulls messages from the queue and processes them in the background. Sending emails, calling external APIs, generating thumbnails, reprocessing data — all great fits. Queues handles delivery, retries, dead-letter routing, batching. No infrastructure to set up. And zero egress means producers and consumers can be in different regions or even outside Cloudflare and you don't pay transfer fees. Most customers reach for Queues the first time they hit a 'this Worker is too slow because it's calling SendGrid synchronously' moment."
Customer Scenario The setup:An e-commerce platform sends ~200K transactional emails a day — order confirmations, shipping updates, password resets. The Worker handling orders called SendGrid synchronously. The pain:SendGrid was occasionally slow (300-800ms latency) and sometimes had hiccups. Customers saw their checkout spinner sit there waiting for the email API to return. During SendGrid's outage in March, checkouts started timing out entirely. What they built:Order Worker writes the order, pushes a message to Queues with the email details, returns 200 to the customer instantly. A separate consumer Worker pulls from the queue and calls SendGrid. Failed sends retry automatically with backoff. Permanent failures land in a dead-letter queue for manual review. The outcome:Checkout latency dropped — no more SendGrid round-trip on the critical path. The next SendGrid outage was invisible to customers; emails just queued up and got delivered when SendGrid came back. Dead-letter queue caught a handful of bad addresses they hadn't realized were failing.
Objection: "We use AWS SQS / RabbitMQ / Kafka""Different tools for different use cases. SQS: comparable simple queue, AWS-tied, egress fees on consumers outside AWS. RabbitMQ / Kafka: way more features (pub/sub, partitions, ordering guarantees, replay). Queues is closer to SQS — simple, durable, async — with Workers-native integration and zero egress. For complex event streaming (millions of events / sec, replay, multiple consumer groups), Kafka is still the answer. For typical webhook / background-job use cases, Queues is simpler."
Deep Dive — Queues
How it actually works
  • Producer Worker: Pushes messages with env.MY_QUEUE.send(message). Message can be any JSON-serializable payload up to 128 KB.
  • Consumer Worker: Bound to the queue with a queue() handler. Pulls batches of messages, processes them, ACKs success or NACKs for retry.
  • Batching: Consumer receives up to 100 messages per batch (configurable). Tunes between throughput (large batches) and latency (small batches).
  • Retries: Failed messages auto-retry with exponential backoff. Configure max retries before dead-letter routing.
  • Dead-letter queues: Messages exceeding retry limit go to a configured DLQ for inspection / manual replay.
  • Delivery semantics: At-least-once delivery — consumers must be idempotent. Order within a producer not guaranteed; order across producers definitely not.
  • HTTP push endpoint: Send messages to a queue via HTTP API from outside Workers (mobile apps, external services).
  • Pull consumer mode: Newer mode — external services pull from Queues via HTTP rather than Workers consuming. Useful for non-Worker consumers.
Anticipated customer questions
"What's a queue good for?"Background work — emails, webhooks, image processing, slow API calls. Decoupling — request path doesn't wait for downstream. Fan-out — one event triggers many handlers. Batch processing — collect events, process in batches. Retry-friendly work — anything that might fail and is safe to retry.
"What's the throughput?"Tens of thousands of messages per second per queue. For higher, partition across multiple queues.
"Pricing?"Workers Paid plan required. Per-operation pricing: $0.40/M operations. Each send + each delivery counts. Zero egress for messages.
"Ordering guarantees?"At-least-once delivery. Order within a single producer largely preserved but not guaranteed across the system. For strict ordering, use Durable Objects (single-threaded coordination).
"What's the message size limit?"128 KB per message. Larger payloads: store in R2, send R2 key in the queue message.
"How long do messages live?"Up to 14 days. After that, dropped. Tune retry policy to fit.
"Can I have multiple consumers on one queue?"Yes — Cloudflare distributes batches across consumer Workers. Scale out by running more consumer instances.
"Idempotency?"At-least-once means consumers may see duplicate messages. Build idempotent handlers — use message ID for dedupe, or design operations that are safe to re-run.
"vs SQS / RabbitMQ / Kafka?"SQS: comparable, AWS-tied, egress costs. RabbitMQ: more features (routing, exchanges, pub/sub) but ops burden. Kafka: event streaming at massive scale, replay, partitioning — different tier. Queues is simple, Workers-native, zero-egress.
Industry angles
SaaS
Background jobs — emails, webhooks, scheduled processing, integrations. Decouple slow third-party calls from request path.
Ecommerce
Order processing, inventory updates, post-purchase notifications, abandoned-cart workflows.
AI / Data pipelines
Async inference batching, ETL stages between Workers, fan-out to multiple downstreams.
Mobile backends
Push notifications, telemetry buffering, deferred work.
Pricing: Workers Paid plan required. $0.40/M operations (sends + deliveries). No egress fees.
Gotcha: At-least-once delivery means consumers must be idempotent. Design accordingly.
Gotcha: No strict ordering across producers. If order matters, use Durable Objects for serialization.
Gotcha: Message size 128 KB — for larger payloads, store body in R2 and queue a pointer.
Gotcha: Dead-letter queue is a separate queue you configure — without it, messages exceeding retry limit are dropped.
Gotcha: Consumer Worker errors retry the whole batch by default. Implement per-message ACK to avoid retrying successfully processed messages.
Where to find it in the dashboard
Compute (Workers) → Queues
  • Queues list — all queues in account.
  • [Queue] → Settings — batch size, max retries, dead-letter queue, consumer concurrency.
  • [Queue] → Messages — view backlog, dead-letter messages.
  • [Queue] → Metrics — throughput, backlog depth, error rate, processing latency.
  • Consumers — Workers consuming this queue (bound via wrangler.toml).

Workflows

What
Durable, multi-step execution for Workers. Each step is checkpointed — if anything fails, Workflows resumes from the last successful step, possibly hours or days later.
Why
Long-running business processes — onboarding sequences, refund flows, content pipelines, AI agent orchestration — need durability across crashes, restarts, and delays. Without Workflows, you'd build this on Durable Objects + Queues + alarms + your own state machine. Workflows is that pattern as a managed primitive.
Say"Workflows is how you build durable multi-step processes on Cloudflare. Think of any business process that takes more than a single request — onboarding a customer, processing a refund, generating a report, running an AI agent pipeline through multiple LLM calls. Each step might involve external APIs that could fail. Each step might need to wait — hours, days, weeks. Doing this with naive code means dealing with crashes losing state, retries duplicating work, and timeouts mid-flow. Workflows solves all that. You write each step as a function. Workflows checkpoints state between steps. If a step fails, it retries with backoff. If the whole thing crashes, it resumes from the last checkpoint. If a step says 'wait 24 hours,' Workflows actually pauses for 24 hours and resumes cleanly. It's like AWS Step Functions or Temporal, but native to Workers, with no separate infra to operate."
Customer Scenario The setup:A B2B SaaS has a customer onboarding flow with 9 steps spanning 5 days — provisioning, welcome emails on a drip schedule, KYC review, billing setup, calendar nudges for the kickoff call. The pain:The original implementation was a tangle of cron jobs, database state machines, and a homegrown retry table. When their worker process restarted, in-flight onboardings sometimes stalled silently. The on-call engineer occasionally had to manually advance customers through a stuck step. What they built:Rewrote the onboarding as a single Workflow. Each step is a function — provisioning, send welcome email, wait 24h, send day-2 email, wait for KYC webhook (could be minutes or days), etc. Workflows checkpoints state between every step. If anything crashes, it resumes from the last checkpoint. The "wait 24h" is literal — the workflow pauses, no polling cron needed. The outcome:The cron + state machine + retry table got deleted. Stuck onboardings dropped to zero — even when there were backend deploys mid-flow, Workflows resumed cleanly. The engineer who used to babysit it got that time back.
Objection: "We use Temporal / AWS Step Functions""Both real options. Temporal is feature-rich, polyglot, self-hosted or Temporal Cloud. Step Functions is AWS-native with rich service integrations. Workflows is the Cloudflare-native version — narrower feature set today but tighter integration with Workers, R2, D1, Workers AI, and zero infra to manage. If you're building on Workers anyway, Workflows removes a vendor. If you have heavy Step Functions or Temporal investment, no rush to migrate."
Objection: "How is this different from Queues + Durable Objects?""You could build Workflows-like behavior on Queues + DO + alarms. Many customers did before Workflows existed. Workflows packages the pattern: step decorators, automatic checkpointing, declarative sleep, built-in retry logic. Saves a few hundred lines of orchestration boilerplate. Use raw DO + Queues if you need custom orchestration; use Workflows for typical multi-step business processes."
Deep Dive — Workflows
How it actually works
  • Define steps: Each step is an async function — call APIs, write to DB, run inference, whatever. Steps wrapped with step.do(name, fn).
  • Automatic checkpointing: After each step completes, result is persisted. Failure mid-step retries with backoff. Failure after a step resumes from next step on restart.
  • Sleep / wait: step.sleep('24h') actually pauses the workflow — no compute consumed during wait. Resumes cleanly when time elapses.
  • Wait for events: step.waitForEvent('approval') pauses until external code sends matching event. Useful for human-in-loop flows.
  • Retries and backoff: Configure per-step retry policy — max attempts, backoff strategy, retryable error types.
  • Composability: Workflows can spawn other Workflows. Useful for fan-out patterns.
  • Observability: Each workflow instance has a unique ID. Dashboard shows step-by-step execution, status, retries, output.
  • Trigger sources: Worker request, Queue consumer, Cron trigger, manual API call. Anywhere you'd start an async process.
Anticipated customer questions
"Use case examples?"Customer onboarding (signup → email → verify → trial setup → success email after 7 days). Refund processing (request → approve → call payment provider → notify customer). AI pipelines (chunk doc → embed → classify → store with retry logic). Multi-stage uploads (receive → virus scan → transcode → notify). E-commerce post-purchase flows. Content moderation pipelines. Cron-triggered ETL jobs that need to be resumable.
"How long can a Workflow run?"Effectively unlimited. Sleeps can be hours, days, weeks. Workflows pause during sleep — no compute consumed.
"Pricing?"Workers Paid required. Pricing based on step executions and duration. Sleeps are free (no compute during wait). Verify current rates with account team.
"What if a step has a non-deterministic side effect (sending an email)?"Workflows guarantees each step result is checkpointed. If the step succeeds, it won't re-execute. If it fails mid-execution, the framework can retry — your step function should be idempotent or use a dedupe key. Standard durable-execution gotcha applies.
"Can workflows talk to each other?"Yes — parent workflow can spawn child workflows, wait for their completion, aggregate results. Or use Queues to pass events between independent workflows.
"How do I cancel a running workflow?"API call to cancel by instance ID. Or fire a cancellation event the workflow is waiting for.
"What about observability and debugging?"Dashboard shows each instance's step-by-step execution with timestamps, inputs, outputs, retries, errors. Logs from each step accessible. Replay-from-step for debugging.
"vs Temporal?"Temporal: more mature, polyglot SDKs, richer feature set (signals, queries, child workflow patterns, search attributes). Workflows: simpler, Workers-native, zero infra, tighter Cloudflare integration. Pick Temporal for complex orchestration at scale; pick Workflows when you're already on Workers.
"vs Step Functions?"Step Functions: AWS-native, JSON state-machine DSL, service integrations baked in. Workflows: TypeScript / JS code, integrated with Workers ecosystem, no DSL. Pick Step Functions for AWS-heavy stacks; pick Workflows for Workers-heavy stacks.
Industry angles
SaaS
Customer onboarding sequences, trial expiration flows, subscription lifecycle (provision → activate → renew → cancel).
Ecommerce
Order processing, return / refund flows, post-purchase email sequences, fraud review with human-in-loop.
Fintech
Loan applications, KYC pipelines, transaction settlement, scheduled compliance reports.
AI / Agents
Multi-step agent execution, content generation pipelines (research → draft → review → publish), training data pipelines.
Healthcare
Patient intake flows, lab result processing, appointment reminders with retry logic.
Pricing: Workers Paid required. Per-step-execution pricing plus duration. Sleeps are free (no compute consumed during wait). Storage of workflow state included. Verify exact pricing with account team.
Gotcha: Steps must be idempotent or use dedupe — at-least-once execution semantics apply.
Gotcha: Step inputs/outputs serialized and stored. Don't pass huge payloads between steps — store in R2, pass pointers.
Gotcha: Workflows is newer (released 2025). Feature set evolving. Lock-in: workflow definitions are Cloudflare-specific.
Gotcha: Long sleeps work but require careful design — what if the user cancels their subscription during a 30-day workflow? Build cancellation paths.
Gotcha: Each step is a separate execution. Cold-start applies to each — for tight latency requirements, batch steps together.
Where to find it in the dashboard
Compute (Workers) → Workflows
  • Workflows list — all workflow definitions deployed across Workers.
  • [Workflow] → Instances — running, completed, failed instances. Step-by-step execution traces.
  • [Workflow] → Metrics — execution counts, success rate, average duration, step latency.
  • [Workflow] → Logs — per-instance logs.
  • [Workflow Instance] → Timeline — visual step-by-step replay.

Containers

What
Run container workloads (Docker images) on Cloudflare's global network. Start fast, scale to zero, billed per second of active runtime. Pairs natively with Workers.
Why
Workers is great for stateless, fast, JS/Wasm workloads. But sometimes you need a Python ML model, a headless browser, a long-running process, or just an existing Docker image you don't want to rewrite. Containers fills that gap without sending you back to AWS Fargate.
Say"Containers is for when Workers isn't enough. Workers is amazing for stateless, fast, JavaScript or Wasm work — but it has real limits. 128MB memory. 30-second CPU per request. No filesystem. So if you have a Python machine learning model, or a Node app that's too big to fit, or some existing Docker image that runs your image processing pipeline, you're stuck. The old answer was 'go run it on AWS Fargate or Google Cloud Run.' The new answer is Containers. You give us a Docker image, we run it on the same global network as Workers, and you call it from a Worker like any other binding. It scales to zero when nobody is using it, scales out automatically under load, and you pay per second of runtime instead of per always-on instance. Most customers use it as the heavy-lifting backend behind their Workers — Workers handles the request, Containers handles the part that needs Python or 4GB of memory or a real OS."
Customer Scenario The setup:An AI startup building a coding-assistant product. Customers send code snippets, the product runs the code in a sandbox, returns the output. They host the sandbox runners on AWS Fargate today. The pain:Cold starts on Fargate are 15-30 seconds — way too slow when a user is waiting for code to execute. They've been paying for always-on warm pools, which is expensive and still doesn't fully cover global users. Latency from EU users routing back to us-east-1 is painful. What they built:They packaged their sandbox runtime as a Docker image and moved it to Cloudflare Containers. The frontend hits a Worker, the Worker spins up a Container instance close to the user, runs the customer's code with a strict resource limit, returns the output. Each execution is fully isolated — one container per request, killed after. The outcome:P50 cold start dropped from ~20 seconds to ~2 seconds. They eliminated the warm-pool spend entirely. EU users now hit a container in Frankfurt instead of routing across the Atlantic. Net infra cost roughly half of what Fargate was.
Objection: "We use Fargate / Cloud Run / Fly.io""All real options. Fargate is mature but cold starts hurt and you pick a region. Cloud Run is similar — fast, but Google-centric. Fly.io is the closest competitor — global, fast cold starts, container-native. Containers wins when you're already on Cloudflare for Workers/CDN/security and want one platform. The integration is the value — Worker calls Container like any other binding, no separate network setup, no separate IAM."
Objection: "Why not just use Workers?""Workers is the right answer for most things — but it has hard limits. If your workload needs more than 128MB memory, runs longer than 30 seconds, needs a filesystem, depends on native binaries (Python with C extensions, ffmpeg, Playwright, ML libraries), Workers won't run it. Containers is for that 10% of workloads where you need a real OS. Most customers use both — Workers for the request handling, Containers for the heavy lifting."
Objection: "Cold starts must be terrible""They're better than you'd expect — typically a few seconds rather than the 20-30 seconds you see on Fargate or Lambda containers. Cloudflare keeps container images warm at the edge and uses fast snapshotting. For latency-critical workloads you can keep a minimum number of instances always warm. For the rest, scale-to-zero saves real money."
Deep Dive — Containers
How it actually works
  • Container class binding: Define your container in Wrangler config. A Worker binds to it like any other resource — env.MY_CONTAINER.fetch(request) spins one up.
  • Docker image: Bring your own Dockerfile. Build locally, push to Cloudflare's registry. Standard OCI-compliant images.
  • Scale to zero: No active instances when no traffic. First request spins one up. Subsequent requests reuse warm instances until idle timeout.
  • Global placement: Cloudflare runs your container in the region closest to incoming traffic. No region selection — it just lands where it needs to.
  • Sizing: Configure CPU and memory per container. Currently supports up to several GB memory and multiple vCPU configurations.
  • Networking: Container can call out to the internet, other Workers, R2, D1, etc. Worker-to-container traffic stays on Cloudflare's network.
  • Storage: Containers are ephemeral by default. For persistent state, pair with R2 (object storage), D1 (SQL), or Durable Objects (coordination).
  • GPU support: GPU containers are rolling out — Cloudflare uses them under the hood for Workers AI. For most workloads you don't need GPU; for the ones that do, talk to your AM.
Anticipated customer questions
"What size workloads are a good fit?"Anything that needs more than Workers' 128MB / 30s CPU limits. Common: Python ML inference, headless browsers (Playwright/Puppeteer), media processing (ffmpeg), sandboxed code execution, legacy Node apps, anything with native dependencies.
"What's the pricing model?"Per second of active container runtime, plus memory and CPU allocation. Scales to zero when idle. Concrete numbers depend on your contract — talk to your AM for the latest. Generally competitive with Fargate, cheaper than always-on instances.
"How do I deploy?"Write a Dockerfile, run wrangler deploy. Cloudflare builds and pushes the image. No separate registry to manage, no Kubernetes config.
"Can it run GPUs?"GPU containers are available — same infrastructure that powers Workers AI. For most CPU workloads you don't need them. If you do need GPU, ask your AM about access.
"How does state work?"Containers are ephemeral by design — when one shuts down, the filesystem is gone. For persistent state, write to R2 (objects), D1 (SQL), or Durable Objects (coordinated state) from inside the container.
"Can a container talk to my origin / VPC?"Yes — outbound to the public internet works by default. For private network access (back to your AWS VPC or on-prem), use Cloudflare Tunnel or VPC (Beta) to give the container a path to your private resources.
"How do I observe a container?"Logs stream to Workers Observability. Metrics — CPU, memory, request count, errors — show up in the dashboard. Logpush works for containers too.
"Security model?"Each container instance is isolated at the kernel level. Same security boundary as any production container platform. SOC2, ISO27001. For sandboxing untrusted customer code, additional isolation can be configured.
Industry angles
AI / ML
Run Python inference models that don't fit Workers AI's catalog. Custom embedding models, fine-tuned models, vision pipelines. Pair with Workers AI for orchestration.
Media
Video/image processing with ffmpeg or ImageMagick. Containers handles the heavy work, R2 stores input and output, Workers orchestrates.
Developer tools
Sandboxed code execution — coding assistants, online IDEs, CI runners. Spin up a container per request, kill it after.
SaaS
Background processing jobs — PDF generation, report rendering, data exports. Worker enqueues, container processes, R2 stores the result.
Ecommerce
Image transformation pipelines beyond Cloudflare Images (custom watermarking, AI-driven product photo enhancement). Browser-rendering for screenshot-based product previews.
Pricing notes: Per-second runtime + memory + CPU allocation. Scales to zero. Talk to your AM for exact rates — pricing has been evolving as the product matures. Generally positioned as cheaper than Fargate or always-on instances, with the integration advantage of being on the same network as Workers and R2.
Gotcha: Containers is newer than Workers — feature surface and limits are still expanding. Check the docs for current memory ceilings and CPU configurations before quoting a customer.
Gotcha: Cold starts are faster than competitors but not zero. For latency-critical paths (under 100ms response budget), keep an instance warm or stay on Workers.
Gotcha: Egress to non-Cloudflare destinations from a container is billed like normal internet egress. If your container talks to AWS or an external API a lot, factor that in.
Gotcha: Existing Dockerfiles usually work, but anything that assumes a specific Linux distro version, systemd, or persistent disks needs adjustment. Test before promising.
Where to find it in the dashboard
Compute → Containers
Account-scoped. Sits next to Workers in the Compute section.
  • Containers list — all deployed container apps.
  • [Container] → Deployments — image versions, rollback to previous.
  • [Container] → Metrics — CPU, memory, request count, errors.
  • [Container] → Logs — stream logs via Workers Observability.
  • [Container] → Settings — image, sizing, environment variables, bindings to other Cloudflare resources.

Vectorize (Vector Database) Free tier + Paid

What
Globally distributed vector database for embeddings. Stores high-dimensional vectors and finds similar ones — the foundation of RAG and semantic search.
Why
AI apps need vector search — for RAG (Retrieval Augmented Generation), semantic search, recommendations, similarity matching. Traditional vector databases (Pinecone, Weaviate) require provisioning and live in one region. Vectorize is serverless, globally distributed, and integrates natively with Workers AI and AI Search.
Say"Vectorize is Cloudflare's vector database. If you're building anything with AI — a chatbot that knows your docs, semantic search, product recommendations — you need a vector database. Here's how it works: you take your content (docs, products, anything), convert each piece into an embedding (a list of ~1000 numbers that captures its meaning) using a model from Workers AI, and store those embeddings in Vectorize. When a user asks a question, you embed the question the same way, and Vectorize finds the most semantically similar items in milliseconds. That's how RAG works — find the relevant docs by meaning, not keyword, then feed them to an LLM as context. Vectorize is serverless — no instance to size, no region to pick, scales automatically. And because it's on Cloudflare's network, it's milliseconds from Workers AI inference. Most customers building AI features use Vectorize + Workers AI together."
Customer Scenario The setup:A B2B SaaS company has 8 years of support tickets, help articles, and internal runbooks — about 200K documents. They want to build an "ask anything" chatbot for their support team and customers. The pain:Their first attempt was Pinecone + LangChain + OpenAI. The Pinecone bill was $400/month for the prod index, they had to manage chunking and embedding generation themselves, and latency from their Workers to Pinecone (different region) was 200-300ms per query. The whole stack was four vendors deep. What they built:They moved the vector store to Vectorize. Embeddings are generated with Workers AI's BGE model (free at low volume, cheap at scale). The source documents live in R2. The Worker that handles chatbot queries embeds the question, queries Vectorize, retrieves matching docs, sends them to Claude via AI Gateway. Whole stack runs on Cloudflare. The outcome:Query latency dropped from ~300ms to ~40ms because Vectorize is on the same network as the Worker. Pinecone bill went away entirely. Two fewer vendor relationships. They added re-ranking with a BGE-reranker model on Workers AI and answer quality improved noticeably.
Objection: "We use Pinecone / Weaviate / pgvector""All real options. Pinecone is mature with great DX. Weaviate is more flexible. pgvector is great if you already have Postgres. Vectorize wins on: (1) zero infra — no instance sizing, (2) global distribution and edge proximity to Workers AI, (3) integrated billing and tooling with your Cloudflare stack, (4) free tier covers prototyping. If your AI workload lives on Cloudflare anyway, Vectorize removes a vendor."
Deep Dive — Vectorize
How it actually works
  • Index per use case: Create an index with a fixed dimension (e.g. 768 for BGE-base, 1536 for OpenAI ada-002) and a distance metric (cosine, euclidean, dot product).
  • Insert vectors: Upsert vectors with IDs, optional metadata (filterable), and the vector itself. Bulk upsert up to thousands per call.
  • Query: Provide a query vector, get top-K nearest matches with scores. Filter by metadata (e.g. only docs from tenant X, only items in category Y).
  • Embedding pipeline: Workers AI provides embedding models (BGE family — small/base/large, EN/multilingual). Generate embedding from text in Worker, store in Vectorize, query later. Same model on both ends.
  • Metadata indexing: Configure which metadata fields are indexed for filtering. Pre-filter narrows the vector search to a subset before similarity ranking.
  • Namespaces: Logical partitioning within an index — useful for multi-tenant (one namespace per tenant) without managing separate indexes.
  • Integration with AI Search: AI Search builds on top of Vectorize for managed RAG — point at an R2 bucket, get an automatic embed + index + query pipeline.
  • Workers binding: Bind Vectorize index to Worker. env.VECTORIZE_INDEX.query(vector, { topK, filter }).
Anticipated customer questions
"What's a vector / embedding for a non-AI person?"Imagine every piece of text gets converted into a point in a very high-dimensional space (hundreds or thousands of dimensions). Texts with similar meaning end up near each other. Vector search = 'find points near this point'. That's it.
"How big can the index be?"Up to 5M vectors per index today, with metadata. Higher limits on Enterprise. Multiple indexes per account.
"What dimensions are supported?"Up to 1536 dimensions today (sufficient for OpenAI ada-002, BGE-base, most common embedding models). Higher dimensions on roadmap.
"Query latency?"Single-digit to low-double-digit milliseconds for queries from Workers. Globally distributed reads. Index updates propagate in seconds.
"Pricing?"Free tier: 30M queried vector dimensions/month, 5M stored vector dimensions. Paid: $0.04 per million queried dimensions, $0.05 per 100M stored dimensions per month. (Dimensions = vectors × dimension count.)
"Hybrid search (vector + keyword)?"Pure vector today. For hybrid (BM25 + vector), combine with D1 full-text search or external full-text engine. AI Search is moving toward hybrid.
"Re-ranking?"Not built-in today. Re-rank Vectorize results with a re-ranker model (BGE-reranker on Workers AI) for higher quality if needed.
"Can I bring my own embeddings (not from Workers AI)?"Yes — vectors are just floats. Generate them anywhere (OpenAI, Cohere, your own model), store in Vectorize. The model just has to be consistent across insert and query.
Industry angles
SaaS / AI products
RAG chatbots over docs / knowledge bases. Customer support bots that know the product. Semantic search inside apps.
Ecommerce
Product recommendations ('customers also viewed'), visual search via image embeddings, semantic product discovery beyond exact keyword match.
Media / Content
Content recommendation, related article suggestions, plagiarism / duplication detection.
Legal / Compliance
Searching policy / contract corpora by meaning. Internal knowledge search.
Healthcare
Symptom / condition matching (with appropriate compliance), medical knowledge search.
Pricing: Free: 30M queried + 5M stored vector dimensions/month. Paid (Workers Paid): $0.04/M queried + $0.05/100M stored dimensions/month. Dimensions = vectors × dimension size, so a 5M-vector index of 768-dim vectors = 3.84B stored dimensions.
Gotcha: Embedding model consistency is critical. Insert with model A, query with model B → garbage results. Pin the embedding model version.
Gotcha: 5M vectors per index limit today — large corpora may need sharding or namespace partitioning.
Gotcha: Metadata filtering only on fields explicitly indexed at index creation time. Plan filterable fields upfront.
Gotcha: Embedding generation cost separate from Vectorize. Workers AI embeddings billed per token — large initial indexing of a big corpus has a real cost.
Where to find it in the dashboard
AI → Vectorize
  • Indexes list — all Vectorize indexes in the account.
  • [Index] → Overview — vector count, dimension config, metric type.
  • [Index] → Metadata indexes — manage which metadata fields are filterable.
  • [Index] → Metrics — query volume, insertion rate, latency.

Hyperdrive Free tier + Paid

What
Connection pooling and edge caching for existing Postgres and MySQL databases. Makes a regional database feel fast and globally accessible from Workers.
Why
Serverless code + traditional databases is a notoriously bad combo. Workers run on 330 PoPs; your Postgres lives in one region. Every Worker request opens a fresh connection (slow) and pays full network latency to the DB. Hyperdrive pools connections globally and caches read queries at the edge.
Say"Hyperdrive is what makes serverless code work with traditional databases. Here's the problem — Workers run everywhere globally, but your Postgres database lives in one region, say us-east-1. Every Worker request that needs the database has to open a connection (slow handshake), authenticate, run the query, then tear down. That's bad for Postgres (connection limits get hit fast) and bad for users (every request pays full latency to one region). Hyperdrive sits in between. It maintains a pool of long-lived connections to your database, so Workers reuse them instead of opening new ones. And it caches read queries at the edge globally — a SELECT that's been run recently anywhere serves instantly from cache. So your Postgres in Virginia feels fast from Tokyo. It supports Postgres and MySQL out of the box, works with any provider — AWS RDS, Neon, Supabase, your own VPS — and doesn't require code changes beyond swapping the connection string."
Customer Scenario The setup:A B2B SaaS company is migrating their frontend from Vercel to Workers, but their Postgres database (AWS RDS in us-east-1) has 8 years of schema, stored procedures, and team knowledge they're not migrating. The pain:First attempt at Workers + Postgres was a disaster. Every Worker invocation opened a new connection. RDS hit its connection limit within minutes during normal traffic. Latency from EU Workers to us-east-1 RDS was 90-120ms per query. They were about to give up and use PgBouncer + a VPN tunnel. What they built:Set up Hyperdrive pointed at RDS. Updated the Worker's database connection string to Hyperdrive's. No code changes beyond that. Hyperdrive pools connections, so RDS sees stable connection count regardless of Worker traffic. Read queries cache at the edge. The outcome:Connection limit issue gone. Average query latency from EU Workers dropped from ~100ms to ~15ms (cache) or ~40ms (cache miss, but pooled connection). Migration unblocked. RDS stays where it is, Workers got the speed they wanted.
Objection: "Why not just move to D1?""For new apps, D1 might be the right call. Hyperdrive is for customers who already have Postgres or MySQL and aren't going to migrate — too much app code, too many tools, too much team expertise. Hyperdrive meets them where they are. Common pattern: keep existing Postgres for legacy workloads via Hyperdrive, use D1 for new edge-native services."
Objection: "Connection pooling — like PgBouncer?""Same core idea, way bigger scope. PgBouncer pools in front of your DB in one location. Hyperdrive pools at Cloudflare's edge globally, so Workers anywhere reuse pooled connections. Plus read caching, plus zero infrastructure to run, plus integrated auth. PgBouncer still works fine — Hyperdrive is what you'd build if you wanted PgBouncer to be a managed service distributed globally."
Deep Dive — Hyperdrive
How it actually works
  • Configure once: Create a Hyperdrive config pointing at your Postgres or MySQL database. Hyperdrive stores connection string securely (encrypted credentials).
  • Bind to Worker: Bind the Hyperdrive config to a Worker. Worker uses standard Postgres / MySQL drivers (pg, mysql2, postgres.js, drizzle, prisma) — connection string points to Hyperdrive, not the database.
  • Connection pooling: Hyperdrive maintains long-lived connections to your DB. Workers reuse them — no fresh handshake per request.
  • Query caching: SELECT queries automatically cached at the edge by default (60s TTL, configurable). Cache invalidation on writes through the same Hyperdrive config.
  • Geographic acceleration: First query from each region pays full latency to database. Subsequent identical reads served from edge cache locally.
  • Postgres protocol passthrough: Hyperdrive speaks the Postgres / MySQL wire protocol. Works with any driver. No SDK lock-in.
  • TLS to origin: TLS connection between Hyperdrive and your DB. Supports custom CAs for managed providers with private CAs.
  • Database providers supported: Any PostgreSQL or MySQL — AWS RDS / Aurora, Google Cloud SQL, Azure Database, Neon, Supabase, PlanetScale, self-hosted, anything with public endpoint.
Anticipated customer questions
"What's the latency improvement?"First request from a region: same as direct connection (full RTT to DB). Subsequent requests: cached reads sub-10ms anywhere globally. Connection pool eliminates handshake overhead (~50-200ms saved per request). Real-world: 5-10x improvement for read-heavy workloads at distance from DB.
"Does it handle writes?"Yes — writes pass through to origin. Hyperdrive pooling reduces connection setup time for writes too. Write caching isn't a thing (it would break consistency).
"What about consistency?"Reads can be cached up to 60s by default. Apps that need strict read-after-write should disable caching or use very low TTLs. Most app workloads (timeline reads, lookups, list views) tolerate 60s staleness fine.
"How does it know not to cache writes?"Hyperdrive parses SQL — SELECT cached, INSERT/UPDATE/DELETE not. Stored procedures and complex CTEs default to passthrough unless explicitly cached.
"What about transactions?"Transactions passthrough to origin — connection pinned for transaction duration so all statements hit the same backend connection. Cache bypassed during transactions.
"Database in private VPC — does Hyperdrive work?"Yes — pair with Cloudflare Tunnel to expose private DB to Hyperdrive securely. Or use Workers VPC binding for private cloud connectivity. Most managed DBs (RDS, Cloud SQL) support public endpoint with IP allowlisting for Cloudflare ranges.
"Pricing?"Free tier on Workers Paid. Pricing currently included with Workers Paid for typical workloads. Verify with account team for high-volume usage.
"Compatible ORMs?"Drizzle, Prisma, Kysely, raw drivers (pg, mysql2, postgres.js). Most work unchanged with connection string swap.
Industry angles
SaaS
Existing Postgres apps wanting to expand globally. Workers in front, Hyperdrive caching reads, Postgres unchanged.
Ecommerce
Product catalog reads cached globally, order writes pass through. Read-heavy catalog pages dramatically faster worldwide.
Fintech
Legacy Postgres / MySQL with regulatory constraints (specific region). Hyperdrive accelerates reads globally without moving data.
Migration scenarios
Customer migrating from monolith to Workers — Hyperdrive lets them keep existing DB during migration, no DB rewrite required.
Pricing: Included with Workers Paid plan for typical workloads. High-volume use cases have their own pricing — verify with account team.
Gotcha: Cached reads can be up to 60s stale by default. Don't enable caching on tables where freshness matters (real-time balances, live inventory).
Gotcha: Connection pool size limited per Hyperdrive config. Very-high-concurrency workloads may need multiple Hyperdrive configs or a larger DB connection limit.
Gotcha: DB must be reachable from Cloudflare's network. Private VPC databases need Tunnel or Workers VPC binding.
Gotcha: DB credentials stored in Cloudflare. Some compliance regimes require careful review of secret storage — point to Cloudflare's encryption at rest and SOC 2 posture.
Gotcha: Postgres-specific features (LISTEN/NOTIFY, advisory locks) work but bypass caching by design.
Where to find it in the dashboard
Storage & Databases → Hyperdrive
  • Configs list — all Hyperdrive configs (one per database connection).
  • [Config] → Settings — connection details, cache TTL, max connections.
  • [Config] → Metrics — query volume, cache hit rate, latency.
  • Bindings live on the Worker — bind a Hyperdrive config to a Worker via wrangler.toml or dashboard.

VPC

What
Private network connectivity between Workers (and other Cloudflare compute) and your private origins — AWS VPCs, Azure VNETs, on-prem networks, anywhere your internal services live.
Why
Public-internet-only Workers limit what Cloudflare can do for an enterprise. Most real backends sit in private networks. VPC gives Workers a routable path into those networks without rebuilding everything.
Say"VPC is what unlocks the rest of your stack. Most enterprises have the front of their app on the public internet — which is where Cloudflare sits today — but the actual important stuff lives in private networks. Internal APIs in AWS VPCs, databases in Azure VNETs, legacy services on-prem behind firewalls. Today, if you want a Worker to talk to one of those, you either expose it to the public internet (bad), run a relay service somewhere (annoying), or use Cloudflare Tunnel as a workaround. VPC is the proper answer. It gives Workers a private path into your network — same security as if you were running inside your own VPC, with private IP routing, no traffic going over the public internet. Once that's wired up, you can move logic to the edge that used to require running servers inside your private network — auth, routing, transformation, caching. And you don't have to re-architect your private services to do it."
Customer Scenario The setup:A regional bank runs their customer-facing web app on AWS. Public web tier is behind Cloudflare, but everything sensitive — account services, transaction APIs, the core banking integration — sits in a private AWS VPC not reachable from the internet. The pain:They want to do JWT validation, fraud signal lookup, and per-request authorization at the edge — sub-10ms instead of round-tripping to the private VPC. Today every request hits the public load balancer, gets validated in the private VPC, then comes back. Latency is the cost of keeping things secure. What they built:They set up a VPC peering between Cloudflare and their AWS VPC. Workers at the edge can now query the internal auth and fraud services over a private path, same as if the Worker were running inside the VPC. No public IP exposed, no Tunnel sidecar to operate, no relay service. The outcome:Auth and fraud checks moved from ~120ms (round-trip to AWS) to ~8ms (edge to nearest Cloudflare PoP, private hop to AWS). Customer login flow felt instantly faster. The security team approved because nothing was exposed to the public internet that wasn't already.
Objection: "We already use Cloudflare Tunnel for this""Tunnel works and lots of customers do exactly that. The difference is operational — Tunnel requires running cloudflared agents on your side, managing connector instances, scaling them as traffic grows. VPC is the network-level version — a peering relationship, not an agent fleet. For high-volume traffic between Cloudflare and your VPC, VPC is cleaner. For lighter use or where you can't easily set up network peering, Tunnel still works."
Objection: "Doesn't this just turn Cloudflare into another network in our security perimeter?""Yes, and that's intentional. The point is to treat Cloudflare as a trusted private extension of your network — same way you treat an AWS region you've peered into. Standard network controls apply: routing tables, security groups, ACLs on your side, plus Zero Trust policies on the Cloudflare side. Nothing gets exposed publicly that wasn't already."
Objection: "It's Beta — we can't bet on Beta products""Fair. VPC is in Beta and the feature surface is expanding. Use cases I'd recommend today: pilot deployments, non-critical internal services, early integrations to evaluate the latency and operational story. For mission-critical production, set up alongside Tunnel as fallback until VPC graduates to GA. Talk to your AM about the roadmap and what's covered under support today."
Deep Dive — VPC
How it actually works
  • Network peering: Cloudflare establishes a private network connection to your AWS VPC, Azure VNET, GCP VPC, or on-prem network. Standard cloud peering primitives (transit gateway attachments, private interconnects, etc.).
  • Routing: Workers can address private IPs in your network. CIDR ranges configured per peering.
  • Workers integration: A Worker binding lets you make HTTP/TCP calls to private endpoints. Looks like a normal fetch from inside the Worker.
  • Zero Trust integration: Same network can be used for Access policies — authenticate users into private services via Cloudflare Access, route over the VPC peering.
  • No agents: Unlike Tunnel, no cloudflared instances to run. Network-level peering, not agent-based.
  • Cloud support: AWS first, Azure and GCP rolling out. On-prem via private interconnect or hybrid approach.
  • Tunnel still works: VPC isn't a replacement for Tunnel — both have their place. Tunnel for lighter use or where peering isn't possible; VPC for production-scale private connectivity.
Anticipated customer questions
"Pricing?"Enterprise-only SKU today. Talk to your AM for current pricing — typically committed-use with per-peering and data-transfer components.
"What clouds does it support?"AWS is first-class today. Azure and GCP are in active development. On-prem via private interconnect (Direct Connect / ExpressRoute / equivalent). Multi-cloud is a primary use case.
"How is this different from Magic WAN?"Magic WAN connects your offices and clouds together with Cloudflare as the SD-WAN. VPC is specifically about giving Workers (and other Cloudflare compute) a path into your private networks. Different problems, both relevant — some customers use both.
"What about latency?"Sub-10ms typical from a Cloudflare PoP to a peered VPC in the same region. Slower if your VPC is in a region far from where the Worker is running.
"Security posture?"Same as any cloud network peering. Cloudflare doesn't see traffic that isn't routed through it. Standard security groups, ACLs, and routing rules on your side apply. Zero Trust policies on Cloudflare side add identity-based controls.
"Why not just expose our backend to the public internet behind Cloudflare?"Security and compliance. Anything exposed publicly has to defend against public-internet attacks. Anything in a private VPC doesn't. VPC lets you keep backend services off the public internet while still using Cloudflare in front.
"What if our VPC is in a region with no Cloudflare PoP?"Cloudflare has 330+ locations — most regions are covered. Edge cases exist. Talk to your AM if you have an unusual geo footprint.
Industry angles
Financial services
Core banking integrations, fraud services, customer data — all in private VPCs by regulation. VPC lets you push logic to the edge without exposing those services publicly.
Healthcare
EHR / patient data systems are never on the public internet. VPC + Workers + BAA = HIPAA-compliant edge logic over patient data without compromising the perimeter.
Enterprise SaaS
Internal APIs, customer-tenant databases, billing systems — all private. VPC lets Workers act as an authenticated gateway into those services.
Government / Regulated
Strict data residency and exposure requirements. VPC enables edge logic without violating "no public internet exposure" mandates.
Manufacturing / IoT
Plant networks, OT systems, internal MES platforms. VPC gives Cloudflare a path into those networks for centralized policy enforcement and observability.
Pricing notes: Enterprise-only Beta. Custom contract — talk to your AM. Expect a per-peering subscription + data transfer component, similar to how other cloud network products price.
Gotcha: Beta status — feature surface, documentation, and support coverage are still evolving. Don't promise specifics without verifying current state with your AM.
Gotcha: Not every cloud / region is supported yet. Confirm coverage for the customer's specific cloud + region before quoting.
Gotcha: Setting up cloud peering requires coordination with the customer's network team — it's not a self-service "click a button" flow. Plan for a real implementation engagement.
Gotcha: Don't confuse "VPC" (this product) with the customer's own VPC — when you say "Cloudflare VPC," it's the connectivity product, not their AWS VPC. Easy to talk past each other.
Where to find it in the dashboard
Compute → VPC (Beta)
Visible only after the VPC Beta entitlement is enabled. Talk to your AM if a prospect should have access.
  • Peerings list — all active VPC peerings.
  • [Peering] → Status — connection health, routes, throughput.
  • [Peering] → Settings — CIDR ranges, routing tables, security policies.

Pages Free + Paid

What
Frontend hosting (React, Next.js, static sites). Git-integrated.
Includes
Auto SSL • global edge delivery • preview deploys per branch • Workers integration.
Say"Pages is a way to host your website without dealing with servers. You connect your code repository — GitHub or GitLab — and every time your team pushes new code, Pages automatically builds the site and deploys it across our entire global network. No configuring servers, no setting up deployment pipelines. Every branch and every pull request gets its own preview URL too, so your team can review changes before they go live. If you've heard of Vercel or Netlify, it's the same idea but with two big advantages — bandwidth is unlimited even on the free tier, so you don't get surprise bills when you go viral, and it's already integrated with all of Cloudflare's security and performance products. A lot of customers are moving over from Vercel just for the cost savings."
Customer Scenario The setup:A B2B SaaS startup hosts their marketing site, docs site, and customer-facing app on Vercel. ~3M monthly visitors total, mostly to docs (high bandwidth) and the marketing site (lots of preview deploys per PR). The pain:The Vercel bill hit $12K/month and kept climbing — mostly bandwidth overage and team seats. They also had two outages last year traced back to Vercel's underlying infrastructure, which their CTO was tired of explaining. What they built:They migrated all three sites to Pages over a long weekend. Git-connected deploys with PR previews kept the same workflow their team was used to. The marketing site uses Pages Functions for the contact form and newsletter signup, replacing a small Lambda. They were already on Cloudflare for DNS and WAF, so the migration didn't introduce a new vendor. The outcome:Monthly bill dropped from $12K to under $1K. No more bandwidth overage anxiety. Single vendor for DNS, CDN, security, and hosting. Team workflow stayed identical — same Git push, same preview URLs.
Objection: "We use Vercel/Netlify""Same concept — the advantage is it's already integrated with everything else on Cloudflare: Workers, WAF, DDoS, Analytics. No separate hosting + security vendors."
Deep Dive — Pages
How it actually works
  • Git integration: Connect GitHub/GitLab repo. Every push triggers build. Custom build commands and output directory.
  • Framework support: React, Vue, Svelte, Next.js, Nuxt, Astro, Remix, Angular, SvelteKit, Hugo, Jekyll, Eleventy. Auto-detected.
  • Functions: File-based Workers routing (/functions/api/users.js = /api/users). Full Workers runtime — KV, R2, D1, env vars, etc.
  • Preview deployments: Every PR/branch gets a unique URL. Shareable for review. Production = main branch.
  • Custom domains: Map your own domain with one click. Auto SSL.
  • Build env: Configurable Node version, env vars, build secrets. Build minutes counted; bandwidth unlimited.
  • Convergence with Workers: Pages and Workers are unifying — newer projects deploy as Workers with assets, exposing the full Workers feature set (cron triggers, queues, etc.).
Anticipated customer questions
"How is this different from Vercel?"Comparable DX. Differences: included in Cloudflare ecosystem (WAF, bots, R2, Workers all native), no per-seat pricing, no bandwidth surprises (unlimited free egress). Vercel has more polish on certain framework features; we're catching up rapidly.
"What about Next.js?"Supported via @cloudflare/next-on-pages or now natively via Workers. ISR, ISG, middleware, app router — all work.
"Build minute limits?"Free: 500 builds/month. Paid: 5,000 builds/month, plus concurrent builds.
"Bandwidth limits?"Unlimited on all tiers. Real differentiator vs Netlify/Vercel which charge for bandwidth overages.
"Can we use monorepos?"Yes — configure build command and output dir per Pages project. Multiple Pages projects from one repo.
"What about environment variables and secrets?"Plain env vars in dashboard, encrypted secrets via Wrangler. Separate per environment (production / preview).
"Rollback?"One-click rollback to any previous deployment. Each deployment is immutable.
"Access controls on previews?"Cloudflare Access in front of preview URLs — restrict to email domain or identity provider.
Industry angles
SaaS
Marketing site + docs site + app frontend all on Pages. Same DX as Vercel without per-seat costs.
Ecommerce
Headless commerce frontends (Shopify Hydrogen, BigCommerce). Edge SSR via Functions.
Media
Static site generation for content sites (Hugo, Astro). CDN built-in.
Fintech
Marketing + investor relations site. Pair with Access for private investor pages.
Pricing notes: Free tier: unlimited sites, 500 builds/month, 1 concurrent build, unlimited bandwidth. Paid (part of Workers Paid $5/mo): 5,000 builds/month, 5 concurrent builds. Enterprise: SSO, audit logs, higher limits, BAA.
Gotcha: Build env is Linux x64. Native deps that don't build for that platform fail. Most JS frameworks fine.
Gotcha: Pages is converging into Workers with Assets. For new projects, evaluate Workers + Assets path for more flexibility.
Gotcha: Next.js compatibility is good but not 100% feature-parity with Vercel. Verify ISR/Image Optimization patterns before migrating heavy Next.js apps.
Where to find it in the dashboard
Compute (Workers) → Workers & Pages
Pages lives in the same area as Workers — pick "Pages" when creating a new application.
  • Create application → Pages — connect Git repo (GitHub/GitLab) or direct upload.
  • [Pages project] → Deployments — production + preview deployments per branch. Rollback by clicking any past deployment.
  • [Pages project] → Custom domains — map your own domain. SSL auto-provisions.
  • [Pages project] → Settings → Builds & deployments — build command, output directory, branch settings.
  • [Pages project] → Settings → Environment variables — plain variables and encrypted secrets, separate per environment (production / preview).
  • [Pages project] → Settings → Functions — Workers bindings for Pages Functions (KV, R2, D1, etc.).
Note: Cloudflare is migrating Pages → Workers with Assets for new projects. Existing Pages keep working.

DNS Free (all plans)

What
Authoritative DNS hosting. Ranked #1 globally by DNSPerf — ~11ms average resolution time worldwide. Built-in DDoS protection, DNSSEC, CNAME flattening.
Why
DNS is the front door of the internet — every visit to a site starts with a DNS lookup. Slow or unreliable DNS = slow first byte and outage risk. Cloudflare DNS is free, the fastest, and runs on the same anycast network as everything else.
Say"Cloudflare DNS is authoritative DNS hosting — when somebody types your domain, our nameservers tell their browser where to go. It's been ranked the fastest DNS in the world by DNSPerf for years running, around 11 milliseconds globally. It's free on every plan, including unlimited queries and unlimited zones, and it comes with DDoS protection built in. There are a few things only Cloudflare does — CNAME flattening lets you use a CNAME at your apex domain, which is normally impossible per the DNS spec. DNSSEC is a one-click toggle. And if you're on Enterprise, you get options like Secondary DNS (where Cloudflare backs up another provider, or vice versa), Multi-Provider DNS for resilience, and Foundation DNS with custom nameserver branding. Honestly, almost every Cloudflare customer should be on Cloudflare DNS regardless of which paid plan they're on — DNS performance is identical across tiers, and it's free."
Customer Scenario The setup:A large enterprise — 4,000 domains across multiple business units — uses Route 53 for DNS. They've been an AWS shop forever. The pain:Route 53 charges per zone and per query. With 4,000 zones and high query volume, the bill was $42K/year. They also had two regional DNS outages in the last year and the network team wanted a multi-provider DNS strategy after the 2016 Dyn-style fear hit a board meeting. What they built:Set up Cloudflare as Secondary DNS for the critical zones first — Cloudflare backs up Route 53, both answer queries. Over six months, migrated the rest of the zones primary to Cloudflare. The really sensitive zones stayed on Multi-Provider DNS with both providers active. The outcome:DNS bill went to $0 (free regardless of volume). Multi-Provider DNS gave the network team resilience against any single provider outage. Query latency improved (DNSPerf ranks Cloudflare #1). The CFO approved a Cloudflare Enterprise contract partly funded by the Route 53 savings.
Objection: "We're happy with Route 53 / Google DNS / NS1""All real products. Route 53 is mature with great AWS integration but charges per zone and per query. NS1 has nice traffic steering features. Cloudflare DNS is competitive on features and faster on benchmarks — DNSPerf ranks it #1 globally. The bigger story is integration: Cloudflare DNS plus everything else on Cloudflare (CDN, WAF, Workers) is one platform. If you're already using Cloudflare for anything else, DNS is free and the integration is tighter."
Objection: "We need redundancy across DNS providers""Reasonable concern after the 2016 Dyn outage. Two options: Multi-Provider DNS (Enterprise) — multiple authoritative providers active simultaneously, all answering queries. Or Secondary DNS — Cloudflare as backup to another primary, or vice versa. Both keep you online if any single provider fails."
Deep Dive — DNS
How it actually works
  • Anycast nameservers: Same IP advertised from 330+ PoPs. User queries hit nearest PoP. Median resolution ~11ms globally.
  • DNSSEC: One-click toggle. Cloudflare signs your zone with NSEC3. Validating resolvers cryptographically verify responses haven't been tampered with.
  • CNAME flattening: DNS spec disallows CNAME at the zone apex (apex must be A/AAAA). Cloudflare invented CNAME flattening — you configure a CNAME at apex, Cloudflare resolves it to an A/AAAA at query time. Critical for SaaS scenarios (point apex at vendor-hosted endpoint).
  • Anycast IPv6: All zones get IPv6 by default. Toggle individual records.
  • Record types supported: A, AAAA, CNAME, MX, TXT, SRV, NS, CAA, PTR, SOA, TLSA, SSHFP, SVCB, HTTPS, URI, NAPTR, SMIMEA, CERT, DNSKEY, DS, LOC, more. Effectively all record types.
  • Bulk operations: Import zone file (BIND format). Export zone file. API for bulk creation. Terraform provider for IaC.
  • Email Routing: Free email forwarding without running a mail server — receive email at your domain, forward to existing inbox. Configured via DNS dashboard.
  • Free DNS Analytics: Query volume, top queried records, response codes, country distribution.
Enterprise DNS add-ons
  • Secondary DNS: Cloudflare as primary or secondary in a multi-vendor setup. Zone transfers via AXFR/IXFR. Critical for compliance regimes requiring multi-vendor DNS.
  • Multi-Provider DNS: Multiple authoritative providers active simultaneously (Cloudflare + Route 53 + NS1 etc.). Survives any single provider outage.
  • Foundation DNS: Custom branded nameservers (ns1.acmebrand.com), higher record limits, more granular SLAs.
  • DNS Firewall: Protect existing third-party authoritative DNS infrastructure (different from authoritative DNS hosting — this is a proxy in front of your own nameservers).
  • Internal DNS: Private DNS zones for Zero Trust environments. Resolution available to WARP clients only.
  • 100% DNS uptime SLA: Financial credits if Cloudflare DNS fails to resolve.
Anticipated customer questions
"Is it really free with no query limit?"Yes — unlimited queries, unlimited zones (within reasonable usage), up to 3,500 records per zone on Free plans, higher limits on paid plans. DNS performance and reliability identical across tiers — no premium DNS tier hidden.
"How fast is it really?"DNSPerf publishes ongoing benchmarks at dnsperf.com — Cloudflare consistently ranks #1 worldwide. Median ~11ms; sub-1ms in regions with PoP density.
"How long does DNS migration take?"Mechanics: 5-10 minutes to add zone and update records. Plus TTL-based propagation (existing TTL window — usually 24-48 hours but can be pre-lowered). Recommended: lower TTL to 300s a week before migration, switch nameservers, wait for propagation.
"What about CAA records?"Fully supported. Cloudflare's edge certs require letsencrypt.org or pki.goog in CAA — common gotcha for SSL issuance failures after migration.
"Can I keep my domain registered elsewhere?"Yes — DNS hosting and domain registration are separate. You can register with anyone (or move to Cloudflare Registrar which sells at cost) and just point nameservers at Cloudflare.
"Geo-based DNS routing?"Load Balancing handles geo-steering at the DNS level (Enterprise feature). Pure DNS routing without LB is not natively supported.
"DNS over HTTPS / DoH for our customers' privacy?"Cloudflare runs 1.1.1.1 as a public resolver with DoH/DoT support — that's the recursive resolver. Cloudflare's authoritative DNS responds to any client regardless of how they queried.
"DDoS protection on DNS queries?"Built in, unmetered, all plans. DNS-layer DDoS (query floods, amplification) absorbed by the same anycast network.
Industry angles
SaaS
Use CNAME flattening to point apex at SaaS provider endpoints. Free everywhere. Combines with Cloudflare for SaaS for end-customer custom domains.
Ecommerce
DNS performance directly impacts time-to-first-byte. Sub-12ms global resolution shaves visible time off page loads.
Fintech / Healthcare
DNSSEC for tamper detection. Audit logs. Multi-Provider DNS for compliance regimes requiring multi-vendor.
Multi-region orgs
Anycast means same DNS performance from anywhere. Foundation DNS for branded nameservers if needed.
Pricing: Free on all plans (including Free plan). Enterprise add-ons: Secondary DNS, Multi-Provider DNS, Foundation DNS, DNS Firewall priced separately.
Gotcha: Nameserver migration takes the full TTL window — lower TTLs a week before cutover to reduce propagation time.
Gotcha: CAA records can block Let's Encrypt — required when proxying customer apex domains through Cloudflare. Common issue with new customers.
Gotcha: CNAME flattening only at apex. Subdomain CNAMEs behave normally.
Gotcha: Wildcards (*.example.com) work but interact with subdomain-specific records — explicit records take precedence over wildcards.
Gotcha: Free plan limit of 3,500 records per zone — large customers (e.g. SaaS with many custom hostnames) need paid plans or Foundation DNS.
Gotcha: DNSSEC at registrar: enabling DNSSEC in Cloudflare requires adding DS record at the registrar. Cloudflare provides the DS values; some registrars don't support DNSSEC.
Where to find it in the dashboard
Per-zone [Domain] → DNS → Records
  • Records — add/edit/delete DNS records, proxy toggle (orange/grey cloud), TTL, comments.
  • Settings — DNSSEC, CNAME flattening behavior, zone-level options.
  • Email Routing — free email forwarding setup if domain hosts email.
  • Analytics — query volume, top records, country distribution.
Account Home → DNS
  • Foundation DNS configs — Enterprise custom branded nameservers.
  • DNS Firewall clusters — proxy in front of third-party authoritative DNS.
  • Multi-Provider DNS — configuration for multi-vendor setups.
Zero Trust DNS → Internal DNS
  • Internal DNS zones — private DNS resolution for WARP-connected clients only.

Registrar At-cost pricing

What
Domain registrar selling domains at wholesale cost. Cloudflare doesn't mark up registration or renewal — you pay what Cloudflare pays the TLD operator.
Why
Most registrars (GoDaddy, Namecheap, Google Domains) make money on markup, upsells, and lock-in. Cloudflare runs Registrar at cost to drive customers onto its DNS and broader platform. For customers already on Cloudflare, moving the domain saves money AND simplifies the stack.
Say"Cloudflare Registrar is where you buy and renew domains at cost. We don't mark them up. So a .com that's $11 wholesale costs you $11 — not the $15-25 GoDaddy charges, and definitely not the $50+ some registrars charge for renewal after a discounted first year. We don't sell upsells like privacy protection (it's free), email forwarding (also free via Email Routing), or 'premium DNS' (our DNS is already the fastest and free). What customers love most: the price doesn't change at renewal. A $11 domain stays $11. For customers managing hundreds or thousands of domains, the savings are meaningful — Cloudflare Registrar is the cheapest legitimate option for most TLDs."
Customer Scenario The setup:A digital marketing agency manages ~800 domains across their client portfolio. They've used GoDaddy for years because that's where the domains started. The pain:The GoDaddy bill was ~$22K/year. Worse, GoDaddy's upsells, dashboard interruptions, and constantly-changing privacy fees made bulk management painful. They had two incidents where a client's domain almost expired because the auto-renewal credit card was rejected and the notification email went to spam. What they built:Transferred all 800 domains to Cloudflare Registrar over a quarter. Wholesale-price renewals. Domains live alongside the rest of the Cloudflare stack (DNS, SSL, WAF) so there's one dashboard. The outcome:Annual domain bill dropped from $22K to about $10K — pure wholesale, no markup. WHOIS privacy free, no upsells. One dashboard for domains + DNS + everything else. The agency turned the savings into a margin line item without raising client fees.
Objection: "We're happy with our current registrar""Fair. Reasons people move: (1) cost — at-scale customers save thousands per year, (2) consolidation — domain, DNS, certs, everything on one platform, (3) no upsells / no expired-credit-card chaos, (4) WHOIS privacy free by default, (5) DNSSEC easy. Reasons people don't move: existing registrar has nicer UI for some workflow, ccTLDs that Cloudflare doesn't support yet, or domain locked due to recent transfer."
Objection: "What if Cloudflare changes pricing?""Cloudflare's commitment is at-cost — wholesale rate from the TLD plus ICANN fee, no markup. If wholesale rates change (which TLDs do raise periodically), customer renewal cost reflects that. Track record since launch: Cloudflare has held the at-cost commitment."
Deep Dive — Registrar
How it actually works
  • At-cost pricing: Each TLD has a wholesale registry fee + ICANN fee. Cloudflare charges that exact amount, no markup. Pricing table per TLD published on Cloudflare's site.
  • Move-in: Existing domain transfer from another registrar. Standard 60-day-from-creation rule applies. Auth code from current registrar. 5-7 day transfer window typical.
  • New registration: Search availability, buy directly through dashboard. Domain ready to use immediately on Cloudflare DNS.
  • Auto-renewal: On by default. Renewal pricing matches registration pricing (no first-year discount, then 3x renewal markup like GoDaddy).
  • WHOIS privacy: Free, on by default. Cloudflare contact info shown in public WHOIS; real details kept private.
  • Bulk operations: Manage hundreds of domains via API. Bulk transfer-in, bulk renewal, bulk DNS config via Terraform.
  • DNSSEC: One-click. Cloudflare handles DS record at the registry side automatically.
  • Account-level admin: User permissions for domain management. Audit log of changes.
Supported TLDs
  • Common TLDs: .com, .net, .org, .io, .co, .ai, .dev, .app, .xyz, .me, .info, .biz, and ~250 others.
  • ccTLDs supported: Many country codes (.uk, .ca, .de, .fr, .es, .it, .au, .nz, .jp, .br, etc.).
  • Not supported: Some ccTLDs with strict registrar agreements (.gov, .edu, some EU ccTLDs). Full list published on Cloudflare site.
  • Premium domains: Some premium TLDs / premium names have higher costs from the registry. Cloudflare passes those through at cost too.
Anticipated customer questions
"How does the move-in process work?"1. Unlock domain at current registrar. 2. Get auth/EPP code. 3. Initiate transfer at Cloudflare dashboard. 4. Pay 1-year renewal (added to existing expiration). 5. Approve transfer email (within 5 days). 6. Wait ~5-7 days for completion. Total downtime: zero (DNS continues working at current registrar until transfer completes).
"Can we have multiple users manage domains?"Yes — Cloudflare account-level roles. Admin / member roles, custom roles on Enterprise. Audit log of all registrar actions.
"What about API automation?"Full Registrar API and Terraform provider. Common pattern: register domains programmatically, configure DNS via Terraform, deploy in CI/CD.
"What if we want to leave?"Standard transfer-out works like any registrar. Get auth code from Cloudflare, initiate transfer at new registrar, approve. Cloudflare doesn't put up barriers.
"Does it work with Cloudflare for SaaS?"Different products. Registrar is where YOU buy YOUR domain. Cloudflare for SaaS is for your end customers to point THEIR domains at your platform. Sometimes used together (SaaS platform owns saas-product.com via Registrar, uses Cloudflare for SaaS for *.customer.com hostnames).
"Privacy protection?"Free, on by default for all supported TLDs. Cloudflare's contact info appears in public WHOIS. Real owner contact preserved for ICANN compliance but not publicly visible.
"Premium feature pricing?"No premium features. No upsells. No "registry lock + $X/year." Everything included in the at-cost price.
Industry angles
SaaS
Companies managing hundreds of brand / vanity domains for marketing, geo, or migrations save substantially.
Agency / Consulting
Manage domain portfolios for many clients — bulk operations + at-cost pricing makes economics work.
DevOps / SRE
Terraform-managed domain inventory. API-first registration for new environments / projects.
Brand protection
Buy adjacent / typo / international domains to protect brand. Cheap renewal cost matters at portfolio scale.
Pricing: At wholesale cost. Examples (verify current published rates): .com ~$10/yr, .net ~$11/yr, .org ~$10/yr, .io ~$28/yr, .ai ~$80/yr. ICANN fee ($0.18) included in displayed price.
Gotcha: Not every TLD is supported. Check Cloudflare's TLD list before assuming.
Gotcha: 60-day post-registration / post-transfer lock — standard ICANN rule, applies anywhere.
Gotcha: Domain must be on Cloudflare DNS to use Registrar. Can't register at Cloudflare and use third-party DNS.
Gotcha: Premium / aftermarket domain purchases not through Cloudflare. For existing premium names, use a broker, then transfer in after standard lock.
Gotcha: Bulk transfer of many domains at once requires support assist for very large portfolios — talk to AM if moving 100+ at a time.
Where to find it in the dashboard
Domain Registration
  • Register Domains — search availability, buy directly.
  • Manage Domains — portfolio view, renewal status, expiration dates, auto-renew settings.
  • Transfer Domains — initiate move-in from external registrar.
  • [Domain] → Settings — contact info, nameservers (locked to Cloudflare DNS), DNSSEC, privacy, transfer lock.

Email Routing Free

What
Free email forwarding for any domain on Cloudflare DNS. Receive mail at you@yourdomain.com, forward to any existing inbox. No mail server needed.
Why
Running your own mail server is operational pain — DNS records, SPF/DKIM/DMARC, blocklists, anti-spam, reputation management. Email Routing handles inbound forwarding so you don't have to run a mail server. Send through your existing Gmail / Outlook / whatever.
Say"Email Routing is free email forwarding. You own yourcompany.com, you want hello@yourcompany.com to land in your existing Gmail, you don't want to run a mail server. Email Routing does that. You set up routes in the dashboard — hello@yourcompany.com goes to your-personal@gmail.com, sales@yourcompany.com goes to your-team@yourcompany-google-workspace.com, anything-else@yourcompany.com goes to a catch-all. Cloudflare handles all the DNS records, spam filtering, and forwarding. It's read-only — you can't send email from Cloudflare, just receive and forward. For sending, customers usually pair with Google Workspace / Microsoft 365 / SendGrid / Cloudflare Email Service. The killer use case is small teams or side projects that want professional email on their domain without paying $6 a seat for Google Workspace per email address."
Customer Scenario The setup:A small consulting firm — 6 employees, each with their own Gmail. They want professional addresses like hello@firmname.com, billing@firmname.com, plus personalized ones like first.last@firmname.com. The pain:Google Workspace would be $36/month minimum for 6 seats. They don't need another inbox — they all already use their personal Gmail and don't want to manage two. They tried free MX-only providers but kept hitting spam-folder issues. What they built:Email Routing on Cloudflare. Set up first.last@firmname.com routes pointing at each person's existing Gmail. Plus a catch-all to the founder. Took 15 minutes total. They send replies from Gmail using "Send mail as" with SMTP through Google Workspace's free SMTP relay or a $0 sending service. The outcome:Professional addresses on their domain, all routed to existing inboxes. Saved $432/year on Google Workspace they didn't need. Spam folder issue gone because Cloudflare's reputation handles inbound filtering.
Objection: "Why not just use Google Workspace?""Workspace is great if you need a real mailbox per user with calendar, drive, etc. Email Routing is for when you don't need that — you just want addresses at your domain to land somewhere. For a small team where everyone already has a Gmail account, $0/month forwarding beats $6/user/month Workspace seats. They serve different jobs."
Objection: "Can we send email from Cloudflare?""Email Routing is receive-only — forward inbound mail. For outbound, use Cloudflare Email Service (transactional sending via API), Google Workspace, Microsoft 365, SendGrid, Postmark, Resend, etc. Workspace + Email Routing is a common combo — Workspace for mailboxes, Email Routing for distribution / aliases."
Deep Dive — Email Routing
How it actually works
  • Auto-configured DNS: Enable Email Routing on a zone, Cloudflare auto-adds MX records, SPF, DKIM signing for the domain.
  • Routing rules: Define address → destination mappings. Specific (sales@you.com → team@gmail.com), wildcard (*@you.com → catchall@gmail.com), suppression (block specific senders).
  • Destination verification: Forwarding destinations must verify ownership (one-time confirmation email). Prevents abuse.
  • Spam filtering: Cloudflare runs anti-spam before forwarding. Heavy spam dropped silently; suspected spam tagged or quarantined.
  • SPF and DKIM: Cloudflare signs forwarded messages with DKIM matching sender's domain. SPF re-write happens automatically — destination mailbox sees Cloudflare as the legitimate sender.
  • Workers integration: Route email to a Worker for programmatic handling — parse, transform, store, integrate with downstream APIs. Powerful for support ticket creation, transactional flows.
  • Per-domain quota: Hundreds of rules per domain, generous monthly send volume in free tier.
  • API and Terraform: All routes manageable via API. Common for SaaS platforms managing customer-domain email routing.
Anticipated customer questions
"Is it really free?"Yes — no per-route fee, no per-message fee, no premium tier. Free forever for any domain on Cloudflare DNS.
"Can I send from Cloudflare?"Not directly via Email Routing (receive-only). For sending, use Cloudflare Email Service (transactional, API-based, separate product) or pair with Workspace / Microsoft 365 / SendGrid for general outbound.
"What about attachments?"Forwarded with the message. Same size limits as the destination provider (Gmail / Outlook).
"DMARC failures?"Cloudflare re-signs forwarded mail with DKIM. The destination sees Cloudflare as the immediate sender, but the original sender's identity is preserved in headers. Most modern receivers handle this well.
"Aliases vs separate users?"Email Routing creates aliases — one or many addresses pointing at the same real mailbox. If you need separate users with separate inboxes / calendars / passwords, that's Workspace / M365 territory.
"Catch-all routes?"Supported — *@yourdomain.com forwards to catchall@somewhere.com. Great for projects where you can't predict every address you'll need.
"Workers integration use case?"Route support@yourcompany.com to a Worker. Worker parses message, creates Zendesk / Linear / Jira ticket, replies with confirmation. Or route invoices@ to a Worker that forwards to AP + archives in R2. Lightweight email automation.
"Compliance / privacy?"Cloudflare doesn't store forwarded messages (transit only). SOC 2 / ISO 27001 applies to Cloudflare's infra. For HIPAA — Cloudflare does support BAA on certain products; verify Email Routing inclusion with compliance team.
Industry angles
Solo / Small teams
Look professional without paying $6/seat. hello@yourstartup.com forwards to your real inbox.
SaaS
Distribute mailing list addresses (engineering@, sales@, security@) that fan out to teams. Or programmatic email-to-API handling via Workers.
Developer / Dev tools
Per-project / per-environment addresses (alerts-prod@, alerts-staging@) routing to PagerDuty or Slack via Workers.
Agencies
Manage email routing for client domains without setting up mail infrastructure.
Brand protection
Defensive domain registrations with catch-all routing for monitoring lookalike attacks.
Pricing: Free. No paid tier yet.
Gotcha: Receive-only — can't send from Cloudflare via Email Routing. Pair with outbound provider for two-way email.
Gotcha: Forwarded mail may be marked as spam by some destinations if DMARC is strict — DKIM re-signing helps but isn't 100% bulletproof across all receivers.
Gotcha: Destinations must be verified — one-time confirmation email. Some users miss this step and wonder why forwarding doesn't work.
Gotcha: Requires zone on Cloudflare DNS. Won't work if domain uses third-party DNS.
Gotcha: Email Routing's MX records replace any existing MX records — incompatible with running a separate mail server on the same domain.
Where to find it in the dashboard
Per-zone [Domain] → Email → Email Routing
  • Routes — add/edit address-to-destination mappings, enable wildcards, catch-all.
  • Destinations — verified forwarding addresses.
  • Settings — enable/disable, DNS auto-config, custom workers.
  • Analytics — received / forwarded / dropped (spam) volume.

SSL/TLS Universal SSL free, Advanced/Custom paid

What
Free SSL/TLS certificates for any domain on Cloudflare, with optional paid upgrades for custom certificates, dedicated certs, geo key management, mTLS, post-quantum encryption.
Why
Every modern website needs HTTPS. Acquiring, deploying, and renewing certs is operational work most teams don't want. Cloudflare made Universal SSL free on every plan in 2014 — single-handedly accelerating HTTPS adoption on the web. Today it's foundational infrastructure most customers take for granted, but the advanced tiers solve real enterprise problems.
Say"SSL/TLS at Cloudflare is the unsung foundation. Every Cloudflare zone gets a free certificate via Universal SSL — Cloudflare issues, deploys, and renews automatically. Free. No setup. Works the moment you point DNS at us. That alone is what most customers need. Beyond that, there are paid tiers for specific situations. Advanced Certificate Manager lets you customize the cert — pick the CA (Let's Encrypt, Google Trust Services, SSL.com), pick the validity period, add custom hostnames, control which root cert clients see. Custom Hostnames / SSL for SaaS is the multi-tenant story for SaaS platforms. Keyless SSL keeps your private key in your data center — useful for compliance regimes that prohibit key escrow. Geo Key Manager controls where private keys are physically stored — important for data residency rules. mTLS lets you require client certificates, common for API authentication or zero-trust device posture. And as of 2025, all of Cloudflare's TLS is post-quantum capable — Kyber encryption protects against future quantum-computer attacks."
Customer Scenario The setup:A European bank operates under EU data residency rules that prohibit private TLS keys from leaving the EU. They want Cloudflare in front of their public-facing applications but can't hand over private keys. The pain:Standard CDN models require uploading the private key to the CDN provider. Their compliance team would not sign off — keys had to stay in the bank's HSM in Frankfurt. They'd been told to "find a non-Cloudflare solution" because of this requirement. What they built:Implemented Keyless SSL. Cloudflare terminates TLS sessions globally without ever holding the private key — instead, the signing operation reaches back to the bank's HSM in Frankfurt over a secure channel. The key never leaves the bank's premises. Configured Geo Key Manager for the supporting ephemeral keys so they stay EU-region too. The outcome:Compliance signed off. Bank now sits behind Cloudflare for DDoS, WAF, and performance, with the key-handling requirement satisfied. This unlocked a regulated-industry use case the bank had been told was impossible with a global CDN.
Objection: "We use Let's Encrypt directly""Let's Encrypt is great — Cloudflare uses Let's Encrypt under the hood for many certs. The value Cloudflare adds is the management layer: automated deployment to 330+ PoPs, automatic renewal handling, no certbot to maintain, integration with the rest of the stack. For a single server, Let's Encrypt direct is fine. For anything at scale, the management cost adds up."
Objection: "We need EV certificates""Cloudflare focuses on DV (Domain Validation) certs for the proxied stack — the modern web has largely moved away from EV after browsers stopped showing the green bar. For customers that still require EV (specific regulated industries), you can BYO certificate via Custom SSL / BYOC on Business+ plans. Cloudflare's edge will serve the EV cert you bring."
How this relates to Cloudflare for SaaSSSL/TLS is the certificate engine for domains you own. Cloudflare for SaaS is the multi-tenant orchestrator on top of it for domains your customers own. Same underlying technology — Let's Encrypt issuance, Cloudflare edge termination, automatic renewals — but very different products. If the customer is asking "how do I get HTTPS on my site?" → SSL/TLS. If they're asking "how do I let my customers point their domains at my SaaS?" → Cloudflare for SaaS. The clean analogy: SSL/TLS and Cloudflare for SaaS are like Workers and Workers for Platforms. One runs your code; the other runs your customers' code on your platform. Same engine, different product. The Custom Hostnames feature on the SSL/TLS dashboard is actually the heart of Cloudflare for SaaS — that's where the naming overlap comes from.
Deep Dive — SSL/TLS
How it actually works
  • Universal SSL (free, all plans): Cloudflare issues a SAN cert covering apex + first-level wildcard (acme.com + *.acme.com). Auto-issued, auto-deployed, auto-renewed. CA is Let's Encrypt or Google Trust Services.
  • Advanced Certificate Manager (paid): Customize per-hostname certs. Pick CA. 30-day to 1-year validity. Add custom SANs. Control which intermediate cert is served. Useful when default Universal SSL doesn't fit.
  • Custom SSL / BYOC (Business+): Upload your own certificate + private key. Useful for EV certs, corporate CAs, specific compliance.
  • Keyless SSL (Enterprise): Your private key stays on your servers. Cloudflare terminates TLS but signs handshakes by calling back to your key server. Compliance-required for some financial / government customers.
  • Geo Key Manager (Enterprise): Control which geographic region holds the private key. E.g., EU keys only in EU PoPs. GDPR / data residency compliance.
  • Origin certificates: Free, long-lived (up to 15 years) certs for the link between Cloudflare and your origin. Locks down origin to only accept Cloudflare-presented certs.
  • mTLS (mutual TLS): Require client certificates for inbound connections. Configure trusted client CAs. Common for API auth, IoT device auth, Zero Trust device posture.
  • Post-quantum encryption: Cloudflare supports hybrid key exchange (X25519 + Kyber) by default. Protects against "harvest now, decrypt later" attacks by future quantum computers.
  • SSL/TLS settings per zone: Off / Flexible / Full / Full (Strict). Strict is the production-correct setting — encrypts CF↔origin AND validates origin cert.
Anticipated customer questions
"What's the difference between Universal SSL and Advanced?"Universal SSL: free, automated, one cert per zone covering apex + first-level wildcard. Advanced Certificate Manager: paid, customizable. Pick the CA, validity, custom SANs, deployment patterns. Most customers don't need Advanced — Universal is fine.
"Does Cloudflare see my plaintext traffic?"Yes — that's how a CDN / reverse proxy works. Cloudflare decrypts, inspects (for WAF, caching, etc.), re-encrypts to origin. For customers where this is unacceptable, Keyless SSL keeps decryption keys on customer servers but Cloudflare still terminates the TLS handshake. For full end-to-end, you'd disable proxying (grey cloud) — but then you lose Cloudflare's protection.
"What's Full vs Full (Strict)?"Full: Cloudflare encrypts to origin but doesn't validate origin's cert (could be self-signed). Vulnerable to MITM between CF and origin. Full (Strict): encrypts AND validates origin presents a valid certificate. Use Strict in production always. Use Origin Certificates (free, 15-year) to make this easy.
"What about wildcard certificates?"Universal SSL covers apex + first-level (acme.com, *.acme.com). Multi-level wildcards (*.api.acme.com) require Advanced Certificate Manager or Custom Hostnames.
"How does post-quantum work?"TLS handshake uses hybrid key exchange — classical X25519 plus post-quantum Kyber. If quantum computers eventually break X25519, the Kyber half still protects the connection. Transparent to clients that support hybrid (modern browsers); falls back to classical otherwise.
"What's mTLS used for?"Client authentication via certificate instead of password / API key. Common: machine-to-machine APIs (call your API only if client presents valid cert from your corporate CA), IoT devices (each device has a unique cert), Zero Trust (device posture validation).
"CAA records — what do we need?"CAA tells the world which CAs are allowed to issue certs for your domain. For Cloudflare Universal SSL, allow letsencrypt.org and pki.goog (Google Trust Services). Missing or wrong CAA = cert issuance failures. Common gotcha.
"How long does cert provisioning take?"Universal SSL: typically minutes after DNS is configured. Sometimes up to 24 hours. Validation via HTTP or DNS-01 challenge automated. Advanced certs: similar timing.
Industry angles
SaaS
Custom Hostnames / SSL for SaaS for multi-tenant. Per-tenant certs auto-managed. Often paired with apex proxying.
Fintech / Banking
Keyless SSL for compliance regimes requiring key custody. Strict cert validation. mTLS for API authentication.
Government / Defense
Geo Key Manager for data residency. Post-quantum encryption for forward secrecy against future quantum attacks. Custom CA support.
Healthcare
Strict cert validation. mTLS for medical device APIs. BAA-compatible TLS handling.
IoT
mTLS for device authentication at scale. Custom hostnames per device class. Programmatic cert provisioning via API.
Pricing: Universal SSL free on all plans. Advanced Certificate Manager: $10/month per certificate. Custom Hostnames / SSL for SaaS: per-hostname pricing (covered in SaaS entry). Keyless SSL, Geo Key Manager, mTLS: Enterprise. BYOC: Business+.
Gotcha: CAA records block Let's Encrypt by default if your registrar set them. Add letsencrypt.org and pki.goog, or remove CAA entirely.
Gotcha: Use Full (Strict) mode, not Full or Flexible. Flexible is broken (HTTP between CF and origin). Full doesn't validate origin cert.
Gotcha: Universal SSL only covers apex + one wildcard level. Deeper subdomains need Advanced Cert Manager.
Gotcha: Cert provisioning can fail silently on DNS misconfigurations. Check the SSL/TLS dashboard for issued / pending status.
Gotcha: Keyless SSL adds latency (call to customer key server per handshake). Mitigated by session resumption but real for new connections.
Gotcha: Some old clients (Android <5, IE 11 on XP, etc.) don't support modern TLS. Cloudflare lets you tune minimum TLS version per zone.
Where to find it in the dashboard
Per-zone [Domain] → SSL/TLS
  • Overview — current SSL mode (Off / Flexible / Full / Strict), cert status.
  • Edge Certificates — Universal SSL, Advanced Certificate Manager, custom certs.
  • Origin Server — Origin Certificates (long-lived for CF↔origin), authenticated origin pull.
  • Custom Hostnames — SSL for SaaS configuration.
  • Client Certificates — mTLS configuration, trusted client CAs, mTLS rules.
  • Edge Certificates → Settings — minimum TLS version, ciphers, HSTS, automatic HTTPS rewrites.

Zero Trust / Access

What
ZTNA — users authenticate to apps, not the network. VPN replacement.
Benefits
No VPN infra • no lateral movement • granular access • contractor-friendly.
Say"Zero Trust is a way to replace your VPN. Here's the difference — with a traditional VPN, an employee logs in and suddenly has access to your entire company network, even stuff they don't need. If their laptop ever gets hacked, the attacker has access to everything too. With Zero Trust, users log in to individual apps, not the network. So your salesperson can access Salesforce and their email, but they literally cannot see your engineering tools — those apps are invisible to them. We check who they are using your existing login system like Okta or Microsoft, and we can even check things like whether their laptop has encryption turned on before letting them in. The big wins — no VPN client to install, no slowness, contractors are easy to manage because you give them access to just one tool, and hackers can't move sideways through your network because users were never on it to begin with."
Customer Scenario The setup:A mid-market law firm — 600 employees, ~80 contractors at any given time, hybrid work model. They run Cisco AnyConnect for VPN access to internal apps (document management, billing system, HR, internal wiki). The pain:VPN was the biggest IT complaint — slow, frequent disconnects, didn't work well from hotels and conferences. Contractor offboarding was sloppy — IT often forgot to revoke VPN access for weeks. And after a phishing incident gave attackers a partner's VPN creds, they had full lateral movement across the network. Cyber insurance premium jumped 40% at renewal. What they built:They put Cloudflare Access in front of each internal app — document management, billing, HR, the wiki. Users authenticate through their existing Okta. Each app has its own policy — billing requires hardware key, HR requires manager group, the wiki is open to all employees. Contractors get per-app access that auto-expires at the contract end date. The VPN got decommissioned. The outcome:Help desk tickets about VPN dropped to zero. Contractor access actually expires when it's supposed to. The follow-up phishing attempt that got a partner's credentials hit a wall — attacker had a password but no hardware key, no MFA approval, no access. Cyber insurance audit went smoothly and the premium came back down.
Objection: "Our VPN works fine""Until it doesn't — capacity issues, cert problems, compromised creds that hand attackers full network access. Zero Trust removes that risk entirely."
Objection: "Sounds expensive vs VPN""VPN has hidden costs — hardware, maintenance, incident response. Access is per-active-seat. Usually comparable or cheaper TCO."
Deep Dive — Zero Trust / Access
How it actually works
  • Identity providers: Okta, Azure AD/Entra, Google Workspace, OneLogin, Ping, Auth0, generic SAML, OIDC, GitHub, plus social. Multiple IdPs per organization. Step-up authentication supported.
  • Application types: Self-hosted web (reverse proxy), SaaS (SAML/OIDC IdP-broker mode), private network (TCP/UDP via WARP client), SSH (browser-rendered or native), RDP, VNC.
  • Tunnels: Cloudflare Tunnel — outbound-only connection from your origin to CF. No firewall holes, no public IPs needed. Replaces VPN concentrators.
  • WARP client: Lightweight agent (Windows, Mac, Linux, iOS, Android) — registers device, applies Gateway/Access policies, optionally enforces always-on connectivity.
  • Device posture: Check OS version, disk encryption, EDR presence (CrowdStrike, SentinelOne, etc.), specific files, certificates, serial numbers. Use as policy conditions.
  • Policies: Identity (group, email), device posture, country, network, time of day, MFA recency. Combine into allow/block/require-MFA rules.
  • Session management: Per-app session duration. Force re-auth on sensitive apps. Continuous evaluation possible.
  • Audit: Every authentication, every app access, every policy decision logged. Logpush to SIEM.
Anticipated customer questions
"How do users connect?"Browser-based apps: nothing to install. TCP/network apps: WARP client. Hybrid possible.
"What about legacy apps that don't speak SAML/OIDC?"Self-hosted mode — Access sits in front, authenticates user, passes Cf-Access-Jwt-Assertion header to your app. App trusts the header (validate signature).
"How is this different from Zscaler ZPA?"Comparable ZTNA capabilities. Differences: unified platform with WAF/DDoS/CDN/SWG (Zscaler ZPA is access-only), per-active-user pricing, faster deployment (hours vs weeks), better self-service.
"vs Palo Alto Prisma Access?"Prisma has deeper inspection features (DLP, sandboxing). We've closed most of that gap and offer simpler pricing + better DX. Pilot easily.
"vs Tailscale/Twingate?"Tailscale is great for small teams, peer-to-peer mesh. We're for organizations needing identity-based policy, device posture, audit, compliance.
"Can we integrate with our existing IdP?"Yes — bring any IdP. We're identity-agnostic. Many customers use Okta or Entra; we federate seamlessly.
"Device posture — what do you check?"OS version, disk encryption, firewall enabled, application running (EDR), file presence, certificate installed, gateway client check, serial number list, third-party integrations (CrowdStrike, SentinelOne, Tanium, Intune).
"What about contractors / external users?"Just-in-time access via temporary identity, social IdP (Google, GitHub), or one-time PINs to email. No corporate account required.
"How do we migrate from VPN?"Phased: start with one app (often internal wiki or admin tool), expand. Run Access alongside VPN initially. Most customers deprecate VPN within 6 months.
"What about clientless apps?"Browser-based apps need zero client install. Just point DNS at Cloudflare and configure policy.
"How fast does it deploy?"Single app: 30 minutes. Org-wide rollout: weeks (mostly policy design + change management, not technical).
"What about compliance — SOC2, FedRAMP, HIPAA?"SOC2 Type II, ISO 27001. FedRAMP Moderate authorized (separate gov-cloud instance). BAA available for HIPAA.
Industry angles
Fintech
Sensitive admin tools, trading systems, internal dashboards. Device posture + MFA + audit critical. SOC2 alignment.
Healthcare
EHR access, telehealth admin tools. BAA + audit logging for HIPAA. Contractor access for clinical staff.
SaaS
Internal tools, customer support portals, admin dashboards. Contractor management without VPN sprawl.
Ecommerce
Warehouse systems, POS admin, vendor portals. Multi-site offices benefit from no-VPN model.
Gaming
Dev tools, build systems, game ops dashboards. Studios with distributed teams benefit hugely.
Media
CMS access, partner portals, advertiser dashboards. Geographic restrictions easy to enforce.
Pricing notes: Zero Trust Free: up to 50 users (Access + Gateway DNS). Standard: ~$7/user/mo. Enterprise: ~$10/user/mo. Per "active" seat — billed on usage, not provisioned. Browser Isolation, CASB, DLP are add-ons or part of higher SKUs.
Gotcha: Some legacy apps with hardcoded auth (SSO assumptions, IP-based access) need configuration changes when moving from VPN.
Gotcha: WARP client conflicts with some endpoint security tools (older VPN clients, certain EDRs). Test compatibility before mass deploy.
Gotcha: SaaS app integration (e.g., putting Cloudflare in front of Workday SAML) requires customer to configure their SaaS IdP — not always trivial.
Gotcha: Contractors using personal devices may not accept WARP client install — plan browser-based access patterns.
Where to find it in the dashboard
Zero Trust (opens separate dashboard)
Zero Trust has its own dashboard. Click "Zero Trust" from the main dashboard's left nav — you'll be taken to one.dash.cloudflare.com.
  • Access controls → Applications — list of all protected apps (self-hosted, SaaS, private network, infrastructure). Add new apps here.
  • Access controls → Policies — reusable access policies (Allow / Block / Bypass). Apply to applications.
  • Access controls → Service credentials — service tokens for non-human access (CI/CD, automation).
  • Networks → Connectors — Cloudflare Tunnels (outbound-only origin connections). Create / manage cloudflared tunnels and WARP Connectors.
  • Integrations → Identity providers — Okta, Entra, Google, SAML, OIDC, etc. Configure SSO.
  • Settings → WARP Client — device enrollment, deployment profiles, posture checks.
  • Team & Resources → Users / Devices — see active users, registered devices, posture check status.
  • Insights & Logs → Logs — every authentication and access decision logged. Filter by user, app, action.
Note: Cloudflare reorganized the Zero Trust dashboard recently. The old "Access" menu is now "Access controls." Old "My Team" items are now under "Team & Resources." Old "Logs" is now under "Insights & Logs."

Cloudflare Tunnel Free with any plan

What
Outbound-only encrypted connector that exposes internal services to Cloudflare's network without opening firewall ports or public IPs.
Why
Traditional remote access requires inbound firewall holes, public IPs, VPN concentrators, or DMZ hardware. Tunnel runs as a daemon on a server, dials out to Cloudflare, and Cloudflare routes traffic to it. Zero attack surface — nothing inbound, nothing publicly reachable.
Say"Cloudflare Tunnel is how you connect your internal stuff to Cloudflare without opening firewall ports or having a public IP. You install a small daemon called cloudflared on a server inside your network — could be a Linux box, a Kubernetes pod, a Windows server. It dials outbound to Cloudflare and stays connected. Now any traffic Cloudflare needs to send to that server gets routed through the tunnel. So your internal webapp, your private database, your dev environment, your home lab — you can expose them through Cloudflare and protect them with Access (Zero Trust), all without any inbound rules. It's the same primitive Cloudflare uses for Zero Trust private network access. It's free, runs on basically any OS, and can handle anything from HTTP to SSH to RDP to TCP / UDP. A lot of customers use Tunnel as their first ZT building block — replace the VPN for one app, expand from there."
Customer Scenario The setup:A mid-market manufacturer wants their remote engineers to access an internal SCADA reporting dashboard. The dashboard server lives on a plant floor network with no public IP and an extremely restrictive firewall. The pain:Engineers were jumping through a clunky VPN with a 1990s UX. Setting up a public IP and a DMZ for the dashboard required filing tickets with the OT (operational technology) team — which was politically a non-starter. Punching inbound holes in the plant firewall was off the table. What they built:Installed cloudflared on a small Linux box inside the plant network. The tunnel dials outbound to Cloudflare — no inbound firewall change required. Put Cloudflare Access in front, restricted to the engineering team's Okta group with hardware key MFA. The dashboard got a clean URL like scada.companyname.com. The outcome:Engineers get to the dashboard in one click from anywhere. The OT firewall didn't change a single rule. Audit logs are centralized in Cloudflare instead of scattered in VPN logs. This became their template — they're rolling the same pattern to 12 more internal apps.
Objection: "We use a VPN. Why switch to Tunnel?""VPN gives users access to the whole network — lateral movement risk. Tunnel + Access gives access to specific apps — zero lateral movement, identity-verified per app. Plus VPN clients are clunky on mobile, painful for contractors, and you have to maintain VPN infrastructure. Tunnel is the underlying primitive for Cloudflare Zero Trust — VPN replacement done right."
Objection: "Is it really secure if it's just a tunnel?""Outbound-only — your firewall stays closed for inbound. TLS 1.3 with mutual auth between cloudflared and Cloudflare edge. Post-quantum encryption (Kyber) in the WARP-based tunnels. Pair with Access for identity-based gating on top. The threat model is way better than 'inbound port 443 with WAF in front' which is what most companies do today."
How this differs from regular CloudflareRegular Cloudflare protection works inbound — somebody requests your website, hits our edge, we proxy them to your origin server. That requires your origin to have a public IP address with port 443 open to the internet. Tunnel flips the connection direction. You install a small daemon called cloudflared on a server inside your network, and IT initiates the connection outbound to Cloudflare. The tunnel stays open, and traffic flows through it both ways. So your origin server has zero inbound ports open — your firewall blocks everything from the internet. From an attacker's perspective, your server doesn't exist on the public internet at all. They can't find it, can't scan it, can't even tell what IP it's on. That's a fundamentally stronger security posture than "we have a WAF in front of an exposed origin." It also unlocks use cases regular Cloudflare can't touch — protecting internal apps that should never be on the internet (admin tools, databases, dev environments), home labs, OT systems in manufacturing, anything behind a corporate firewall. Combined with Access for identity-based gating, it's the foundation of how Cloudflare does Zero Trust private network access.
Deep Dive — Cloudflare Tunnel
How it actually works
  • cloudflared daemon: Lightweight Go binary. Runs on Linux, macOS, Windows. Container available. Kubernetes operator for k8s clusters.
  • Outbound tunnel: cloudflared establishes persistent HTTP/2 or QUIC connections to Cloudflare's edge. No inbound firewall changes required.
  • Public hostname routing: Map a public hostname (e.g. app.acme.com) to a private service (e.g. http://internal-server:8080). Cloudflare proxies user traffic through the tunnel.
  • Private network mode: Advertise CIDR ranges (e.g. 10.0.0.0/8) through tunnel. WARP-connected users can reach any IP in those ranges as if on the LAN. No per-app config needed.
  • Multiple replicas: Run multiple cloudflared instances pointing at same tunnel for HA. Cloudflare load-balances across replicas.
  • Auth flows: Pair with Cloudflare Access for identity-based gating. Pair with Gateway for outbound filtering on tunneled traffic.
  • Supported protocols: HTTP/HTTPS (most common), SSH, RDP, VNC, raw TCP, UDP, SMB, arbitrary protocols via WARP-connected private network mode.
  • Browser-based SSH/RDP: When paired with Access, users SSH/RDP via browser — no client install required. Session recording on Enterprise.
Anticipated customer questions
"What's the latency cost?"Single-digit ms added by Cloudflare's edge. Tunnel uses HTTP/2 or QUIC — keeps connections warm, no per-request handshake. For most apps, imperceptible.
"Can it handle high traffic?"Yes — multiple cloudflared replicas for HA, automatic load balancing. Big customers run hundreds of replicas. Throughput limited by cloudflared instance + network — not Cloudflare side.
"What about TCP / UDP (not HTTP)?"Supported. Public hostname mode for HTTP/SSH/RDP/specific TCP services. WARP-based private network mode for arbitrary IP routing — users on WARP can reach any IP in advertised CIDR ranges.
"Kubernetes?"Official Cloudflare Operator deploys cloudflared into k8s clusters. Manages tunnel lifecycle, secrets, hostnames as Kubernetes resources.
"What if cloudflared crashes?"Systemd / launchd / Windows service auto-restart. Multiple replicas for HA. Cloudflare detects dead replicas and stops routing to them within seconds.
"Can we run it air-gapped?"cloudflared needs outbound HTTPS to Cloudflare edge. If outbound 443 is blocked entirely, it doesn't work. Most enterprise networks allow outbound 443 even with strict ingress controls.
"Logs and audit trail?"Tunnel events (connect/disconnect/error) in Cloudflare logs. When paired with Access, every authentication and authorization decision logged. Logpush to SIEM available.
"Cost?"Tunnel itself is free. Pair with Access for identity (Free up to 50 users, then per-seat). Pair with Gateway for outbound filtering (per-seat).
"Difference between cloudflared and WARP Connector?"Same fundamental tech, different positioning. cloudflared = traditional Tunnel for exposing services. WARP Connector = newer, designed for site-to-site networking (multiple sites mesh together through Cloudflare). Both work; WARP Connector is the future direction for branch/multi-site.
Industry angles
SaaS
Expose internal dev / staging environments to contractors without VPN. Replace VPN entirely for production app access.
Fintech / Healthcare
Inbound-port-zero posture — compliance auditors love this. Combine with Access for identity-driven gating.
Manufacturing / OT
Expose specific operational systems (HMI dashboards, log viewers) to remote engineers without VPN risk.
Dev / Internal tools
Free tier handles homelabs, side projects, dev environments. Common Tunnel adoption story: developer uses it personally, brings it to work.
Multi-region orgs
Cloudflare edge has 330 PoPs — tunneled traffic egresses globally. User in Tokyo accessing app in Virginia goes via nearest Cloudflare PoP, not direct.
Pricing: Tunnel itself is free, included with any Cloudflare plan including Free. Companion products priced separately: Access (per-seat after 50 users free), Gateway (per-seat), session recording (Enterprise).
Gotcha: cloudflared is stateless — secret stored on disk, server reinstall means re-creating tunnel. Use named tunnels with tokens stored in secret manager for reproducible deployments.
Gotcha: Public hostname mode requires a domain on Cloudflare. Private network mode (WARP) doesn't.
Gotcha: By default, cloudflared accepts traffic from any source — Access policy required for identity gating, otherwise it's just a public reverse proxy.
Gotcha: Tunnel logs and metrics live in Zero Trust dashboard, not main Cloudflare dashboard — confuses customers used to per-zone analytics.
Gotcha: Long-lived TCP connections (e.g. database connections, persistent SSH sessions) work but have idle timeouts — tune keep-alives.
Where to find it in the dashboard
Zero Trust Networks → Connectors
  • Tunnels list — all tunnels in account. Status (healthy / unhealthy), replica count, last seen.
  • [Tunnel] → Public Hostnames — map domain.com paths to internal services.
  • [Tunnel] → Private Networks — advertise CIDR ranges to WARP users.
  • [Tunnel] → Configuration — install commands, token regeneration, replica management.
  • [Tunnel] → Metrics — request volume, error rates, latency per hostname.
Zero Trust Networks → Routes
  • Routes — manage which CIDR / hostname combos route through which tunnel.
Tunnel and Access are configured separately. Tunnel says "where the service lives." Access says "who can reach it." Both required for full Zero Trust pattern.

Browser Isolation (RBI)

What
Risky web pages render in a disposable browser inside Cloudflare's network. The user sees pixels and audio streamed to their device. Active web content (JavaScript, downloads, scripts) never reaches the endpoint.
Why
Browsers are the most-attacked surface in any company — phishing pages, drive-by downloads, malicious JavaScript, ransomware delivery, credential theft. Traditional security inspects content and tries to block bad stuff. Browser Isolation flips the model: assume the page is hostile, render it in a sandbox, never let active code touch the user's machine.
Say"Browser Isolation is one of the most underrated Cloudflare One products. Here's how it works — when a user visits a risky page, instead of their browser running the page locally, Cloudflare spins up a disposable browser in our data center, renders the page there, and streams just the visual output back to the user. The user can scroll, click, type, watch videos — feels like a normal browser experience. But the actual JavaScript, downloads, and active content stay in our sandbox, which gets destroyed at session end. So phishing pages can't capture credentials, drive-by downloads can't deliver malware, malicious scripts can't pivot to other tabs. It's especially powerful for risky categories — newly-registered domains, uncategorized sites, content the policy flags as suspicious. Pair it with Gateway and you can say 'render anything in this category in isolation' as a policy. The latency is surprisingly low because Cloudflare runs the isolated browsers on the same network as Gateway's filtering, and the protocol is bandwidth-efficient — we're streaming rendered output, not raw video."
Customer Scenario The setup:A law firm — 1,200 attorneys, all of whom routinely visit sketchy sites as part of their work (opposing counsel websites, news from obscure regions, leaked documents on weird hosting). Their endpoint security tool blocks everything aggressively, which is constantly disrupting work. The pain:The security team had two bad choices — block too much (attorneys can't do their job, file workarounds) or block too little (drive-by malware risk). They had two malware incidents traced to attorneys clicking links in case files. What they built:Routed all browsing through Cloudflare Gateway with policy: known-bad blocked outright, newly-registered or uncategorized domains rendered in Browser Isolation, everything else passes normally. Attorneys can visit any site, but risky ones run in Cloudflare's cloud, not on their laptop. The outcome:Two more incidents that would've been malware infections were absorbed by Browser Isolation — the malicious code ran in Cloudflare's disposable sandbox and never touched any laptop. Attorney complaints about blocked sites went down because legitimate-but-weird sites now just work (in isolation).
Objection: "Won't this feel sluggish for users?""Cloudflare's RBI uses a network vector rendering protocol — we stream rendered draw commands, not raw video frames. So bandwidth is low and the experience is close to native. For typical browsing (forms, reading, scrolling) most users can't tell. Heavy media (4K video, gaming) is where it shows. The trick is policy — don't isolate everything, just the risky stuff."
Objection: "We already have an EDR. Isn't this overlap?""EDR catches threats after they execute on the endpoint. Browser Isolation prevents threats from reaching the endpoint at all. Defense in depth — EDR for things that slip through, RBI for the highest-risk web categories upfront. Combined they're stronger than either alone."
How this differs from regular Cloudflare securityRegular Cloudflare security inspects traffic and tries to make a yes/no decision — block this request, allow that one, scan this file for malware. It's pattern-matching against known threats. Browser Isolation works on a completely different premise: assume any web page might be malicious and just don't let it touch the user's machine in the first place. When a user clicks a link, instead of their browser fetching and running the page locally, we spin up a fresh Chromium browser in our data center, load the page there, and stream the rendered output back to the user. They can interact normally — click, type, scroll, watch videos — but the actual JavaScript, downloads, and any malicious code stay in our sandbox. At session end the sandbox is destroyed. So even if a user lands on a zero-day phishing page that bypasses every other filter, the malicious code physically can't reach their device. It's a fundamentally different threat model from WAF / Gateway / DDoS protection — those are detection-based, RBI is isolation-based. The streaming protocol (Network Vector Rendering) is also worth understanding — we send rendered draw commands instead of raw video frames, which is why bandwidth stays low and latency feels close to native browsing. Most customers think of it as a defense against unknown threats, but it's also a clean way to give contractors and BYOD users access to sensitive SaaS apps without trusting their devices.
Deep Dive — Browser Isolation
How it actually works
  • Network Vector Rendering (NVR): Cloudflare's protocol streams rendered draw commands to the user's browser. Way more bandwidth-efficient than streaming pixels or video.
  • Disposable Chromium: Each session runs a fresh Chromium instance in Cloudflare's data center. Destroyed at session end — no persistent state, no cross-session contamination.
  • Same-tab rendering: User's browser renders the isolated session in the same tab. Looks like the real page. Address bar, navigation, scroll all work natively.
  • Gateway integration: RBI is a Gateway action. Write HTTP policies: "if domain is risky-category, isolate." If approved-category, allow direct. If malicious-category, block.
  • Clientless mode: RBI can run without WARP client — users navigate via a Cloudflare URL prefix. Useful for unmanaged devices, contractor access, third-party apps.
  • Data exfil controls: Block copy/paste between isolated session and local clipboard. Block printing. Block downloads. Block keyboard input on sensitive pages. Watermark sessions.
  • Sensitive app protection: Common pattern — render high-value SaaS apps (Salesforce, internal admin, etc.) in RBI from unmanaged devices. Data stays in the isolated browser; user just sees pixels.
  • Session recording: Available for compliance / audit use cases.
Anticipated customer questions
"What's the latency hit?"Typically 50-200ms additional for typical browsing — most users don't notice. Heavy media (4K, real-time video) feels different. Cloudflare runs RBI in the same PoPs as Gateway, so network overhead is minimal.
"Bandwidth usage?"NVR protocol streams draw commands, not raw video. Typical session is single-digit Mbps. Way less than VDI or DaaS streaming.
"What if the user tries to download a file from an isolated session?"Policy-controlled. Default: file downloads sanitized (PDFs flattened, executables blocked). Stricter policies block all downloads from isolated sessions. Looser policies allow with content scanning.
"Does it work on mobile?"Yes — Cloudflare One Client (WARP) supports RBI on iOS and Android. Clientless mode also works on mobile browsers.
"Pricing?"Per-seat add-on to Cloudflare One Zero Trust. Verify with account team — pricing tier depends on usage profile.
"How does it handle Single Sign-On / authenticated sessions?"Cookies, session tokens flow through. User auths to the destination normally — auth state lives in the isolated browser for the session, destroyed at end.
"What about extensions and bookmarks?"Isolated sessions don't carry user browser extensions or bookmarks — disposable Chromium has nothing. For SSO bookmarks / SaaS app launchers, use the Cloudflare One App Launcher.
"vs Menlo / Authentic8 / Talon?"Menlo Security: mature RBI specialist, comparable feature depth, separate vendor. Authentic8: focused on regulated industries. Talon: enterprise browser approach. Cloudflare RBI: native integration with Gateway/Access, simpler procurement, faster deployment, competitive pricing. Pick standalone vendors if you have very specific RBI feature requirements; pick Cloudflare RBI when consolidating onto a single SASE platform.
Industry angles
Fintech
Render risky / uncategorized sites in isolation. Protect against phishing aimed at financial credentials. Sensitive internal apps in RBI from unmanaged devices.
Healthcare
Patient data systems accessed via RBI from BYOD / contractor devices — data never lands on endpoint.
Government / Defense
Air-gap-like browsing posture for sensitive workflows. RBI for any external web access.
Legal
Client-confidential document access via RBI. Copy/paste blocking prevents leak to personal storage.
Education
Student browsing with category-based isolation — safer than full content blocking.
Pricing: Per-seat Cloudflare One add-on. Tied to Zero Trust subscription. Verify exact pricing with account team.
Gotcha: Some sites detect headless / isolated browsers and break (banking sites, anti-fraud systems). Allowlist trusted destinations to bypass RBI when needed.
Gotcha: Heavy media (video conferencing, WebRTC, 4K video) — RBI not the right call. Direct browsing for those.
Gotcha: User extensions and saved logins don't carry into isolated sessions — re-auth each session unless app supports persistent SSO.
Gotcha: Policy design matters — isolate-everything kills UX. Best practice: isolate risky categories (new domains, uncategorized, file sharing, phishing-prone), allow-direct for known-good (M365, Workspace, internal apps).
Gotcha: Clientless mode requires customer to access through Cloudflare URL prefix — different UX than transparent WARP-based RBI.
Where to find it in the dashboard
Zero Trust Browser isolation
  • Settings — global RBI policy (copy/paste, downloads, printing, keyboard input restrictions).
  • Policies — RBI is also a Gateway action; configure via Traffic policies → Firewall policies → HTTP with action "isolate."
  • Sensitive App settings — designate specific apps for RBI-only access.
  • Session recording — enable per-policy recording for audit.

Gateway / SWG

What
DNS + web filtering for outbound traffic. Blocks phishing, malware, C2.
Say"Gateway controls what your employees can reach on the internet. Think of it as a filter between your users and the open web. The simplest version is DNS filtering — when somebody on your team tries to visit a phishing site or a known malware site, we just don't let them get there. They see a block page instead. We can also block whole categories like gambling, social media, or anything inappropriate, and scan files going out of your company for stuff that shouldn't leave — like credit card numbers or social security numbers. For really risky websites, we can open them in a remote browser that runs in our cloud, so even if the site has malware, it can't touch the employee's laptop. The big advantage we have is visibility — we see about 20% of all internet traffic, so we usually know a site is malicious before it ever shows up in any threat feed."
Customer Scenario The setup:A 2,000-person company runs Zscaler for secure web gateway. The contract is up for renewal at $190K/year. The pain:Zscaler worked fine but the price kept climbing every renewal. The security team also wanted DNS filtering on personal devices used by contractors, which Zscaler made painful and pricey. Plus they already had Cloudflare for the public-facing side and wanted to consolidate vendors. What they built:Replaced Zscaler with Cloudflare Gateway. Rolled out WARP client to managed laptops for tunneled filtering. Set DNS filtering policies for malware, phishing, and categories like gambling/adult. Layered DLP rules to scan outbound for PII. Browser Isolation on for newly-registered domains and uncategorized sites. Contractors use DoH on their devices pointed at the team's filter — no agent. The outcome:Annual SWG spend dropped from $190K to roughly $90K including Browser Isolation and DLP. Contractor coverage actually improved because DoH is easier than installing the Zscaler agent. The security team gets one console for Gateway + Access + CASB + DLP instead of three.
Objection: "We have a DNS filter""Most do blocking only. Gateway is integrated with our global threat intel and Zero Trust platform — one consistent policy across web, network, and apps."
Deep Dive — Gateway / SWG
How it actually works
  • DNS filtering: Lightweight, no agent needed. Set DNS to Cloudflare on device/router. We resolve normally for allowed, return block page IP for blocked.
  • Network filtering: Requires WARP client. L4 firewall — block by IP, port, protocol, app category.
  • HTTP filtering: Requires WARP client with TLS inspection cert installed. Full L7 inspection — URL, content category, file type, file size.
  • Categories: 70+ content categories (gambling, adult, social media, gaming, etc.) and security categories (malware, phishing, command-and-control, cryptomining, newly-registered domains).
  • Threat intel: Powered by Cloudflare's view of internet traffic — we see ~20% of web traffic, so emerging threats are detected early. 1.1.1.1 resolver feeds threat data.
  • TLS inspection: Optional — needed for L7 inspection of encrypted traffic. Cert deployed via MDM (Intune, Jamf, etc.). Selective by category (e.g., don't inspect banking, do inspect uncategorized).
  • Data Loss Prevention (DLP): Scan outbound traffic for PII, credit cards, source code, custom regex/keywords. Block or alert.
  • Remote Browser Isolation (RBI): Render risky pages in remote browser. User sees pixels; threats never reach endpoint. Triggered selectively (risky categories, uncategorized).
  • Logs: Every query, every block, every decision. Logpush to SIEM.
Anticipated customer questions
"Do we need to install anything?"For DNS filtering only: no client needed — change DNS on devices or router. For L4/L7 filtering: WARP client required.
"How does TLS inspection work?"Cloudflare cert installed on devices (via MDM). WARP terminates TLS, inspects content, re-encrypts to destination. Selective — don't inspect banking, healthcare, sensitive categories.
"How is this different from Zscaler Internet Access?"Comparable capabilities. We're typically faster to deploy (cloud-native, no SaaS console complexity), simpler policy model, unified with our other security products. Zscaler has deeper DLP/CASB maturity in some areas.
"vs Netskope / Menlo / iboss?"All credible SWG vendors. Differentiators for us: integration with Cloudflare's WAN/CDN/Access platform, unmetered DDoS on the same network, simpler pricing.
"What about Cisco Umbrella?"Umbrella is strong on DNS filtering. We're broader (DNS + L4 + L7 + DLP + RBI in one product). Often cheaper at scale.
"Can we do CIPA / school-compliant filtering?"Yes — content categories, time-based rules, per-user-group policies. K-12 customers use us widely.
"What about BYOD?"DNS-only mode works for BYOD without forcing WARP. Or use clientless RBI links to push sensitive web apps through isolated browser.
"How do we handle private apps?"Combine Gateway with Access — same WARP agent, unified policy. Internet traffic filtered, private apps gated by identity.
"Performance impact?"Anycast — traffic routes to nearest PoP. Typically faster than the local ISP DNS for resolution. L7 inspection adds latency but we're optimized — usually <20ms overhead.
"What about shadow IT discovery?"Gateway logs show every SaaS app accessed. Build inventory automatically. CASB extends with config scanning of approved apps.
Industry angles
Fintech
Block C2 callbacks, prevent data exfil via DLP, audit every external connection.
Healthcare
PHI exfiltration prevention (DLP for PHI patterns), block clinical-system access from unmanaged devices.
K-12 / Higher Ed
CIPA compliance, age-appropriate filtering, per-grade-level policies.
SaaS
Block competitor scraping tools, shadow IT discovery, IP allowlist enforcement.
Manufacturing
OT/IT segmentation, block unauthorized cloud services on shop floor.
Legal/Professional Services
DLP for client confidential data, audit trail for compliance.
Pricing notes: Bundled with Zero Trust SKUs. Standard tier includes DNS + basic HTTP filtering. Advanced/Enterprise adds DLP, RBI, CASB, deeper inspection. Free for up to 50 users (DNS filtering only).
Gotcha: TLS inspection requires cert distribution — coordinate with MDM/endpoint team early. Pinned-cert apps (some banking, some IoT) won't work through inspection.
Gotcha: Aggressive content categorization can over-block — start with monitoring mode and tune categories before enforcement.
Gotcha: DLP requires Enterprise SKU and careful tuning. Off-the-shelf DLP rules generate false positives — invest in custom data classes.
Gotcha: WARP on Linux works but has fewer features than Mac/Windows. Servers often skipped from Gateway enforcement.
Spotlight: Egress Policies Enterprise

Egress policies decide which IP address Cloudflare uses when traffic leaves Gateway and heads to the internet. By default everybody on Cloudflare One shares a giant pool of source IPs, so an upstream service like a bank API or SaaS partner can't tell your organization apart from anyone else's. Egress policies let you swap that default for a dedicated egress IP that's reserved for your account and route specific traffic through it. That way the upstream service can add your IP to its allowlist and trust traffic from your organization.

What they're used for
  • SaaS allowlists — Microsoft 365, Salesforce, Workday, banking APIs that require connections from known IPs. Route traffic to the SaaS through your dedicated IP, add that IP to their allowlist, done.
  • Geo-based routing — send traffic destined for one region through a regional egress IP for compliance or partner requirements.
  • Identity-driven egress — different user groups can egress through different IPs (e.g., finance team uses one IP for banking partners, engineering uses another).
  • Force IP version — combine with DNS policies that block AAAA or A records to force traffic to IPv4-only or IPv6-only upstream services.
  • BYOIP — bring your own IP ranges and use them as the egress source. Useful when you already have IPs whitelisted everywhere and don't want to update partners.
The two egress methods
MethodWhat it doesWhen to use
Default Cloudflare egress Shared IP pool. Traffic exits from the nearest data center. Best raw performance. General internet browsing where no upstream allowlisting is required.
Dedicated egress IPs (Cloudflare or BYOIP) Static IPs reserved for your account. Primary + secondary IPv4 for failover, IPv6 range. If the primary location goes down, Gateway fails over to secondary. SaaS allowlisting, partner integrations, anything that requires a known stable source IP.
What happens with multiple egress policies (order of enforcement)

This is the question that trips people up. Egress policies — like all Gateway policies — evaluate top-to-bottom in order of precedence. Gateway uses a "first match wins" model: as soon as a request matches an egress policy, evaluation stops and that policy's egress IP is used. Anything below it is ignored for this request.

PrecedencePolicyWhat happens
1 (top)Finance team → Banking partner IPs → Dedicated IP AEvaluated first. If finance user hits banking IP, use Dedicated IP A and stop.
2Destination = Salesforce → Dedicated IP BOnly evaluated if policy 1 didn't match.
3 (bottom)Catch-all → Default Cloudflare egressAnything that didn't match anything above uses the default shared pool.

The catch-all policy at the bottom is the important pattern — without it, unmatched traffic tries to use the closest dedicated egress IP location, which can produce surprising IP assignments. The catch-all explicitly routes leftovers through Cloudflare's default shared range so you keep performance for general traffic and reserve dedicated IPs only for what needs them.

Where egress fits in the broader Gateway flow

When traffic flows through Gateway, the order is roughly: DNS policies → network policies → HTTP policies → egress policies → traffic exits. So egress is the last decision Gateway makes — what source IP to use when sending the request out to the destination. Allow/Block decisions happen earlier; egress is about how allowed traffic leaves.

Anticipated customer questions
"Why can't I just use a static IP from the proxy?"Default Cloudflare egress uses a shared IP pool — your traffic looks identical to every other Cloudflare One customer. SaaS providers can't allowlist you specifically. Dedicated egress IPs solve that by giving you static IPs nobody else uses.
"What if I have two egress policies that could both match?"First match wins. The policy higher in the list (lower precedence number) is used and evaluation stops. Order matters — put the most specific policies at the top.
"What happens if my dedicated egress IP's data center goes down?"Gateway fails over to the secondary IPv4 address you configured. If you set secondary to 0.0.0.0, traffic routes to the location closest to the user. If you set a specific secondary location, traffic uses that.
"Can I bring my own IPs (BYOIP)?"Yes. If you already have IPs whitelisted by partners, you can have Cloudflare announce those IPs and use them as egress sources. Means zero allowlist changes at upstream services during migration.
"Does this affect performance?"Default Cloudflare egress is the most performant (closest data center). Dedicated egress IPs add a routing constraint — traffic exits from the specific data center the IP belongs to, which may not be the closest one to the user. Catch-all at the bottom keeps general traffic fast.
"How do I see if my policies are working?"Gateway activity logs show which egress policy matched each connection. Customer can verify by checking what IP the upstream service sees (most SaaS providers log this).
"What identity signals can I use to pick the egress IP?"User email, user name, user groups (by ID, name, or email), SAML attributes. Plus traffic attributes like source/destination IP, ports, geolocation, domain, host, application, content category, and device posture.
Common gotchas
Gotcha: No catch-all policy means unmatched traffic tries to use the closest dedicated egress IP location. Always add a catch-all "use default Cloudflare egress method" policy at the bottom to keep general traffic fast and predictable.
Gotcha: Cloudflare doesn't publish dedicated egress IP ranges publicly. You won't find them at cloudflare.com/ips — contact your account team to get the actual IPs assigned to your organization.
Gotcha: Application, Content Categories, Domain, and Host selectors require additional setup (Traffic and DNS mode, PAC files, or Browser Isolation). Don't promise these in a deal scoping call without verifying the customer's onboarding mode supports them.
Gotcha: Terraform provider v4 hashes precedence values (a precedence of 1000 may become 1000901), which breaks reordering. Use Terraform v5 or manually set precedence via the Update Zero Trust Gateway rule API.
Gotcha: Secondary IPv4 is required for resilience. If the primary data center goes down and there's no secondary configured, traffic drops. Always set either a specific secondary location or 0.0.0.0.
Gotcha: Egress policies only run on traffic going to the public internet. Traffic to private networks via Cloudflare Tunnel, Magic WAN, or Mesh doesn't egress — it stays within the Cloudflare network and the egress policy doesn't apply.
Pricing notes: Egress policies themselves are an Enterprise Zero Trust feature. Dedicated egress IPs are a paid add-on — typically priced per IP / per region. BYOIP has its own setup process and may have different pricing. Confirm with your account team for the customer's specific deal.
Where to find it in the dashboard
Zero Trust (opens separate dashboard)
Gateway shares the Zero Trust dashboard with Access. Same place: one.dash.cloudflare.com.
  • Traffic policies → Firewall policies — DNS, Network, and HTTP filtering rules. Block by category, domain, application, IP, port, file type, etc. Order matters (first match wins).
  • Traffic policies → Resolver policies — custom DNS resolution rules (route specific domains to specific resolvers).
  • Traffic policies → Egress policies — control which IP traffic exits from. Requires Dedicated Egress IPs add-on.
  • Traffic policies → Traffic settings — global Gateway settings (TLS inspection, block page, certificate management).
  • Reusable components → Lists — reusable lists (domains, IPs, URLs, hashes) referenced by policies.
  • Data loss prevention → Profiles — sensitive data detection patterns (PII, PCI, custom regex). Reference in HTTP firewall policies.
  • Browser isolation — configuration for Remote Browser Isolation policies and settings.
  • Cloud & SaaS findings — CASB results: misconfigurations and data exposure across M365, Google Workspace, Salesforce, etc.
  • Integrations → Cloud & SaaS — connect SaaS apps for CASB scanning.
  • Insights & Logs → Logs — every DNS query, HTTP request, and policy decision. Logpush to SIEM.
Note: Cloudflare reorganized the Zero Trust dashboard recently. The old "Gateway" parent menu is now "Traffic policies." DLP moved to its own top-level section. Lists moved under "Reusable components."

CASB (Cloud Access Security Broker)

What
Continuously scans SaaS apps (M365, Google Workspace, Salesforce, GitHub, Slack, AWS, GCP, Azure, etc.) for misconfigurations, risky data sharing, exposed credentials, and policy violations.
Why
Companies have hundreds of SaaS apps. Each one has its own security settings, sharing controls, admin permissions, integration risks. Someone in marketing makes a public Google Drive folder. A dev pushes an API key to a public GitHub repo. An admin enables external sharing in M365 by accident. CASB finds these problems by scanning the apps directly via API, no traffic interception required.
Say"CASB is how Cloudflare gives you visibility into the security posture of your SaaS apps. You know how every company is using Microsoft 365, Google Workspace, Salesforce, GitHub, Slack, AWS, plus 50 other SaaS tools — and each one has its own settings, its own sharing controls, its own user permissions? CASB connects to those apps via API, scans the configuration continuously, and flags problems. Things like 'this Google Drive folder is shared with the entire internet', 'this GitHub repo has an AWS access key committed,' 'this M365 admin role has way more users than it should,' 'this Salesforce object has externally-shared records with PII in them.' It's not preventing those things from happening — it's giving you the dashboard to find them and fix them. And because it's API-based, it works even if users access SaaS apps without going through Gateway. The catch is it's a posture / detection tool, not real-time blocking. For real-time, you pair it with Gateway (HTTP inspection of SaaS traffic) and DLP."
Customer Scenario The setup:A scale-up SaaS company has grown from 50 to 500 employees in two years. They use Google Workspace, Slack, GitHub, Salesforce, M365 (a few exec holdouts), and ~30 other SaaS tools. No formal SaaS security program. The pain:A pen-test found AWS access keys committed to a public GitHub repo, a Google Drive folder containing the customer database shared "anyone with link," and a Salesforce report with externally-shared customer PII. The CISO realized there was no way to know how many more issues existed. What they built:Connected CASB to Google Workspace, GitHub, Salesforce, and Slack via API. CASB scanned configuration and produced a findings list — 240+ posture issues ranked by severity. They prioritized the bleeding ones, set up policies to alert when new ones appear, and ran quarterly remediation sprints. The outcome:Closed the four critical findings the pen-test had spotted plus 38 more they hadn't known about. Ongoing alerts mean new issues are caught within hours instead of "whenever the next pen-test happens." This was a major piece of evidence at their next SOC2 audit.
Objection: "We have Microsoft Defender for Cloud Apps / Netskope CASB""Defender for Cloud Apps is a real product, especially strong if you're M365-heavy. Netskope CASB is a mature standalone CASB. Cloudflare CASB is competitive on integration depth for common apps (M365, Workspace, GitHub) and gets stronger with the rest of the Cloudflare One stack — Gateway + DLP + Access in one platform. If you're already buying Cloudflare One for SWG and ZTNA, adding CASB removes a vendor."
Objection: "Doesn't this require us to give Cloudflare admin access to our SaaS apps?""Yes — CASB authenticates via OAuth or admin API tokens with read-only or scoped permissions. Standard pattern across all CASB products. Required because that's how API scanning works."
Deep Dive — CASB
How it actually works
  • API-based connection: Connect each SaaS app via OAuth or admin token. Cloudflare scans configuration, users, permissions, sharing settings, integrations.
  • Continuous scanning: Scans run on a schedule (typically daily) and surface findings. New misconfigurations show up automatically as they're created.
  • Finding categorization: Each finding rated by severity (critical / high / medium / low) and type (data exposure, misconfiguration, identity risk, integration risk).
  • Remediation guidance: Each finding includes the actual setting / object affected, plus guidance on how to fix it.
  • Inactive user detection: Surfaces stale accounts (no login in N days) that should be deprovisioned.
  • Shadow integrations: Finds OAuth apps users have authorized that you don't know about (e.g. random extension that has access to all Gmail).
  • SaaS apps supported: M365, Google Workspace, Salesforce, GitHub, GitLab, Slack, Atlassian, Box, Dropbox, AWS, GCP, Azure, Workday, Zendesk, ServiceNow, more. List growing.
  • Integration with Gateway and DLP: CASB findings can trigger Gateway policies. DLP profiles can scope to specific SaaS apps surfaced by CASB.
Anticipated customer questions
"What's the most common 'wow' finding?"Externally shared files containing sensitive data — Google Drive folders shared 'anyone with the link' that contain PII, financial data, source code. Or AWS S3 buckets misconfigured public. Or GitHub repos with leaked secrets. These are the findings that get budget approved.
"How is this different from SSPM (SaaS Security Posture Management)?"CASB and SSPM overlap heavily — different vendors use the terms differently. Cloudflare CASB does what most people call SSPM (configuration scanning + posture). 'Traditional CASB' also includes inline traffic inspection — Cloudflare does that via Gateway + DLP, not under the CASB product label. Net: combined Cloudflare One coverage = what most call CASB+SSPM.
"How quickly do new findings appear?"Most scans run daily. Critical events (new admin role created, new external share) can be near-real-time depending on app integration. Compare with your incident response window.
"Can it auto-remediate?"Limited today. CASB primarily surfaces findings — humans fix them. Some app integrations support quick-action remediation. Direction of travel: more auto-remediation over time.
"What about non-API SaaS apps?"CASB requires API access. SaaS apps without admin APIs aren't covered by CASB scanning. For those, pair with Gateway HTTP inspection — see what users do, apply DLP and policy at the network layer.
"Pricing?"Per-seat add-on to Cloudflare One. Bundled in some Cloudflare One tiers. Verify with account team.
"Will it find every issue?"No — CASB scans what each app's API exposes. Apps with limited APIs have less visibility. Tunable scan rules vs out-of-box rules vs custom rules — Cloudflare's library expanding.
"vs Wiz / Orca for cloud posture?"Wiz/Orca are CNAPP — broader cloud security posture (workloads, vulnerabilities, runtime). Cloudflare CASB focuses on SaaS configuration. Some overlap on AWS / GCP / Azure config scanning; Wiz / Orca much deeper for cloud workloads. Different categories — both might be in a customer's stack.
Industry angles
SaaS
Scan their own SaaS stack — find leaks of customer data via external sharing in Google Drive / Slack / GitHub. Audit OAuth apps users authorized.
Fintech / Regulated
Continuous posture validation for compliance (SOC 2, ISO 27001). Find externally shared files containing financial data. Detect inactive privileged accounts.
Healthcare
HIPAA posture: find PHI in misconfigured shares. Detect overly-permissive M365 / Workspace settings. Audit BAA-covered app configurations.
Tech / Dev
GitHub secret scanning, OAuth app review, AWS / GCP / Azure config drift detection.
Manufacturing / Retail
Salesforce / Workday posture, contractor account hygiene, third-party integration audit.
Pricing: Per-seat add-on to Cloudflare One Zero Trust. Sometimes bundled in higher Cloudflare One tiers. Verify with account team.
Gotcha: Requires admin API access to each SaaS app — provisioning takes coordination with SaaS admins.
Gotcha: Scan coverage limited by each app's API surface. M365 / Workspace coverage deepest; long-tail SaaS apps less complete.
Gotcha: Findings volume can be overwhelming initially. Best practice: prioritize critical+high, triage in waves.
Gotcha: CASB is detective control, not preventive. Pair with Gateway + DLP for inline blocking.
Gotcha: Auto-remediation limited — most findings require human action. Build remediation workflow into your security ops process.
Where to find it in the dashboard
Zero Trust Cloud & SaaS findings
  • Findings — all detected issues across connected apps. Filter by app, severity, finding type.
  • Integrations → Cloud & SaaS — connect SaaS apps via OAuth / admin token. Configure scan scope.
  • [Finding] → Details — affected object, severity, remediation steps, links into the source app.
  • Reports — aggregate compliance / posture reports for sharing with audit.
Cloudflare reorganized: the CASB findings live under "Cloud & SaaS findings" in the Zero Trust dashboard. Integration setup under Integrations → Cloud & SaaS.

DLP (Data Loss Prevention)

What
Scans web traffic (via Gateway) and SaaS app content (via CASB) for sensitive data — credit cards, SSNs, PII, source code, custom patterns — and applies policies: log, alert, block, encrypt.
Why
Sensitive data leaving an organization is the #1 source of compliance violations and breach reporting requirements. Traditional DLP requires endpoint agents and content-aware proxies. Cloudflare DLP runs in Gateway and CASB — so any traffic going through Cloudflare One gets inspected without endpoint work.
Say"DLP is data loss prevention — it stops sensitive information from leaving the company through risky channels. The classic use case: somebody copy-pastes a customer's credit card number into a personal Gmail draft. Or uploads a spreadsheet of employee SSNs to a personal Dropbox. Or pastes proprietary source code into ChatGPT. Traditional DLP requires installing agents on every endpoint, which is expensive and breaks frequently. Cloudflare DLP works differently — it lives inside Gateway, which means any web traffic flowing through Cloudflare One gets inspected. So if a user is on WARP and they try to upload PII to an unsanctioned destination, the upload gets blocked (or logged, or alerted, depending on policy). It also works alongside CASB to scan data at rest in SaaS apps — find PII sitting in shared Google Drive folders, detect customer data in Slack messages. The big patterns are preventing leaks to unsanctioned cloud storage, blocking sensitive data going to public AI tools, and finding existing data leaks in SaaS apps. Pre-built detectors cover the obvious stuff (credit cards, SSNs, passport numbers, healthcare IDs across countries). Custom detectors handle company-specific data like customer IDs or internal classifications."
Customer Scenario The setup:A healthcare technology vendor handles PHI under HIPAA. They allowed employees to use ChatGPT for productivity but had no enforcement on what could be pasted in. The pain:An internal audit found three employees had pasted patient data into ChatGPT (anonymized, but barely). One had copy-pasted a real customer support email containing names and dates of birth. Legal flagged this as a HIPAA reportable incident risk. They needed to block this before it became an actual breach. What they built:DLP policies running through Cloudflare Gateway. Pre-built detectors for HIPAA-related identifiers (MRN format, NPI, common PHI patterns) blocking uploads or pastes to ChatGPT, Claude, Gemini, and any uncategorized AI tool. Custom detector for their internal patient ID format. Pair with CASB for scanning Google Drive and Slack for existing PHI exposure. The outcome:Active blocking of PHI to AI tools — incidents went from "discovered in audit weeks later" to "blocked at the moment, employee gets a coaching message." Legal team got a defensible answer for the next compliance review. CASB scans cleaned up ~80 historical PHI exposures in Slack/Drive.
Objection: "We have Symantec / Forcepoint / Digital Guardian DLP""All legitimate enterprise DLP tools, especially strong on endpoint coverage. Cloudflare DLP is the network-layer answer — covers web/SaaS traffic without endpoint agents. Many customers run both: legacy DLP for endpoint file movements (USB, local copying), Cloudflare DLP for web/cloud-bound traffic. Cloudflare's bet: more sensitive data moves via web/SaaS every year, so the network-layer DLP grows more valuable over time."
Objection: "Won't DLP slow down web traffic?""DLP inspection runs at Cloudflare's edge — same network path as Gateway. Single-digit ms typical overhead. Less impact than endpoint DLP which inspects locally. The real performance gotcha is over-scanning everything — best practice is policy targeting (scan uploads to unsanctioned destinations, skip approved cloud apps)."
Deep Dive — DLP
How it actually works
  • DLP Profiles: Reusable sets of data patterns to detect. Built-in profiles for credit cards, SSNs, passport numbers, healthcare IDs (HIPAA), GDPR-relevant PII, financial data per country.
  • Detection methods: Regex patterns (credit cards, SSNs), keyword dictionaries (medical terms), exact data matching (upload your customer ID list, detect those specific values), document fingerprinting (detect known sensitive documents).
  • Gateway HTTP policies: Reference DLP profiles in HTTP policy rules. Action: log, alert, isolate (RBI), block, allow with notification.
  • CASB integration: DLP scans content at rest in SaaS apps via CASB connections. Find files in Google Drive containing credit card numbers, etc.
  • OCR for images: Detect PII in screenshots and image-based documents.
  • Context-aware policies: Combine DLP detection with user identity, destination, time of day. "Block SSN uploads to non-corporate domains for users not in Finance group."
  • Logpush integration: DLP events to SIEM. Each detection includes match details, action taken, user, destination, traffic context.
  • Exact Data Match (EDM): Upload structured data (customer IDs, employee records) — DLP detects those exact values, not just patterns. Way fewer false positives than regex.
Anticipated customer questions
"What pre-built detectors are included?"Credit cards (PCI), US/EU/Canada/Australia/UK SSNs and tax IDs, passport numbers, drivers licenses, healthcare IDs (HIPAA-relevant), GDPR PII categories, banking IBAN, AWS / GCP / Azure secret patterns, common API key formats. Library expanding.
"Can we write custom detectors?"Yes — custom regex patterns, keyword dictionaries, exact data matching for company-specific data. Common: detect internal classification tags ("CONFIDENTIAL", "PROPRIETARY"), customer ID formats, employee badge numbers.
"How does Exact Data Match work?"Upload structured data — e.g. CSV of customer SSNs. DLP hashes the values and detects matches in inspected traffic. Much higher precision than regex (regex flags any 9-digit number as SSN — EDM only flags your actual customers' SSNs).
"AI/ChatGPT use case?"Hot topic. Common policy: DLP scans all uploads to AI chat domains (ChatGPT, Claude, Gemini, Copilot). Block sensitive data, allow benign queries. Pair with Gateway category filtering for full Shadow AI control.
"False positive rate?"Regex-based detectors have inherent false positives (any 9-digit number could be an SSN). EDM dramatically reduces false positives. Tuning: start with log-mode, observe matches, refine to reduce false positives, then move to block.
"Pricing?"Per-seat add-on to Cloudflare One Zero Trust. Often bundled in higher tiers. Verify with account team.
"Does it work without WARP / Gateway?"DLP inspection requires traffic to flow through Gateway. Methods: WARP client (per-device), PAC files, Gateway proxy mode, Magic WAN connector. For SaaS-at-rest scanning, only CASB connection needed (no Gateway).
"Decryption / TLS inspection?"Required for HTTP DLP — DLP needs to read the request body. Gateway terminates TLS, scans content, re-encrypts to origin. Some domains can be bypassed (banking, healthcare apps) for privacy. Roll out TLS inspection carefully — root cert pushed to managed devices.
Industry angles
Fintech
Card data egress prevention, PII outflow to personal accounts, source code leak detection. Compliance with PCI / GLBA.
Healthcare
PHI detection across uploads, downloads, SaaS scanning. HIPAA compliance posture. Block uploads to personal cloud storage.
Tech / SaaS
Source code DLP, API key / secret detection. Prevent leaks of customer data to AI tools.
Legal
Privileged document protection, client confidential data, M&A material detection.
Regulated
Any company under regulatory exposure (GDPR, CCPA, HIPAA, PCI) — DLP is mandatory for both audit and breach prevention.
Pricing: Per-seat Cloudflare One add-on. Sometimes bundled in higher tiers. Verify with account team.
Gotcha: Requires traffic flowing through Gateway (WARP, PAC, Magic WAN). Bypassed traffic isn't inspected.
Gotcha: TLS inspection required for HTTP body inspection — root cert must be deployed to managed devices. Plan rollout carefully.
Gotcha: Regex-based detectors have false positives. Use Exact Data Match for high-precision detection.
Gotcha: Privacy concerns from inspection — some destinations (banking, healthcare apps) often bypassed for compliance/privacy. Customer should decide policy with legal/compliance.
Gotcha: Rollout pattern: start in log/alert mode, observe matches, tune detectors, move to block. Going straight to block creates user friction and false-positive blowback.
Gotcha: DLP doesn't cover endpoint-only file movements (USB, local copy, screenshots to personal email via desktop client). For those, pair with endpoint DLP.
Where to find it in the dashboard
Zero Trust Data loss prevention
  • Profiles — manage pre-built and custom DLP detectors. Reusable across policies.
  • Datasets — Exact Data Match — upload structured data for high-precision detection.
  • Detection patterns — custom regex, keyword dictionaries, document fingerprints.
  • Settings — global DLP options, payload logging, false positive reporting.
Zero Trust Traffic policies → Firewall policies → HTTP
  • HTTP policies — reference DLP Profiles in HTTP rule selectors. Set action (log / alert / isolate / block).
DLP got its own top-level menu after the Zero Trust dashboard reorganization. Used to live under Gateway.

Magic WAN / Magic Transit Enterprise

Magic WAN
SD-WAN replacement — connect offices/DCs/cloud through Cloudflare's backbone.
Magic Transit
L3 DDoS scrubbing for entire IP ranges — all traffic, not just HTTP.
Say"Magic WAN is for companies with multiple offices or locations that need to connect them all together. Traditionally, companies pay phone companies a lot of money for what's called MPLS — basically private network lines between their buildings. It works, but it's expensive, slow to change, and adding a new office takes weeks. Magic WAN replaces that with our network. Each office just needs a regular internet connection, and we route traffic between your locations over our backbone, which is 500 terabits per second. New office? Set it up in hours instead of months. You also get our DDoS and firewall protection on every site automatically. There's a sister product called Magic Transit which does the same thing for protecting your servers — DDoS protection for any kind of network traffic, not just websites. Customers typically save 30 to 70% versus MPLS."
Customer Scenario The setup:A regional restaurant chain with 180 locations. Each restaurant has a POS network connected to corporate HQ via MPLS through a national carrier. They were paying ~$1.4M/year for MPLS. The pain:Bringing up a new location took 6-8 weeks for the carrier to provision a circuit. MPLS bandwidth was capped low (under 50 Mbps per site) because higher tiers cost a fortune. When the carrier had an issue, individual restaurants went dark for hours. And the chain's expansion plan called for 40 new locations in 18 months. What they built:Replaced MPLS with Magic WAN. Each restaurant gets a cheap commodity broadband line, plus a small Magic WAN connector device. Traffic between sites and HQ now goes over Cloudflare's backbone. Magic Firewall handles per-site policy. New site brings up in hours, not weeks. The outcome:Annual networking spend dropped from $1.4M to around $500K — roughly 60% savings. Each location got 10x the bandwidth at lower cost. The expansion plan got back on track because new restaurants no longer waited for carrier provisioning. Magic Transit on top of that protects HQ from network-layer attacks.
Objection: "MPLS works""It works — expensively and inflexibly. New sites take weeks. Magic WAN spins up in minutes over any internet connection."
How this differs from regular Cloudflare securityRegular Cloudflare security protects individual websites — somebody points DNS at us, we proxy their HTTP traffic, we filter out attacks. That's great for web apps but it only covers the HTTP/S in front of one zone at a time. Magic Transit is a completely different model. The customer announces their entire IP space (like a whole /24) to Cloudflare via BGP, which essentially tells the internet "the route to these IPs goes through Cloudflare first." Every packet headed for those IPs — HTTP, gaming traffic, VoIP, internal protocols, anything — hits one of our 330 data centers before reaching the customer's actual network. We inspect each packet's header in under a millisecond, drop the malicious ones, and forward clean traffic back to the customer through encrypted GRE or IPsec tunnels. So instead of protecting one website, we're protecting their entire network infrastructure — and the customer's real server IPs stay hidden from the public internet, which means attackers can't bypass Cloudflare to hit the origin directly. The DDoS dilution effect is massive too: a 2 Tbps attack against one IP gets spread across 330 PoPs, so no single point of the network ever sees more than a few Gbps of attack traffic. That's how we mitigate attacks bigger than most customers' total internet capacity.
Deep Dive — Magic WAN / Magic Transit
How it actually works
  • On-ramps: IPsec tunnel (any router), GRE tunnel, Cloudflare Network Interconnect (CNI — direct peering at major IXs), WARP Connector (software gateway in any environment).
  • Magic Transit: Customer announces their IP space to Cloudflare via BGP. We attract traffic via anycast, scrub L3/L4 DDoS, forward clean traffic via GRE/IPsec back to customer.
  • Magic WAN: Same on-ramps but for branch/cloud connectivity — all sites are peers on Cloudflare's backbone, routing decisions made centrally.
  • Magic Firewall: L3/L4 firewall at the edge — IP allow/block, geo blocks, port/protocol filtering. Stateful inspection.
  • Magic NS (DNS): Authoritative DNS over the same control plane.
  • Network Interconnect: Private peering with Cloudflare at hundreds of locations. Includes direct connect to AWS, GCP, Azure, Oracle Cloud — bypass public internet.
  • SD-WAN integrations: Native partnerships with Aruba, Versa, VMware/VeloCloud, Fortinet, Cisco Meraki, Aryaka. Plug existing SD-WAN into Cloudflare.
  • Capacity: 500+ Tbps backbone. Same network for security and connectivity — no separate platforms.
Anticipated customer questions
"How does this replace MPLS?"Every site gets an internet connection (any ISP) + IPsec/GRE tunnel to nearest CF PoP. Traffic between sites routes over our backbone. Cost: typically 30-70% lower than MPLS.
"What about latency vs MPLS?"Often better — our backbone is optimized for latency, and Argo Smart Routing finds the fastest path. Comparable or better than MPLS in most geographies.
"How is this different from Aryaka / Cato Networks?"Cato and Aryaka are SASE-native competitors. Differentiators for us: larger network (330+ PoPs vs Cato's ~80), unified with WAF/DDoS/CDN/Workers, lower TCO at scale. Cato is more mature on some SD-WAN features.
"vs Cisco SD-WAN?"Cisco's strength is the appliance ecosystem and partner network. We're cloud-native — no appliance refresh cycles. Often pair: Cisco SD-WAN at the branch terminates into our backbone.
"vs AWS Cloud WAN?"Cloud WAN is AWS-region-centric. Magic WAN is multi-cloud, multi-site, with security built in. Magic Transit explicitly protects AWS workloads (we sit in front of your AWS Direct Connect).
"How long to deploy?"First site: ~1 hour (tunnel config + routing). Phased rollout to 50 sites: typically 4–8 weeks. Compared to MPLS: months.
"BGP requirements for Magic Transit?"You need your own IP space (/24 or larger for IPv4) and ASN. We help with ARIN/RIPE coordination if needed.
"Can we keep existing firewalls?"Yes — Magic Firewall layers in front. Many customers use both: cleanup at the edge, deep inspection at branch.
"What about cloud connectivity?"CNI to AWS/Azure/GCP — private interconnect, no public internet hops. Direct Connect / ExpressRoute / Cloud Interconnect partnerships.
"Failover/redundancy?"Multiple tunnels to multiple PoPs from each site. Automatic failover. Anycast means the IP itself is redundant.
"Audit and visibility?"Flow logs (NetFlow-style), real-time analytics, packet captures (Enterprise). Logpush to SIEM.
Industry angles
Retail/Ecommerce
Store connectivity — every location gets reliable, secure backhaul without MPLS. POS isolation, PCI scoping.
Manufacturing
Plant connectivity, OT/IT segmentation via Magic Firewall, secure remote engineer access via Tunnel.
Healthcare
Clinic-to-data-center connectivity, HIPAA-compliant private routing, integration with hospital EHR cloud.
Fintech
Magic Transit for L3 DDoS on bank-of-the-internet IP ranges. Low-latency CNI to public cloud.
Gaming
Magic Transit for game server IP space, sub-second mitigation across all sites simultaneously.
Media
Studio-to-studio file replication, broadcaster CDN backbone, satellite uplink protection.
Pricing notes: Enterprise only. Magic WAN priced by site count + bandwidth commit. Magic Transit by protected IP space + bandwidth commit. Magic Firewall typically bundled. CNI is per-location physical port + included with sufficient commit.
Gotcha: Magic Transit requires your own IP space + ASN. Customers using cloud-provided IPs need a different architecture (e.g., reverse proxy via CDN).
Gotcha: Some applications don't tolerate the GRE/IPsec overhead well (chatty protocols over high-latency links). Test before mass migration.
Gotcha: Migration off MPLS requires coordination with telco contracts — often 12-month contract overlap during phased cutover.
Gotcha: If branches have very low bandwidth or unreliable internet, internet-based WAN is risky — keep MPLS for critical sites or use dual-WAN with SD-WAN partner.
Where to find it in the dashboard
Network → Magic WAN / Magic Transit
All network-level products live under the Network section in the left nav. ENT-only — only visible with proper entitlement.
  • Magic WAN → Sites — branch / DC sites. IPsec or GRE tunnel configs, BGP peering, static routes.
  • Magic WAN → Connectors — WARP Connector deployments for cloud / virtual sites.
  • Magic WAN → Network Interconnect — direct private peering at IX locations.
  • Magic Transit → Prefixes — IP space announced to Cloudflare via BGP. Status of advertised prefixes.
  • Magic Transit → Tunnels — GRE / IPsec tunnels back to customer infrastructure.
  • Magic Firewall → Rules — L3/L4 firewall policies applied at the network edge.
  • Network Analytics — flow logs, top sources/destinations, attack analytics.

Magic NS (DNS)
If enabled, authoritative DNS managed alongside Magic WAN.

Spectrum (TCP/UDP Proxy)

What
Extends Cloudflare's DDoS protection, load balancing, and edge proxying to any TCP or UDP protocol — not just HTTP/S. Gaming servers, MQTT, SSH, custom protocols, FTP, SMTP, anything with a port.
Why
Cloudflare's standard zone proxying only covers HTTP/S. But customers run non-HTTP services that also need DDoS protection and edge acceleration — game servers, IoT brokers, email servers, custom application protocols. Spectrum is the answer: open a port on Cloudflare's edge, get DDoS/proxy/LB benefits for that protocol.
Say"Spectrum is how Cloudflare protects everything that isn't HTTP. The default Cloudflare CDN / proxy is HTTP/S only. But a lot of important stuff runs on other protocols — game servers on UDP, MQTT for IoT, SSH for remote admin, SMTP for mail servers, custom binary protocols for trading systems. Spectrum extends Cloudflare's edge to those. You point your protocol's clients at a Cloudflare IP, Cloudflare proxies the TCP or UDP traffic to your origin, and along the way you get the same anycast DDoS protection that protects every HTTP zone. Plus load balancing, geo-steering, and a real-time analytics dashboard. The classic case is gaming — Minecraft servers, Roblox-style platforms, multiplayer game lobbies. Pre-Spectrum these companies built custom DDoS protection at huge cost. Now they get it from us by default."
Customer Scenario The setup:A multiplayer mobile game studio runs game servers on UDP with custom binary protocol. Player count peaks at ~80K concurrent. They host on bare-metal providers in three regions. The pain:Competitors had figured out their server IPs and were launching DDoS attacks during major tournament events. Each attack cost them $20-40K in lost in-app purchases plus reputation damage. Their bare-metal provider's DDoS protection was HTTP-focused and didn't handle the UDP game traffic well. What they built:Routed UDP game server traffic through Spectrum. Clients connect to Cloudflare anycast IPs, Spectrum forwards to the game servers (whose real IPs are now hidden). Anycast DDoS protection from the 500 Tbps network kicks in automatically on any volumetric attack. The outcome:The next attack — a 300 Gbps UDP flood during a tournament — never reached the game servers. Players didn't notice. Server IPs are now hidden behind Spectrum so even the attackers' previous targeting data is useless. Tournaments stopped being attack windows.
Objection: "Doesn't Magic Transit cover this?""Different tier. Spectrum is per-application — you configure specific ports per origin. Magic Transit is at the IP layer — Cloudflare announces your IP range via BGP and scrubs DDoS for everything coming to those IPs. Spectrum: 'protect my game server on port 25565.' Magic Transit: 'protect this entire /24 of my network.' Spectrum is much simpler to set up; Magic Transit is enterprise-scale infrastructure."
Objection: "What's the latency impact?""Single-digit ms added at Cloudflare edge. For latency-critical workloads (real-time gaming, trading), Spectrum's anycast routing often improves end-to-end latency because traffic terminates at nearest PoP, not at origin region. Real-world impact varies — test for your specific use case."
How this differs from regular CloudflareRegular Cloudflare protection assumes everything is a website — somebody types acme.com, their browser makes an HTTPS request, we proxy it through our WAF and DDoS scrubbing, and forward to the origin. That whole pipeline only works because HTTP is a well-defined protocol we can inspect, cache, and filter. But the internet runs on more than HTTP. Game servers use UDP for real-time gameplay. IoT devices use MQTT. Mail servers use SMTP. Banks have custom binary protocols for market data. None of that fits the standard CDN model. Spectrum extends Cloudflare's edge to any TCP or UDP protocol on any port. You tell us "my Minecraft server is on TCP port 25565 at origin.acme.com," we open that port on our anycast IPs, and every connection to it gets the same DDoS protection that protects every HTTP zone. The difference from Magic Transit is scope — Magic Transit announces your whole IP range via BGP for whole-network protection. Spectrum is per-application, per-port. So it's simpler to set up (no BGP, no IP space requirements) but narrower — you have to configure each app explicitly. Gaming companies, IoT platforms, financial firms, and email providers are the biggest Spectrum users. Pre-Spectrum, these companies built custom anti-DDoS at enormous cost. Now they point their clients at a Cloudflare IP and get it by default.
Deep Dive — Spectrum
How it actually works
  • Per-application config: Define a Spectrum app — protocol (TCP or UDP), edge port, origin host + port, IP routing pattern.
  • Anycast edge IPs: Same anycast IPs as the rest of Cloudflare. Clients connect to nearest PoP automatically.
  • Origin proxying: Cloudflare receives the TCP/UDP connection at the edge, opens a connection to your origin, proxies traffic bidirectionally.
  • DDoS protection: Cloudflare's 500 Tbps network absorbs L3/4 attacks at the edge. Same protection as HTTP zones get for free.
  • Load balancing: Spectrum apps can use Cloudflare Load Balancing — multiple origins, health checks, failover, geo-steering.
  • Argo support: Argo Smart Routing accelerates Spectrum traffic too — finds fastest path to origin.
  • Authenticated origin pull: mTLS between Cloudflare and origin — only Cloudflare can connect to origin.
  • PROXY protocol: Cloudflare adds PROXY protocol v1 / v2 header so origin sees real client IP, not Cloudflare IP.
  • TLS support: For TLS-wrapped protocols (SMTPS, IMAPS, etc.), Cloudflare can terminate TLS or pass through to origin.
Common use cases
  • Gaming: Minecraft (TCP 25565), Roblox-style multiplayer, custom game servers. Anti-DDoS critical — gaming is heavily targeted.
  • SSH: Protect bastion / jump hosts behind Cloudflare. Some customers pair with Access for SSH-over-Access.
  • SMTP: Mail servers behind Cloudflare DDoS. SMTP 25, 465, 587, 993, 995.
  • IoT / MQTT: Brokers handling millions of device connections. UDP and TCP MQTT.
  • FTP: Legacy file transfer protected behind Spectrum.
  • Custom binary protocols: Financial / trading APIs, telemetry collectors, anything TCP/UDP-based.
  • Database tunneling (with caution): Postgres, MySQL exposed via Spectrum — usually paired with mTLS and IP allowlisting.
Anticipated customer questions
"What protocols are supported?"Any TCP or UDP protocol. Cloudflare doesn't inspect L7 (with exceptions for known protocols like SSH where Cloudflare optionally adds telemetry). For TLS-wrapped protocols, Cloudflare can either terminate or pass through.
"What about ports — any port number?"Spectrum supports a wide range of TCP/UDP port numbers. Verify specific port availability with Cloudflare — some restrictions (e.g., port 25 for SMTP has anti-abuse rules).
"Origin IP — does it stay hidden?"Yes — clients connect to Cloudflare anycast IP. Origin IP exposed only to Cloudflare. Standard Cloudflare-fronted origin pattern.
"Real client IP at origin?"PROXY protocol v1 or v2 forwards original client IP. Origin must speak PROXY protocol to use it. Most modern servers support PROXY natively or via plugin.
"vs Magic Transit?"Different scope. Spectrum: per-application, configure specific ports/origins. Magic Transit: BGP-level, Cloudflare announces your IP space and scrubs DDoS for everything on those IPs. Pick Spectrum for specific apps; Magic Transit for entire networks.
"Latency for real-time gaming?"Anycast routes traffic to nearest PoP — typically faster than direct-to-origin for global customers. Edge-to-origin path can be optimized with Argo Smart Routing. Real numbers vary; benchmark for your customer base.
"Pricing?"Tiered by plan. Business: includes some Spectrum apps for specific use cases. Enterprise: usage-based or committed capacity. Get specific pricing from account team.
"DDoS limits — is there a cap?"No cap on attack size. Cloudflare's 500 Tbps network absorbs any attack ever recorded. Same unmetered DDoS guarantee as HTTP zones.
Industry angles
Gaming
Anti-DDoS for game servers. Multiplayer matchmaking, voice chat servers, game lobbies. Volumetric attacks are common in gaming; Spectrum is foundational.
IoT
MQTT brokers, device telemetry endpoints. Millions of persistent device connections protected at edge.
Fintech / Trading
Custom binary protocols for market data. mTLS between client and edge, edge and origin. Low-latency anycast routing.
Email / Communications
SMTP, IMAPS, custom messaging protocols. Anti-DDoS critical — mail infrastructure is heavily targeted.
Remote access
SSH bastions, RDP gateways, VPN concentrators. Combined with Access for identity gating.
Pricing: Business plan: limited Spectrum allowance for specific use cases. Enterprise: usage-based or commit-based, custom pricing. Discuss with account team.
Gotcha: Per-app pricing — for customers with many ports / many apps, costs add up vs Magic Transit's flat IP-range pricing.
Gotcha: Some protocols have anti-abuse restrictions (SMTP port 25) — discuss with Cloudflare before deploying.
Gotcha: Origin must accept connections from Cloudflare IP ranges (or use Tunnel for outbound-only). Allowlisting required.
Gotcha: PROXY protocol support required at origin for real client IP — without it, origin sees Cloudflare IPs.
Gotcha: Spectrum doesn't do deep packet inspection (L7) for non-HTTP protocols — DDoS protection is L3/4 only. For application-layer attack protection on custom protocols, build at origin.
Gotcha: UDP support varies by use case. Some UDP protocols have quirks (statelessness, asymmetric routing) — test with Cloudflare for non-trivial UDP apps.
Where to find it in the dashboard
Per-zone [Domain] → Spectrum
  • Spectrum apps — list of configured TCP/UDP proxies on this zone.
  • Add application — protocol, edge port, origin host:port, IP type (CNAME / fixed IP), TLS settings, PROXY protocol toggle.
  • [App] → Settings — IP firewall rules, traffic type, edge / origin TLS, authenticated origin pull.
  • [App] → Analytics — connection volume, bandwidth, geographic distribution.
Account Home → Account-level Spectrum analytics (for multi-zone aggregation)

R2 (Object Storage) Free tier + Paid

What
S3-compatible object storage, zero egress fees.
Why
Serving content globally with S3 means painful egress bills. R2 removes that line item.
Say"R2 is where you store files — images, videos, documents, backups, anything. If you've heard of Amazon S3, R2 does the exact same thing, with one huge difference: we don't charge you when you read your data back. With Amazon, every time a user downloads a file or your app pulls data, you pay for that. It's called egress fees, and for any company serving a lot of content, it's brutal — usually way more than the storage itself costs. With R2, reading is free. Always. We've had customers cut their storage bill by 60 to 80% just by switching. And because R2 works with all the same tools as S3, migrating is usually a weekend project. We even have a tool that copies your stuff over for you."
Customer Scenario The setup:A video education platform stores ~2 PB of course videos in AWS S3, served to learners globally. They use CloudFront in front of S3 for delivery. The pain:S3 egress to CloudFront, plus CloudFront egress to users — the storage bill was $9K/month, the egress bill was $94K/month. Total $1.2M/year, growing as their library grew. The CFO had been asking pointed questions for two quarters. What they built:They migrated to R2 using Super Slurper — the bulk copy tool — over 4 days with no downtime. Their app didn't change because R2 is S3-compatible, just a new endpoint. They put Cloudflare's CDN in front of R2 for delivery (also no egress charge from R2 to the CDN). The outcome:Egress bill went from $94K/month to zero. Storage bill went from $9K/month to about $30K/month (R2 storage is slightly more per GB than S3 standard, but who cares when egress is free). Total bill dropped from $1.2M/year to roughly $360K/year — about a $840K annual swing.
Objection: "Migration sounds painful""S3-compatible — most tools work unchanged. Use Super Slurper for bulk migration. Most customers move in a weekend without downtime."
How this differs from regular CloudflarePeople hear "Cloudflare" and think CDN — the thing that caches your website's images so they load fast worldwide. R2 is something completely different. It's not a cache, it's primary storage. You're putting files INTO Cloudflare and reading them back out, treating us as the authoritative source of truth for the data, not a layer in front of S3. The economics are also fundamentally different from the rest of our stack. Most Cloudflare products are bundled by plan tier (you pay for Pro / Business / Enterprise and get features included). R2 is usage-based — you pay for storage by the GB and operations by the million, like AWS S3. The headline number — zero egress — isn't a CDN-style "we cache for free" promise. It's a structural decision Cloudflare made when designing R2 to compete with AWS by removing the line item that hurts customers most. So when you think about R2, don't compare it to the CDN — compare it to S3, GCS, Azure Blob Storage, Backblaze B2. Same job, different economics. And because R2 is integrated with the rest of our platform, you can do things you can't do on S3: bind a bucket directly to a Worker (sub-millisecond reads, no network round-trip to AWS), serve a bucket through a custom domain with built-in CDN, route events through Queues to trigger downstream processing. The S3 compatibility means you can drop R2 in as a replacement; the integration means you can do new things once you're there.
Deep Dive — R2 / Object Storage
How it actually works
  • API: S3-compatible — works with AWS SDKs, boto3, aws-cli, Terraform AWS provider (with custom endpoint). Most S3 tools work unchanged.
  • Storage classes: Standard (single-region, multi-zone redundancy). Infrequent Access (cheaper storage, slightly higher read cost). No "Glacier"-equivalent — designed for active data.
  • Location hints: Specify region (WNAM, ENAM, WEUR, EEUR, APAC, OC) for data residency. Auto-replicates within region.
  • No egress fees: Reading data is free regardless of where it goes. This is the headline differentiator vs S3.
  • Public buckets: Expose bucket via custom domain — built-in CDN, no extra config. Or via r2.dev for testing.
  • Workers integration: Bind R2 bucket to Worker — read/write objects directly without HTTP overhead. env.MY_BUCKET.get('key').
  • Event notifications: Object create/delete events → Queues → trigger Workers. Build event-driven pipelines.
  • Super Slurper: Migration tool — bulk copy from S3, GCS, Azure Blob, generic S3-compatible. Incremental sync.
  • Sippy: Lazy migration — points R2 at S3, reads pull through and cache. Eliminates upfront migration cost.
  • Object Lock: Immutability for compliance — WORM (write-once-read-many).
  • R2 Data Catalog: Managed Apache Iceberg catalog built into R2 (public beta). Turns a bucket into a queryable lakehouse. See R2 Data Catalog entry.
  • Pipelines: Real-time data ingestion product (pricing announced May 2026). Stream events into R2 with optional SQL transforms before storage. $0.04/GB SQL transforms + $0.03/GB sink delivery; free ingress.
  • R2 SQL: Serverless distributed query engine for data stored in R2 Data Catalog. $2.50/TB scanned with free tier on all plans. Query Iceberg tables without standing up Spark / Snowflake.
Anticipated customer questions
"What's the cost vs S3?"Storage: $0.015/GB/mo (vs S3 $0.023). Class A ops (write): $4.50/M (vs S3 $5/M). Class B ops (read): $0.36/M (vs S3 $0.40/M). Egress: $0 (vs S3 ~$0.09/GB). Egress is where most customers save heavily.
"Migration approach?"Super Slurper for bulk one-shot. Sippy for lazy migration (zero downtime, pay as you read). Most teams use combination.
"What about durability?"11 9's of durability target — same as S3 Standard. Multi-zone redundancy within region.
"Data residency?"Location hints (WEUR, EEUR for European data, etc.) keep data in region. Important for GDPR.
"What about backup / versioning?"Object versioning supported. Lifecycle rules (delete after N days, transition to IA). Cross-bucket replication available.
"Performance vs S3?"For Workers integration: dramatically faster (no network round-trip to AWS). For external clients: comparable. R2's edge proximity helps reads.
"What's the upper limit on object size?"5 TiB per object via multipart upload. Single PUT: 5 GiB.
"Compliance?"SOC2 Type II, ISO 27001, GDPR. HIPAA BAA available. PCI compatible.
"Can we use existing tools (Rclone, Cyberduck, etc.)?"Yes — anything S3-compatible. Configure custom endpoint URL pointing to R2.
"What about Glacier-style archival?"No deep archive tier today. Infrequent Access is cheaper storage but still online. For true archive, customers often pair R2 active + external archive.
"Pre-signed URLs?"Yes — same S3 pre-signed URL pattern. Expiring time-limited links.
Industry angles
Media
Huge egress savings for video/asset delivery. Public buckets via custom domain = built-in CDN. Stream integration.
SaaS
User-uploaded files, document storage, customer data lakes. Workers integration for in-line processing.
Gaming
Patch distribution, user-generated content, replay storage. Egress savings on multi-GB downloads is significant.
Fintech
Compliance documents, statements, audit trails. Object Lock for immutability. Encrypted at rest.
Healthcare
DICOM imaging, document storage. BAA available. Location hints for data residency.
AI/ML
Training data lakes, model artifacts, inference outputs. Workers AI + Vectorize + R2 = full AI stack.
Pricing notes: Free tier: 10 GB storage, 1M Class A ops/month, 10M Class B ops/month, zero egress. Paid: pay-as-you-go usage-based. Infrequent Access tier ~50% cheaper storage with slightly higher read cost. Enterprise: committed-use discounts.
Gotcha: R2 ≠ S3 in every detail. Some less-common S3 features missing (Glacier deep archive, S3 Select, Object Lambda). Validate compatibility for edge-case workloads.
Gotcha: Class A operations (writes/lists) are more expensive than reads — write-heavy workloads should be modeled carefully.
Gotcha: Multi-region replication is available but isn't single-bucket multi-region by default — design with region in mind.
Gotcha: If reading from R2 to non-CF compute, latency may be worse than co-located S3. Best for serving end-users or use with Workers.
Where to find it in the dashboard
R2 Object Storage
R2 has its own top-level section in the left nav.
  • Overview — total storage, classes A/B operation counts, top buckets.
  • Buckets list — all your buckets across locations.
  • [Bucket name] → Objects — browse / upload / download objects via UI. Useful for spot checks; bulk operations via API.
  • [Bucket name] → Settings — public access, custom domains, CORS, lifecycle rules, location hint.
  • [Bucket name] → Metrics — request rates, latency, error rates.
  • [Bucket name] → Event Notifications — wire create/delete events to Queues / Workers.
  • Data Migration → Super Slurper — bulk migration jobs from S3/GCS/Azure.
  • Data Migration → Sippy — lazy migration (read-through caching from source).
  • Manage R2 API Tokens — create scoped access keys (S3-compatible).
  • Catalog (R2 Data Catalog) — Iceberg catalog for analytics workloads.

R2 Data Catalog Public Beta

What
Managed Apache Iceberg catalog built into R2. Turns an R2 bucket into a queryable data warehouse or lakehouse.
Why
Data teams want to query object storage as structured tables without spinning up Glue Catalog, a Hive Metastore, or a third-party catalog service. And they want to do it without paying egress every time Snowflake or Databricks reads the data.
Say"R2 Data Catalog turns your R2 bucket into a real data warehouse. Here's the problem it solves — modern data teams store huge amounts of analytics data in object storage as Parquet files, but raw files aren't queryable on their own. You need something called a table format on top, and the open standard there is Apache Iceberg. Iceberg gives you database-style tables — schemas, ACID transactions, time travel — but stored as files in your bucket. The catch is Iceberg needs a catalog to track which files belong to which table. Most companies run their own catalog service or pay for AWS Glue. We built one straight into R2, so the moment you flip a switch on a bucket, it's an Iceberg catalog. Then you point Snowflake, Databricks, Spark, DuckDB, whatever you use, at our catalog, and they query your data directly out of R2. No egress fees. No catalog to maintain. And because the engines are bringing their own compute, you only pay for storage and the queries they run on their side."
Customer Scenario The setup:An ad-tech company runs a data lake on AWS S3 — billions of ad events per day in Parquet. Snowflake on top for analyst queries. AWS Glue as the catalog. The pain:Snowflake's external table queries to S3 incurred AWS egress every time. The data team's bill from AWS — S3 storage plus egress when Snowflake queried — was about $180K/year on top of Snowflake's own bill. Glue was an ongoing pain to maintain. What they built:Migrated the data lake from S3 to R2. Flipped on R2 Data Catalog so the bucket became an Iceberg catalog automatically. Pointed Snowflake at R2 via the Iceberg catalog. Same Parquet files, same Snowflake queries, just a different storage backend with no egress fees. The outcome:The $180K/year AWS bill went to ~$30K/year in R2 storage. Snowflake bill unchanged because it's still doing the compute. Glue retired. Data team got back the operational time they'd been spending on Glue. The CFO loved the line-item swap.
Objection: "We already use AWS Glue Catalog""Glue works, but it's tied to AWS — and every cross-region or cross-cloud query against your S3 data hits egress. R2 Data Catalog plus zero egress means Snowflake in Azure, Databricks in GCP, and a Spark cluster in your own data center can all query the same R2 tables for free. The catalog itself is open Iceberg REST, so you're not locked in — any Iceberg-compatible engine works."
Objection: "Is this production-ready?""It's in public beta today, so be honest with customers about that. The Iceberg spec it implements is rock-solid and widely adopted. Cloudflare's catalog implementation is what's still maturing. For exploratory workloads, log analytics, and second-tier analytics it's a great fit right now. For mission-critical primary data warehouse, wait for GA or run it alongside the existing setup."
Deep Dive — R2 Data Catalog
How it actually works
  • Iceberg table format: Apache Iceberg is an open table format for big analytics data. Think "database table, but the data is Parquet files in object storage." Supports ACID transactions, schema evolution (add/rename/drop columns without rewriting data), time travel (query the table as of yesterday), partition evolution.
  • What a catalog does: Iceberg tables are stored as a tree of files in your bucket — data files plus metadata files. Something has to track which metadata file is the current one for each table. That's the catalog. Without it, engines can't safely share tables (concurrent writes corrupt the table).
  • R2 Data Catalog interface: Implements the open Iceberg REST catalog spec. Any Iceberg engine that speaks REST catalog can connect — Spark, Snowflake, Databricks, Trino, DuckDB, PyIceberg, ClickHouse, Starburst, Dremio.
  • Enablement: Per-bucket. Flip the catalog on for a bucket, get an API endpoint and warehouse name, authenticate engines with an R2 API token. Tables stored as Iceberg files inside that bucket.
  • Compute model: The catalog is just metadata. The actual query compute runs in whatever engine the customer chooses (their Snowflake, their Databricks, their Spark cluster). Cloudflare isn't running queries — Cloudflare is serving the metadata and the underlying R2 data.
  • Zero egress is the wedge: Iceberg's whole pitch is decoupling storage from compute. R2's zero egress means you can decouple them across clouds without getting murdered by transfer fees. Snowflake in AWS reading R2 data is free egress. Databricks in Azure reading R2 data is free egress.
  • Multi-engine concurrency: Iceberg's ACID guarantees mean multiple engines can read/write the same table safely. Without a catalog, this breaks.
Anticipated customer questions
"What is Iceberg, in one sentence?"An open table format that lets you treat files in object storage like database tables — with schemas, transactions, and time travel. Created by Netflix, now an Apache project, supported by basically every modern analytics engine.
"What engines work with it?"Anything that speaks Iceberg REST catalog. Spark, Snowflake (read), Databricks (read), Trino, DuckDB, PyIceberg, ClickHouse, Starburst, Dremio. Cloudflare publishes config examples for the common ones.
"How is this different from just using S3 + Glue?"Same architectural pattern. Differences: (1) zero egress when querying from outside AWS, (2) catalog is included with R2 not billed separately, (3) catalog is open Iceberg REST not AWS-specific, (4) one less service for the customer to manage.
"How is this different from Snowflake or BigQuery?"Snowflake and BigQuery are full warehouses — storage plus compute plus query engine, all bundled. R2 Data Catalog is just the storage and catalog layer. Customers bring their own compute (could be Snowflake itself querying R2 tables externally). Cheaper for storage-heavy workloads, more flexible, more DIY.
"What's the pricing?"In public beta, the catalog itself isn't billed — you only pay for the underlying R2 storage and operations. Pricing post-GA hasn't been announced.
"Can we write to tables from multiple engines?"Yes — Iceberg's ACID guarantees support concurrent writes. The catalog coordinates so engines don't step on each other.
"What about time travel and schema evolution?"Both are core Iceberg features and work as expected. Query a table as of a specific snapshot timestamp. Add, rename, drop columns without rewriting data files.
"How does authentication work?"Engines connect using an R2 API token scoped to the bucket. Standard token-based auth.
"Can we migrate existing Iceberg tables in?"If your Iceberg data is already in R2 (or you migrate it via Super Slurper / Sippy), you can register existing tables with the catalog. If it's in S3 today, migrate the data to R2 first.
"Is there a query engine included?"No — catalog only. Customers bring their own engine. This is intentional: Cloudflare is the storage and metadata layer, not the compute layer.
Industry angles
SaaS
Customer event data, product analytics, billing events. Decouples your warehouse from any single vendor — write once to R2, query from Snowflake, Databricks, or homegrown engine.
AdTech
Massive event volumes (impressions, clicks, conversions). Egress costs to ship data into BigQuery or Snowflake can be brutal. R2 + Catalog keeps storage cheap, lets analytics tools query in place.
Gaming
Telemetry, player behavior, A/B test data. High-volume, time-series, mostly queried via Spark or DuckDB. R2 Catalog fits naturally.
Fintech
Transaction logs, market data archives, compliance retention. Iceberg's time travel and schema evolution are valuable for regulated long-retention data.
Multi-cloud orgs
This is the killer use case. Storage in R2, compute spread across AWS Snowflake, Azure Databricks, on-prem Spark — all reading the same tables without egress charges.
Pricing notes: Public beta — catalog itself is not currently billed. You pay standard R2 storage and operations only. Post-GA pricing TBD.
Gotcha: Public beta. Don't position as the sole catalog for a customer's primary production warehouse yet. Great for second-tier analytics, log analytics, exploratory workloads.
Gotcha: Catalog only — no query compute included. Customers need to already have or stand up an Iceberg-compatible engine (Spark, Snowflake, Databricks, DuckDB, etc.).
Gotcha: Iceberg has a learning curve. Customers new to lakehouse patterns will need help understanding table formats, catalogs, and engine integration before this is useful to them.
Gotcha: Snowflake reads external Iceberg tables, but writes from Snowflake to external Iceberg are limited. Validate write patterns against the customer's engines.
Where to find it in the dashboard
R2 Object Storage → [Bucket name] → Settings → Catalog
  • Enable catalog — flips R2 Data Catalog on for the bucket. Surfaces the catalog URI and warehouse name.
  • Catalog URI / Warehouse name — paste these into your Iceberg engine config (Spark, Snowflake external volume, Databricks Unity Catalog external, etc.).
  • R2 API tokens — scope a token to the bucket; engines use it to authenticate against the catalog.
  • Tables — once engines start writing, tables appear here for browse and inspection.

Stream

What
Upload → transcode → globally delivered video. Adaptive bitrate. No separate CDN.
Say"Stream is a video platform — you upload a video, we do everything else. We process it into the right formats, deliver it globally, and give you a player that automatically adjusts quality based on the viewer's internet speed. You can also do live streaming. The simple part is the pricing — you pay per minute of video stored and per minute watched. That's it. No charges per view, no bandwidth surprises if something goes viral. If you tried to build this yourself on AWS, you'd be paying for like five different services and each one can spike. Most customers use Stream for product demos, training videos, online courses, or live events — anywhere you need video that's branded as yours instead of going through YouTube."
Customer Scenario The setup:A corporate training company sells online courses to enterprises. ~3,000 videos in their library, growing every week. They host on AWS — S3 for storage, MediaConvert for transcoding, CloudFront for delivery, plus a homegrown player. The pain:Their AWS bill on the video stack was unpredictable — sometimes $4K/month, sometimes $14K when an enterprise customer's whole team binged a course launch. They had no idea how to forecast it. The homegrown player was buggy on mobile. Adaptive bitrate was inconsistent. What they built:Migrated all 3,000 videos to Stream. Replaced the homegrown player with Stream's embeddable player. Killed the MediaConvert + CloudFront + S3-for-video stack. Pricing now is per minute stored + per minute watched, predictable and linear with usage. The outcome:Video bill became predictable — they can model it against subscription revenue. Player quality on mobile improved noticeably (adaptive bitrate just works). Two AWS services and a small engineering ownership area got retired. Onboarding a new enterprise customer no longer triggers a "wait is our bill about to spike?" Slack thread.
Objection: "We use YouTube/Vimeo""Those are consumer platforms. With Stream you control the experience — no ads, no related videos, no branding. Plus integrates with CF access controls."
Deep Dive — Stream
How it actually works
  • Upload: Via dashboard, API (TUS resumable), or direct creator upload (signed upload URL). Up to 30 GB per video.
  • Encoding: Automatic transcode to HLS + DASH, multiple bitrates (1080p, 720p, 480p, 360p), H.264 + AV1.
  • Delivery: Adaptive bitrate streaming from Cloudflare edge. Built-in player or use your own (Video.js, HLS.js, Shaka).
  • Live streaming: RTMP or SRT ingest. Outputs HLS for playback. Low-latency mode (sub-second LL-HLS) available.
  • Signed URLs: Time-limited tokens for paywalled/private content. JWT-based.
  • Watermarking: Burned-in image watermarks per playback.
  • Analytics: View counts, playback duration, geographic distribution, drop-off rates per video.
  • Captions: Upload SRT/VTT, or use auto-generated captions (Whisper-powered, multiple languages).
  • DRM: Widevine, FairPlay, PlayReady for premium content (Enterprise).
  • Live recording: Live streams auto-saved as on-demand videos.
Anticipated customer questions
"What's the pricing model?"Two metered components: minutes stored + minutes delivered. ~$5/1000 min stored + ~$1/1000 min delivered. No per-view, no egress, no transcoding fees.
"How does this compare to Mux?"Mux has deeper analytics and customizable encoding. We're simpler and unified with our platform (R2, Workers, Images, CDN). Pricing competitive — both flat per-minute models.
"vs JW Player / Brightcove?"Those are full-featured enterprise platforms with marketing/monetization features. We focus on developer-first video infrastructure — simpler API, lower cost.
"vs AWS Elemental + CloudFront?"AWS is component-based — MediaConvert + S3 + CloudFront + IVS — each metered separately. Costs add up. Stream is one flat per-minute price including encoding, storage, delivery.
"Can we use our own player?"Yes — HLS/DASH manifests work with any standard player. Or use ours (open-source, customizable).
"Live streaming quality?"Multi-bitrate ABR, low-latency mode (~2s glass-to-glass with LL-HLS), instant replay (re-watch live streams within 24h).
"DRM available?"Yes — Widevine, FairPlay, PlayReady. Enterprise pricing.
"What about ads / monetization?"SSAI (server-side ad insertion) integrations available. Not a built-in ad server — pair with Google Ad Manager or similar.
"Geographic restrictions?"Country-based blocking via signed URL params or Workers in front of stream.
"How fast is upload-to-playable?"VOD: typically 1-3x video length for encoding (1 hour video ready in 1-3 hours). Live: instant (5-10s buffer).
Industry angles
EdTech
Course videos, paid content via signed URLs, analytics on completion rates. Captions for accessibility.
Media/News
Live news broadcasts, on-demand archives. Built-in CDN scales for breaking news spikes.
SaaS
Product demos, in-app tutorials, training content. Replace YouTube embeds with branded experience.
Gaming
Tournament streaming, replay storage, creator content. Low-latency mode for interactive streams.
Religious / Community
Live service streaming, archived sermons, multi-campus broadcast.
Fitness
On-demand workout libraries, live class streaming. Signed URLs for subscriber-only access.
Pricing notes: $5 per 1000 minutes stored, $1 per 1000 minutes delivered. Free trial credits available. Enterprise: commit-based pricing with discount, DRM included, dedicated support.
Gotcha: No native ad server — bring your own. SSAI integrations exist but require integration work.
Gotcha: DRM is Enterprise — if customer needs Widevine/FairPlay, that's a separate conversation.
Gotcha: Live encoder requirements: customer needs RTMP-capable encoder (OBS, vMix, Wirecast, hardware). Not turnkey "webcam-only" out of box.
Gotcha: For very high-volume linear/broadcast workflows (24/7 channels), dedicated streaming platforms may have more mature features.
Where to find it in the dashboard
Stream
Stream is a top-level item in the left nav.
  • Videos — all uploaded videos. Drag-and-drop upload, generate signed URLs, view analytics per video, download MP4 source.
  • Live Inputs — RTMP / SRT ingest URLs. Create live inputs, view recording settings, manage low-latency mode.
  • Analytics — total minutes delivered, top videos, geographic distribution, drop-off rates.
  • Settings → Stream API tokens — create API tokens scoped to Stream.
  • Settings → Storage / Delivery — usage breakdowns and pricing dashboard.
  • Stream Player — embed code generator, customization options.
  • Webhooks — notify your app on video state changes (ready, errored, recording started/stopped).

Email Security

What
Inline, pre-delivery email security. Catches phishing, BEC, lookalikes.
Say"Email Security catches phishing emails before they ever reach your team's inboxes. We sit in front of your email server, so every message gets checked first. If it's bad, we block it — your employees never even see it. Most email security tools work the other way — the bad email arrives, then they try to pull it back after, but by then somebody might've already clicked. We also look at the infrastructure behind every email — who sent it, where the website link actually goes, whether the sender's domain was registered yesterday. Microsoft and Google's built-in protection catches maybe 70-80% of phishing. We catch the sophisticated stuff they miss — like somebody pretending to be your CEO asking for a wire transfer, or a fake invoice from a vendor whose account got hacked. According to the FBI, business email compromise is the number one cybercrime by dollars lost. One blocked wire fraud email can pay for this product for years."
Customer Scenario The setup:A construction company — 1,800 employees, M365 for email, Microsoft Defender for email security. Lots of accounts payable activity involving wire transfers to subcontractors and vendors. The pain:They got hit with a business email compromise attack — attacker spoofed a regular vendor's email asking to update banking details for the next wire. AP processed it. $340K went to the wrong account. The bank recovered most but not all. Cyber insurance covered the rest but premium jumped at renewal and underwriting demanded better email security. What they built:Added Cloudflare Email Security in front of M365 (works alongside Defender, not a replacement). Cloudflare scans every inbound message — sender authentication, domain age, link analysis, behavioral context like "this 'vendor' has never asked us to change banking info before." Defender keeps catching the easy stuff; Cloudflare catches the BEC and supply-chain attacks. The outcome:In the first 90 days, Cloudflare blocked 14 BEC attempts that Defender had let through. One was another banking-detail-change attempt that would've cost ~$120K. Cyber insurance underwriting noted the upgrade. AP team has a much clearer signal when something is real vs. spoofed.
Objection: "We use Microsoft's built-in""M365 protection catches basic spam well, sophisticated phishing maybe 70-80%. BEC, lookalike domains, vendor compromise often slip through. Cloudflare Email Security focuses there — that's what we acquired Area 1 to do."
Objection: "We have Proofpoint/Mimecast""Similar category — the differentiator is pre-delivery detection and integration with Cloudflare's global threat intelligence across web and email."
Deep Dive — Email Security
How it actually works
  • Deployment modes: (1) Inline via MX record — emails route through Cloudflare first, blocked emails never reach Microsoft/Google. (2) API integration with M365 / Google Workspace — post-delivery quarantine without changing MX. (3) BCC/journaling for visibility.
  • Pre-delivery detection (inline mode): The key differentiator. We see and block malicious emails before they hit the inbox. Most competitors quarantine after delivery.
  • Detection methodology: Sender infrastructure analysis (not just content). We crawl the open internet, identify phishing campaigns being assembled before they launch, fingerprint sender behavior across millions of inboxes.
  • Detection categories: BEC (business email compromise), credential phishing, malware, lookalike domains, vendor compromise (legitimate vendor accounts taken over), conversational attacks (slow-build trust), wire fraud.
  • Attachment sandboxing: Detonate suspicious attachments in isolated VM, observe behavior, score.
  • URL rewriting + time-of-click: Rewrites URLs in emails; re-checks at click time (catches links that go bad after delivery).
  • Browser Isolation integration: Suspicious links open in remote browser — even if user clicks, threats can't reach endpoint.
  • Auto-quarantine: Post-delivery remediation — if a threat is detected after delivery (vendor compromise, weaponized URL), retroactively pulls from inboxes.
  • Phishing simulation: Cloudflare Sentinel — built-in phishing training campaigns.
Anticipated customer questions
"How is this different from M365 Defender / Google built-in?"Built-ins catch 70-85% of phishing on average. Sophisticated attacks — BEC, lookalikes, vendor compromise — often slip through. Cloudflare Email Security's pre-delivery + infrastructure analysis catches what content-based filtering misses. Independent benchmarks (SE Labs, Tolly) show 99%+ catch rates.
"How is this different from Proofpoint?"Proofpoint is the incumbent leader — strong product. Our differentiators: (1) pre-delivery detection (Proofpoint mostly post-delivery on M365), (2) infrastructure-based detection model (catches new campaigns before they go widely), (3) integration with broader Cloudflare platform (Browser Isolation, Gateway).
"vs Mimecast?"Mimecast is mature with email archiving + continuity. Our focus is detection. Customers sometimes pair us (detection) with Mimecast (archive) or our R2 storage.
"vs Abnormal Security?"Abnormal is a direct competitor — also API-based behavioral detection. Strong product. Differentiators: our pre-delivery (MX-based) deployment option, integration with broader CF platform, often more aggressive pricing.
"How does deployment work?"Two paths: (1) Change MX record to route through Cloudflare first (highest catch rate, ~1 hour deployment). (2) API integration with M365/Google (no MX change, ~15 min, slightly lower catch rate).
"What about false positives?"FP rate <0.1% in benchmarks. Quarantined emails go to admin review queue. Users can request release. Tunable per detection category.
"Does this work with our DLP?"Email Security + Gateway DLP catches data exfiltration via email. Outbound scanning available.
"What about encrypted email?"S/MIME and PGP encrypted content can't be inspected — same limitation as every email security vendor. We catch the sender infrastructure even if payload is encrypted.
"Compliance / data residency?"SOC2 Type II, ISO 27001, HIPAA BAA available. Regional processing available for EU customers.
"What about phishing training?"Built-in via Cloudflare Sentinel (phishing simulations + user training). Or integrate with KnowBe4, Proofpoint Security Awareness, etc.
"Inbound only or also outbound?"Primary focus inbound. Outbound DLP via Cloudflare Gateway DLP. Some customers extend to outbound for data leak prevention.
"What about M365 native vs add-on?"Microsoft pushes Defender for O365 P2 ($5/user/mo addition). Independent assessments consistently show third-party (Cloudflare Email Security, Abnormal, Proofpoint) outperform native — especially for BEC and lookalikes.
Industry angles
Fintech
BEC is the #1 fraud vector. Wire transfer fraud, vendor invoice fraud, exec impersonation. Pre-delivery detection critical.
Healthcare
PHI exfiltration via phishing, ransomware delivery via email. HIPAA-aligned deployment.
Manufacturing
Supply chain phishing, vendor compromise — attackers piggyback on legitimate vendor accounts to redirect payments.
Professional Services / Legal
Client confidentiality at risk from spear phishing. Wire fraud during real estate transactions is a major BEC pattern.
Education
Student credential phishing, payroll fraud (W-2 scams). High-volume, low-resource IT — fully managed service appealing.
SaaS
Customer support inbox attacks, OAuth grant phishing (subtle and dangerous), credential theft of admin accounts.
Pricing notes: Per-mailbox per-year typically. Tiered by deployment mode (API vs MX inline) and add-ons (Attachment Sandbox, Browser Isolation, Phishing Sim, Auto-Quarantine). Volume discounts at scale. Often replaces 2-3 existing tools (filter + sandbox + training) for similar/lower total cost.
Gotcha: MX-record changes have email delivery implications. Plan migration carefully — usually staged with mail flow rules.
Gotcha: API mode (M365/Google) has slightly lower catch rate than MX inline because some emails reach the inbox briefly before being pulled. Most customers eventually move to MX inline.
Gotcha: Doesn't replace email archiving / eDiscovery — that's a separate concern. Pair with Mimecast Archive or M365 archiving.
Gotcha: Phishing simulation features are newer than dedicated vendors (KnowBe4). If customer is heavily invested in awareness training, keep that vendor.
Gotcha: S/MIME and PGP-encrypted emails can't be content-inspected. Some regulated industries have edge cases.
Where to find it in the dashboard
Email Security (opens dedicated portal)
Email Security has its own portal — historically built on the Area 1 acquisition. Click "Email Security" from the main dashboard nav.
  • Overview / Dashboard — threats blocked, top campaigns, detection summary.
  • Detection Search — search across all inbound email by sender, subject, recipient, disposition. Investigation workhorse.
  • Detection Settings — disposition rules per threat category (BEC, phishing, malicious, spam, suspicious). Choose Block / Quarantine / Allow / Tag.
  • Auto-Move (Quarantine) — configure post-delivery quarantine for M365/Google.
  • Allow / Block Lists — sender allow lists, custom rules, IP-based controls.
  • Domain Settings — your protected domains. SPF/DKIM/DMARC status. Authentication configuration.
  • Submission — user-reported phishing review queue.
  • PhishGuard / Phishing Simulations — training campaigns (Cloudflare Sentinel).
  • Reports — exportable summaries for executive / compliance reporting.

Zone Email → Email Routing
Separate product — for forwarding emails on your domain (no mail server needed). Not Email Security.

Cloudflare for SaaS

Also known as
SSL for SaaS • Custom Hostnames • Apex Proxying for SaaS
What
Lets a SaaS platform offer custom domains to their end customers, with automated SSL certificate issuance, validation, renewal, and routing — at the scale of thousands or millions of hostnames.
Who buys it
Any platform where end customers want to use their own branded domain instead of a subdomain on the SaaS. Ecommerce (Shopify-style stores), website builders (Webflow, Carrd), help desks (Help Scout), email marketing (Mailchimp), checkout pages (Stripe), publishing platforms (Notion, Substack), and many more.
Core capabilities
Custom Hostnames • Automated SSL via Let's Encrypt or Google Trust Services • TXT and HTTP validation • Apex domain proxying via dedicated anycast IPs • Per-hostname analytics • API and dashboard for lifecycle management • Custom origin certificates / mTLS to origin • BYOC (bring your own certificate)
Say"Cloudflare for SaaS is the product behind something most SaaS platforms eventually need — letting their end customers use their own custom domain instead of being stuck on a subdomain. Think about Shopify letting merchants use `store.merchantbrand.com` instead of `merchantbrand.myshopify.com`, or Webflow letting designers use their custom domain. That sounds simple but is actually really hard to build yourself — you need to validate that the customer owns the domain, issue an SSL cert, renew it every few months, handle failures, and do this potentially thousands of times. Most platforms that try to build it internally end up with a small engineering team dedicated to just keeping it running. Cloudflare for SaaS automates all of that. Customer adds a DNS record, we validate, issue the certificate from Let's Encrypt automatically, route the traffic, keep it renewed, and give you an API to manage the whole thing programmatically. The biggest SaaS platforms in the world — Shopify, Webflow, Notion, Carrd — use this for exactly this reason."
Customer Scenario The setup:A scheduling SaaS — think Calendly-style — has 30,000 paying customers. Their power-user tier ($99/mo) is supposed to include "your own domain" so customers can have `book.theirbrand.com` instead of `theirbrand.schedulingapp.com`. The pain:They tried to build custom-domain support twice. First version was AWS ACM + manual cert issuance. Second was Let's Encrypt + ACME automation. Both broke regularly — cert renewals failed, DNS validation tripped over edge cases, customers' domains went insecure intermittently. Two engineers spent ~30% of their time keeping it running. The feature was so unreliable they almost killed it. What they built:Switched the custom-domain feature to Cloudflare for SaaS. Customers add a CNAME pointing at the SaaS company's hostname. Cloudflare validates ownership, issues the cert, deploys it, renews it forever. The SaaS company calls the Cloudflare API to manage hostnames programmatically — no manual cert handling. The outcome:Cert renewal failures dropped to zero. The two engineers got their time back. Custom domain became reliable enough to actually market — pricing tier conversion went up because the feature finally worked. Adding custom-domain support became a 30-second onboarding step instead of a multi-step nightmare.
Objection: "We built this ourselves and it works""Acknowledge it — many platforms have built their own version. The question worth probing is operational cost. How many engineers does it take to keep running? When was the last certificate renewal failure that hit a customer? How long did debugging take? Most platforms that built this themselves describe it as 'works until it doesn't, and then it's painful.' The shift to Cloudflare is usually about getting that engineering team back to working on the product, not maintaining certificate infrastructure."
Objection: "We use AWS Certificate Manager""ACM works inside AWS but is designed for your own company's certificates, not for SaaS platforms managing certificates for thousands of customer domains. The model breaks at the multi-tenant boundary. Try asking: how many certs are you managing today, how do you handle apex domains, and what does the customer onboarding flow look like? The apex problem is usually the killer — ACM + Route 53 has a limited story for apex domains at multi-tenant scale."
Objection: "What about Let's Encrypt directly?""Let's Encrypt is a great free CA — we actually use it as our primary CA under the hood. What they don't give you is the orchestration: validation flows, renewal automation, multi-tenant management, apex domain support, integration with edge routing, customer-facing error handling. SaaS for Cloudflare is the management layer on top of Let's Encrypt that makes multi-tenant practical. You're not paying for the cert; you're paying for not having to build the management layer."
Objection: "We don't want vendor lock-in""Fair concern. Worth noting: every customer SSL is a Let's Encrypt cert, owned by the customer, valid wherever. If you ever migrated off Cloudflare, your customers still have their domains — you'd just need a new infrastructure path. The lock-in is operational (you built around our APIs) rather than data-locked. Most customers find the operational stickiness worth the tradeoff for not building this themselves."
Objection: "How does pricing scale?""Below about 100 hostnames is typically included with your plan at $0.10 per additional hostname. Above that, pricing scales — for platforms with thousands or millions of hostnames it becomes a custom Enterprise contract. Always have your AM run real numbers based on the customer's actual or projected hostname count before quoting. The honest framing: cheaper than building it yourself with a dedicated engineering team, but it's a real line item at scale."
How this differs from regular CloudflareThe standard Cloudflare model is one company, one zone. You own acme.com, you add it to Cloudflare, we protect and accelerate everything under acme.com. That works great for protecting your own website. Cloudflare for SaaS flips the multi-tenancy. Now YOU'RE the platform — your customers are bringing THEIR domains, and you want every one of those customer-owned domains to flow through your infrastructure with your branding, your SSL, your routing. That's a fundamentally different problem from "protect my one website." It requires automated domain validation (proving each customer actually owns their domain), automated SSL issuance and renewal for every one (potentially millions), apex domain proxying via dedicated anycast IPs (because DNS doesn't allow CNAME at the apex), and a programmable API for your platform to onboard and offboard customer domains as part of your normal product flow. Shopify, Webflow, Notion, Help Scout, Mailchimp, Substack, Stripe Checkout — every SaaS platform you can think of that lets customers use their own domain is solving this problem. The decision is whether to build that multi-tenant cert + domain orchestration yourself (real engineering team, ongoing maintenance, painful renewal failures) or use Cloudflare's version (API call to onboard, certs handled, apex domains work, scales to millions). It's not "Cloudflare protecting your site" — it's "Cloudflare being the multi-tenant edge for YOUR product."
How this relates to SSL/TLSCloudflare for SaaS and SSL/TLS share the same certificate engine under the hood — Let's Encrypt issuance, Cloudflare edge termination, automatic renewals — but they're different products for different jobs. SSL/TLS handles certificates for domains you own (your own website, your own subdomains). Cloudflare for SaaS handles certificates for domains your customers own (their branded URL pointing at your platform). If a customer asks "how do I get HTTPS on my site?" → SSL/TLS. If they ask "how do I let my customers use their own domain on my SaaS?" → Cloudflare for SaaS. Clean analogy: same relationship as Workers vs Workers for Platforms. One runs your code; the other runs your customers' code on your platform. The confusion comes from the naming — "SSL for SaaS" and "Custom Hostnames" both refer to this product, but live in the SSL/TLS dashboard menu. Don't let the menu placement fool you — this is its own product with its own pricing, API, and orchestration model.
Deep Dive — Cloudflare for SaaS
The problem this solves (in detail)

Customers running SaaS platforms eventually face a request: "can my customers use their own domain?" The answer requires solving several non-trivial technical problems:

  • Domain ownership validation — proving the customer actually controls the domain they're claiming, without you having to manually verify each one
  • SSL certificate issuance — getting a valid TLS cert for a domain you don't own
  • Certificate renewal — automatic renewal before expiration, handling failures, alerting on issues
  • Traffic routing — receiving HTTPS traffic for thousands of unrelated domains and routing each to the right backend
  • Apex domains — DNS protocol doesn't allow CNAME at apex; you need a different mechanism for customers wanting `theirbrand.com` (not just `www.theirbrand.com`)
  • Performance — serving SSL handshakes from the customer's nearest edge location, not your origin region
  • Lifecycle management — onboarding new hostnames, deprovisioning when customers leave, handling DNS changes mid-flight
  • Multi-tenant analytics — letting your support team see per-hostname traffic and errors when debugging

Cloudflare for SaaS bundles solutions to all of these.

How it actually works
  • Customer adds a DNS record: Either a CNAME pointing at the SaaS platform's Cloudflare-managed domain (most common), or an A record pointing at dedicated anycast IPs for apex domain support.
  • Cloudflare detects the hostname: Either via API call from the SaaS platform's onboarding flow, or via traffic landing on Cloudflare's edge.
  • Validation: Cloudflare confirms domain ownership using one of two methods. HTTP validation puts a token at a specific URL; the issuing CA fetches it; if it matches, validation passes. TXT validation provides a TXT record value the customer adds to their DNS; the CA reads it. HTTP is faster post-cutover; TXT enables pre-validation before DNS cutover (safer for migrations).
  • Certificate issuance: Free certificate from Let's Encrypt or Google Trust Services. Multiple CAs supported for redundancy.
  • SSL termination: Cloudflare serves the SSL at the edge for that hostname using the issued certificate.
  • Traffic routing: Cloudflare proxies the traffic to the SaaS platform's origin via the configured backend. Multiple origins, weighted routing, and failover all supported.
  • Renewal: Cloudflare attempts renewal well before expiration, retries on failure, alerts the platform via API or webhook if it can't recover.
  • Programmatic management: Full REST API for create/update/delete of custom hostnames. Typical integration is "new customer signs up → SaaS calls Cloudflare API to register their hostname → validation kicks off automatically."
Apex domain handling (the often-overlooked feature)

DNS protocol doesn't allow CNAME records at the apex (root) of a domain. So if a customer wants their actual brand domain like `acmebrand.com` to work — not just `www.acmebrand.com` — you can't use a CNAME. This is a real limitation that affects every multi-tenant SaaS platform.

Cloudflare's solution: Apex Proxying. The SaaS platform is assigned a set of dedicated anycast IPs. Customers add A records at their apex pointing at those IPs. Cloudflare handles routing and SSL just like with CNAMEs.

This is what lets smaller SaaS platforms compete with Shopify-style user experience. Without apex support, customers can only use subdomains. With apex support, they get the cleaner brand experience.

Anticipated customer questions
"How fast does a new custom hostname onboard?"Once the customer's DNS is configured correctly, certificate issuance is typically minutes — sometimes seconds. The longer wait is DNS propagation on the customer's side, which depends on their DNS provider's TTL settings. Usually under an hour, occasionally up to 24 hours.
"What if a certificate fails to renew?"Cloudflare attempts renewal well before expiration, retries automatically on failure, and alerts via API or webhook if it can't recover. The platform's support team gets notified before customer-visible outages happen. Most renewal issues are caused by customer-side DNS or CAA record changes, which are easy to diagnose with the right alerting.
"Can we use this with our existing CDN provider?"Generally not — Cloudflare for SaaS works because Cloudflare is the SSL termination point and traffic proxy. If you want another CDN in front, the architecture gets complex. The typical conversation here is moving the CDN responsibility to Cloudflare too, which is usually the right call for performance and operational reasons.
"Can a customer have both apex and subdomain on the same domain?"Yes. A customer can have `acmebrand.com` (via apex proxying with A records) AND `www.acmebrand.com` (via CNAME) both working through Cloudflare for SaaS simultaneously. Common pattern — apex for the brand domain, www subdomain for the actual application.
"What certificate authority do you use?"Default is Let's Encrypt with Google Trust Services as a backup. Both are publicly trusted, valid in every browser, free. Enterprise customers can configure custom CAs for specific compliance or trust requirements (DigiCert, corporate CAs, etc.). Most customers just use the defaults.
"What's the difference between SSL for SaaS and Cloudflare for SaaS?"Same product. Marketing name has shifted over time. "Cloudflare for SaaS" is the broader product family covering Custom Hostnames + SSL automation + Apex Proxying + analytics. "SSL for SaaS" is sometimes used as shorthand for the certificate piece. Functionally interchangeable in customer conversations.
"How do we migrate our existing custom-domain customers?"Phased approach is standard. Use TXT pre-validation so certs are issued BEFORE customers cut over their DNS. Run both old and new systems in parallel during transition. Validate traffic flows correctly. Then have customers update DNS to point at Cloudflare. Most platforms migrate over weeks to months depending on customer count. Cloudflare's SE team can scope this if you have a real migration to plan.
"Can we use this for internal apps too?"Yes — same mechanism. Some customers use Cloudflare for SaaS for internal apps where employees access tools at custom hostnames, or for partner integrations where each partner gets their own subdomain. The technical pattern is the same as customer-facing.
"How does this compare to building on Fastly or AWS?"Fastly has TLS subscriptions for similar use cases — credible product but smaller network, less mature multi-tenant management. AWS via ACM is designed for your own company's certs, not multi-tenant SaaS — works at small scale but the architectural model breaks for thousands of customer domains. Cloudflare for SaaS is the only widely-adopted product purpose-built for this specific use case at scale.
"What compliance frameworks does it cover?"Cloudflare for SaaS is in scope for our SOC 2 Type II, ISO 27001, and PCI compliance. HIPAA BAA covers it for healthcare customers. For specific certifications a customer needs (FedRAMP, industry-specific), verify with the compliance team.
"What about mTLS for our backend?"Supported. Cloudflare can present a client certificate to the SaaS platform's origin, and the origin can require mTLS. Standard pattern for high-security scenarios where the platform doesn't want to accept unauthenticated traffic from any source.
"Can customers see analytics for their hostname?"The SaaS platform sees per-hostname analytics by default. Some platforms expose a filtered version of these analytics to their end customers — that's a custom build on the platform side using Cloudflare's API.
Industry angles
Ecommerce platforms
Shopify-style stores where merchants want their own brand domain. Apex proxying critical because customers want `acmebrand.com`, not `acmebrand.platform.com`. Combine with WAF and Bot Management for full customer security.
Website builders
Webflow, Carrd, Wix-style. Customer publishes their site, brings their own domain. SSL for SaaS is the standard product for this category.
Help desk / Support platforms
Help Scout, Intercom-style. Custom domains for branded help centers (`help.acmebrand.com`).
Email marketing
Mailchimp-style. Custom domains for branded landing pages, click tracking, unsubscribe flows.
Checkout / payments
Stripe Checkout-style. Custom domains for hosted payment pages that look like the merchant's brand, not Stripe's.
Publishing / content
Substack, Notion, Ghost-style. Custom domains for publications, public docs, knowledge bases.
Developer platforms
API gateways, identity providers, feature flag services. Custom domains for white-labeled developer-facing endpoints.
Healthcare SaaS
Patient portals, telehealth platforms with provider-branded domains. HIPAA BAA covers Cloudflare for SaaS, but validate specific compliance scope.
Pricing notes: Below 100 hostnames is included on all plans at $0.10 per additional hostname. Above 100 hostnames, pricing scales — typically a custom Enterprise contract for platforms with thousands or millions of custom domains. Always have your AM scope real numbers based on the customer's hostname count and growth projections. Don't quote pricing from this doc without confirming current Enterprise tier numbers. Includes Custom Hostnames, automated SSL, apex proxying, custom origin certs, mTLS, analytics, and full API.
Gotcha — DNS provider weirdness: Some customer DNS providers have unusual TTL behavior, restrictive CAA records, or odd validation handling. Most validations work first try; some don't. The platform's support team needs to be ready to help customers debug DNS issues. This operational work doesn't go away with Cloudflare for SaaS — but it's much less than building the whole system.
Gotcha — CAA records can block Let's Encrypt: If a customer has restrictive CAA records on their domain (e.g., only allowing DigiCert), Let's Encrypt validation will fail. Customer needs to add `letsencrypt.org` and/or `pki.goog` to their CAA records, or you switch to a different CA on their hostname. Common blocker, easy fix once identified.
Gotcha — apex requires dedicated IPs: Apex domain support requires assignment of dedicated anycast IPs to the SaaS platform. These IPs become long-term commitments — once customers point at them, you can't easily change them. Plan IP allocation for permanence.
Gotcha — pricing scales: At small scale, Cloudflare for SaaS is essentially free ($0.10 per hostname above 100 adds up slowly). At large scale (100k+ hostnames), it's a real line item. Make sure customers understand the pricing curve before they get to scale.
Gotcha — not every SaaS pattern fits: Platforms requiring deep customization of SSL handshakes (specific cipher suites, custom cert extensions), or with unusual multi-region setups where the edge model doesn't match their architecture, may not be a clean fit. These are rare but real. Worth scoping with SE before committing.
Gotcha — email MX records don't apply: Cloudflare for SaaS handles HTTPS traffic. Customer's email (MX records) and other DNS records are separate concerns. Make sure customers understand that adding their domain to Cloudflare for SaaS doesn't affect their email — just their web traffic.
Where to find it in the dashboard
Zone SSL/TLS → Custom Hostnames
The main configuration screen for Cloudflare for SaaS. Pick the zone that will host your SaaS platform's custom hostnames, then navigate here.
  • Custom Hostnames list — every customer hostname registered to your account, status, certificate state, validation method.
  • Add Custom Hostname — manually register a hostname (most use the API instead).
  • Fallback Origin — configure the default origin that customer traffic routes to. Required setup before custom hostnames will serve traffic.
  • Settings — default certificate authority, validation method preferences, custom origin certificate configuration, BYOC settings.

Account Home → Manage Account → API Tokens
Create scoped API tokens for the SaaS platform's onboarding flow to register and manage custom hostnames programmatically.

Zone Analytics → Performance
Per-hostname analytics: traffic, errors, latency, bandwidth. Filter by custom hostname to see specific customer's data.

Account Home → Plans
For platforms approaching or exceeding free hostname limits, this is where to upgrade to Enterprise contracts that include higher hostname allotments.

Reference — Network / Performance

CDN (Caching) All Plans

Say
"Global caching — serves from nearest PoP instead of your server."

Argo Smart Routing

What
Routes traffic across the fastest available paths in real time. ~30% faster TTFB on dynamic content.
Pricing
Usage-based (per GB). Mitigated attack traffic excluded. Now bundled in Smart Shield.
Say
"Waze for network traffic."

Load Balancing

Say
"Routes to healthiest server; automatic failover."

Speed / Optimizations All Plans

What
Auto-minify, Brotli, image opt, Rocket Loader.

Spectrum Enterprise

What
DDoS + acceleration for non-HTTP (SSH, gaming, MQTT).

Reference — Security

WAF

Diff
Pro = managed rules. ENT = custom rules, advanced rate limiting, exposed creds checks.

DDoS All Plans

Diff
Pro = auto. ENT = Adaptive DDoS + SOC + SLA + Botnet Threat Feed.

Bot Management Enterprise

Diff
Pro/Biz = Super Bot Fight Mode (basic). ENT = ML score 1-99, JA3/JA4, bot family IDs, analytics.

API Shield Enterprise

Includes
Discovery • Schema • JWT • mTLS • Sequence Analytics • Sensitive Data Detection.

Rate Limiting

Tier note
Capability scales sharply by plan. Free/Pro = basic per-IP. Business = per-session, response-based counting. ENT = full request/header fields, 100 rules. ENT+ARL = body inspection, JA3, complexity-based scoring.
Watch out
ARL is a separate ENT entitlement — not automatic with ENT. Verify the contract before promising body/JSON/JA3/complexity-based features.

SSL/TLS All Plans

What
Free certs, auto renewal, full/strict modes.

Advanced Certificate Manager

What
Custom CAs, dedicated IPs, more cert control.

Page Shield

What
Monitors JS on pages — catches Magecart/skimmer supply chain attacks.

Reference — Compute / Serverless

Workers Free + Paid

Workers AI

Pages Free + Paid

Durable Objects

What
Stateful serverless — sessions, coordination, shared state.

Queues

What
Async background jobs.

Containers Enterprise / Beta

What
Run containerized apps on Cloudflare.

Reference — Zero Trust / SASE

Cloudflare Access (ZTNA)

Gateway (SWG)

CASB

What
Scans SaaS (Google, Salesforce, etc.) for exposed data.

Browser Isolation

What
Remote browser — pages never reach the endpoint.

Magic WAN / Magic Transit Enterprise

Magic Firewall Enterprise

What
Network-level firewall at the CF edge.

Cloudflare for Offices Enterprise

What
Plug-in branch device for easy connectivity.

Reference — DNS

DNS (Authoritative) All Plans

Say
"Fastest DNS globally — built-in DDoS protection."

1.1.1.1 (Recursive) Consumer

What
Privacy-first public resolver.

Reference — Observability / Analytics

Cloudflare Observability

What
Logs, metrics, traces for Workers/apps.

Web Analytics Free

What
Privacy-first, no cookies required.

Radar Free (Public)

What
Global internet traffic trends and benchmarks.

Reference — Storage

R2 (Object Storage) Free + Paid

Hook
S3-compatible, zero egress fees.

KV (Key-Value)

What
Global low-latency reads for config/session data.

D1 (SQL)

What
Serverless SQLite-based DB for edge apps.

Reference — Email

Email Routing Free

What
Forwarding from your domain — no mail server needed.

Email Security

Reference — Platform

Cloudflare for SaaS

Also known as
SSL for SaaS, Custom Hostnames, Apex Proxying for SaaS
What
Multi-tenant custom domain support for SaaS platforms. Automated SSL issuance, validation, renewal, and apex proxying.
Pricing
<100 hostnames free, $0.10/additional. Enterprise contracts for thousands+ hostnames.
Reference customers
Shopify, Webflow, Notion, Carrd, Help Scout, Mailchimp, Substack, Stripe Checkout, others.

Reference — Developer Tools

Stream

Images

What
Image optimization, resizing, CDN delivery.

AI Gateway All Plans

What
Proxy in front of any AI provider. Adds analytics, logs, caching, rate limits, retries, fallback. Free.
Works with
OpenAI, Anthropic, Workers AI, Gemini, Bedrock, Azure OpenAI, Mistral, Groq, Cohere, Replicate, more.
— viewing now
— total visits