Most of the effort in standing up a SaaS never touches the product. It goes on the plumbing: the network, the servers, the certificates, the scaling policy, the front-line defences against a hostile internet. Cloudflare's real pitch is that it takes that plumbing off your plate, either as a protective front door for an application you already run, or as the whole platform you build on. Understanding which of those two you are doing, and what you still have to bring yourself, is the difference between a fast, sound launch and a fragile one.
This is a practical guide to using Cloudflare as an accelerator: the two ways to adopt it, the stack of Cloudflare plus the external services you deliberately keep, how to add and manage the WAF and edge rules that protect it, and an honest comparison with AWS and Azure so you can tell when the edge-first approach is the right call and when it is not.
Two ways to adopt it, and choosing the right one
The single most useful thing to get straight before anything else is that there are two quite different ways to use Cloudflare, and people conflate them constantly.
Mode A, the front door. You keep your application exactly where it is, on AWS, on Azure, on a virtual machine, or on-premises, and you put Cloudflare in front of it as a reverse proxy. In this mode Cloudflare gives you authoritative DNS, a global CDN and cache, TLS termination, a web application firewall, bot management and DDoS protection, all without touching your application code or moving your data. This is the fastest possible win and the lowest commitment: it is a configuration change, not a migration. For most existing businesses, this is where Cloudflare starts, and for many it is all they ever need.
Mode B, the whole platform. You build the application itself on Cloudflare: Pages and Pages Functions for the application and its server-side logic, D1 for state, Workers AI for inference, Turnstile for human verification. There is no origin server at all. This mode is where the "no servers, nothing to patch" story lives, and it is a strong fit for a greenfield SaaS built by a small team, because it removes an entire category of operational work. It also asks more of you architecturally, which I will come to.
The choice is not ideological. If you have a working application and a competent platform team, Mode A gets you protection and performance in an afternoon and you carry on as you are. If you are starting something new, or you are a small team without the appetite to run infrastructure, Mode B lets you ship the product instead of the plumbing. Many organisations run both: the new service on the platform, the legacy estate behind the front door.
The enabler stack: what is Cloudflare, and what you bring
The mistake people make with Mode B is assuming "build it on Cloudflare" means "everything must be Cloudflare." It does not, and it should not. The sound pattern is to use Cloudflare for what it is genuinely best at, the edge, the compute and the state, and to bring proven external services for the things where a dedicated provider is the better choice. Wiring those together is what Pages Functions and webhooks are for.
Cloudflare provides the edge and the runtime. DNS, CDN and cache, TLS, the WAF, bot management and DDoS protection at the edge; Pages and Pages Functions for the application; D1 for the database; Workers AI for inference; Turnstile to tell humans from bots on your forms. That is a complete runtime for a web application with no server to run.
Source control and CI/CD are external, and belong on GitHub. Your repository is your system of intent, and GitHub Actions is where deployment, secret scanning, dependency scanning and your own invariant checks run. The rule that matters most: every path that publishes to production should open a pull request, so nothing goes live without a human merge. On a platform where a deploy is instant, the pull request is your only release gate, and it has to be treated as one.
Payments stay with a payment provider. You do not build card handling, and you do not want that data in your D1 database. Use a dedicated payment provider and integrate it the way it is designed to be integrated: your Pages Functions call its API to create checkouts, and it calls your Functions back through webhooks to confirm what happened. The webhook endpoint is a Function like any other, which means it sits behind the same edge protections as the rest of your app, and it must verify the provider's signature rather than trusting the payload.
Identity and secrets are external too, and they are not the same thing. Identity, who your users are and how they authenticate, is best handled by a dedicated auth provider that issues tokens your edge middleware validates on every request. Secrets, the API keys and signing keys your platform itself needs, belong in a secrets or password manager and are injected as environment bindings at deploy time, never committed to the repository. The single most common self-inflicted breach in small platforms is a credential in source control; a vault plus a secret-scanning gate in CI is how you stop it.
Backups leave the platform on purpose. A serverless platform still needs a recovery story, and the discipline is unchanged from any other era: export the database on a schedule and the repository regularly, encrypt each copy before it leaves, send it to external object storage you control, ideally to two independent destinations, verify each copy with a checksum, and deliberately mismatch the retention windows so neither copy is a perfect superset of the other. The point of pushing backups off the platform is precisely that they must survive the platform being unavailable.
The edge protection, and how to actually manage the rules
Whichever mode you are in, the WAF and edge controls are the part you will operate day to day, so it is worth understanding how requests flow through them and how to add and tune rules without breaking your own traffic.
The request order
Every request passes through a fixed sequence of phases, and knowing it is the key to both writing rules and troubleshooting them. In order: HTTP DDoS protection, then your WAF custom rules, then rate limiting rules, then Cloudflare's managed rules, then the bot controls, and finally the origin or your Function, unless an earlier rule changed the path. A terminating action such as block or a managed challenge stops the later phases from ever evaluating the request. A skip action deliberately bypasses selected later controls. When a rule does not behave as you expect, the first question is always which phase it is in and what ran before it.
What you get out of the box, before you write a single rule
A useful thing about the WAF is how much protection is already on before you author anything. DDoS mitigation runs autonomously across the network layers on every plan. Cloudflare's managed rulesets, its own detections plus an OWASP-based core ruleset, ship maintained and updated as new exploit classes appear, so coverage for the common vulnerability categories is a toggle rather than a project. A managed scoring signal, the attack score, rates how likely a request is to be malicious even when it matches no specific signature, which catches novel and obfuscated payloads that a pure signature engine misses. Bot mitigation is available from a simple on-off mode up to full bot scoring you can reference in your own rules. And Turnstile gives you a human check for forms without proxying the whole site. The point is that the baseline is not empty: you turn managed protection on, observe, and then add your specifics on top.
| Layer | What it is | Out of the box, or you build it |
|---|---|---|
| DDoS protection | Autonomous L3, L4 and L7 mitigation | On by default, every plan |
| Managed rulesets | Cloudflare Managed plus an OWASP core ruleset, kept current | Enable and tune; some rules off by default |
| Attack score | A maliciousness rating for requests that match no single signature | Managed signal you reference in rules |
| Bot management | Fight Mode, Super Bot Fight Mode, or full bot scoring | Toggle, up to scores you rule on |
| Custom rules | Your own IF expression, THEN action logic | You author these |
| Rate limiting | Rate-based abuse control on chosen endpoints | You author these |
| Page Shield | Client-side script and supply-chain monitoring | Enable, baseline, then watch |
| API Shield | mTLS, JWT validation, schema enforcement, API discovery | Configure per API, observe, then enforce |
Custom rules: your application-specific logic
A custom rule is simply "IF expression THEN action." You match on request attributes, hostname, path, method, source, headers, and the fields your plan exposes, and you choose an action: block, one of the challenges, log, or skip. A typical early rule locks down the admin surface: if the hostname is your app and the path starts with /admin and the source is not an authenticated or trusted path, then issue a managed challenge, or block once you have validated it against real traffic. The discipline that keeps this safe is to name every rule descriptively, keep the ordering explicit because rules interact, and test on a staging hostname before it touches production.
The actions available to a rule are worth knowing as a set, because choosing the right one is most of the craft: block refuses the request outright; managed challenge presents a proportionate check that a real browser clears and a script usually does not; JS challenge and interactive challenge raise that bar further; log records a match without acting, which is how you trial a rule safely; and skip deliberately bypasses selected later phases for a known-good condition. A terminating action ends evaluation there, which is why order matters: a block in your custom rules means the managed rules never see that request.
Rate limiting: protecting the expensive and abusable endpoints
Rate limiting counts requests by some characteristic over a window and acts when a threshold is crossed. It is what you reach for against login brute force, credential stuffing, password-reset abuse, scraping and expensive API endpoints. The design that matters is the characteristic and the threshold: count by client IP or a stronger signal where you have one, set the window and limit from your own real traffic distribution rather than a number copied from the internet, and choose a mitigation duration long enough to suppress an attack but short enough to limit harm to a legitimate user. Remember that NAT, mobile carrier gateways and corporate proxies put many real users behind one IP, so an IP-only threshold set too tight will punish the innocent.
Managed rules: the maintained detections, and how to tune them
Cloudflare's managed rulesets, including OWASP core detections, cover the common exploit classes and emerging threats, and they are maintained for you. The skill is tuning them without creating blind spots. When a managed rule produces a false positive, resist the urge to skip the whole ruleset or the entire API. Instead, exempt the smallest combination that resolves the problem: the specific rule, on the specific route, for the specific method and known-safe characteristic. A broad "skip WAF for /api" is how a real attack later walks straight through the hole you opened to silence one alert.
Two mechanisms do that tuning, and they are not the same. An override changes the action or status of a whole ruleset, a tag, or a single rule, and it is the blunt instrument: an over-broad override can quietly weaken your coverage as Cloudflare adds new rules under that tag later. An exception skips a specific rule for a specific, described condition, and it is the scalpel. The preferred fix for a false positive is always the narrowest exception that resolves it, the rule, on the route, for the method, with the known-safe characteristic, and ideally one that is reviewed or expires after your next release rather than living forever as an unexamined hole.
The tuning loop, and the false-positive checklist
The safe way to introduce any rule is a loop, not a switch. Deploy it in log mode first and watch how it matches real traffic. When it looks clean, promote it to a challenge, and only then to block. When something legitimate is caught, investigate before you weaken anything: capture the Ray ID, timestamp, hostname, source, method and path; identify the exact product, ruleset and rule ID that matched; and ask whether that request is genuinely expected for that route and who generated it, your own UI, a mobile app, a partner, a health check. Then apply the narrowest exception that fixes it. Two further layers are worth knowing exist: Page Shield watches your client-side JavaScript and third-party scripts for supply-chain changes, which matters because an attacker can compromise a third-party script even when your origin is perfectly secure; and API Shield adds JWT validation and schema enforcement for the API-heavy platforms where that is warranted.
API Shield, when the platform is mostly API
For a SaaS that is primarily an API, the generic WAF is only the first layer, and API Shield adds the controls that fit APIs specifically. mTLS requires client certificates, which is how you lock a business-to-business or high-trust API to known partners, rolled out partner by partner. JWT validation cryptographically verifies tokens at the edge and exposes their claims to your rules, so an invalid, expired or tampered token is rejected before it reaches your function, though a valid token is authentication, not authorisation, and your application still has to enforce who owns what. Schema validation compares each request against an uploaded OpenAPI description and flags anything that does not fit, which you run in observation first because a stale schema is the usual source of noise, then enforce with a custom rule once you trust it. And API discovery surfaces the endpoints actually seen in traffic, which is how you find the shadow API someone shipped without telling anyone. The pattern across all of these is the same as the rest of the WAF: observe first, enforce once you are confident, and narrow the scope of anything that blocks.
Typical use cases, from CDN to full build
It helps to see the range, because the same platform serves very different jobs depending on how much of it you adopt.
| Use case | What Cloudflare is doing | Mode |
|---|---|---|
| Speed up and protect an existing site | CDN, cache and TLS in front of your current origin, with the WAF and DDoS on top | Front door |
| Shield a legacy app you cannot easily change | Edge WAF, rate limiting and bot control absorbing attacks before they reach a fragile backend | Front door |
| Add access control to internal tools | Zero Trust access in front of apps, replacing a VPN for staff and contractors | Front door |
| Ship a new SaaS as a small team | The whole application on Pages Functions and D1, no servers to run | Platform |
| Serve a global static or content site | Pages hosting with the CDN doing the heavy lifting worldwide | Platform |
| Put an API behind a managed edge | Functions plus API Shield for JWT and schema validation, rate limited at the edge | Either |
The important nuance is the top of that list. A very large share of Cloudflare usage is not "build your platform here" at all, it is "put this in front of the platform you already have." Treating Cloudflare purely as a fast, defended front door is a completely legitimate and extremely common way to use it, and it asks nothing of your application. The full-build mode is powerful, but it is one option among several, not the only reason to adopt Cloudflare.
How it compares to AWS and Azure
This is where honesty matters most, because the three are not straightforward substitutes. Cloudflare is edge-first: its strengths are global reach, the network and security layer, and a runtime that removes infrastructure operations. AWS and Azure are depth-first: enormous catalogues of managed services, mature data and analytics platforms, deep compliance and regional coverage, and the ability to build almost anything if you are willing to operate it.
For a small team building a straightforward SaaS, Cloudflare's edge-first model is often the better trade, because the work it removes, patching, capacity planning, load balancing, origin hardening, is exactly the work a small team can least afford. For an organisation with a platform team, deep data needs, strict regional or compliance requirements, or a large existing estate, a hyperscaler's breadth usually wins, and the operational overhead is a cost they are already paying. The two are not really competing for the same decision.
And the most common real-world answer is not either-or, it is both. Cloudflare in front of an AWS or Azure origin gives you the edge, the CDN and the security layer without giving up the hyperscaler's depth behind it. This is Mode A applied deliberately: you keep the platform you have invested in and put the world's traffic through Cloudflare's front door first. If you take one architectural idea from this article, it might be that the interesting question is rarely "Cloudflare or AWS", it is "what belongs at the edge and what belongs in the platform behind it."
What Cloudflare does not give you
A fair guide names the limits. The full-build mode asks more of you architecturally than a hyperscaler with managed everything. D1 is SQLite at the edge and has no row-level security, so multi-tenant isolation has to be enforced in your application code and proven by a build check rather than delegated to the database. The managed data and analytics services are far fewer than AWS or Azure offer, so data-heavy platforms may outgrow the native options. The regional and residency model is different from a hyperscaler's, which matters for some compliance regimes. And building your platform on any single provider concentrates risk, which is one more reason the payments, identity, secrets and backups deliberately live elsewhere. None of these is a reason not to use Cloudflare; they are reasons to use it with your eyes open and to keep the specialised pieces external.
The honest summary
Cloudflare is an accelerator. It takes the undifferentiated infrastructure, the network, the certificates, the scaling, the front-line defences, off a small team's plate, and it lets you choose how much of the platform you hand over: a fast, defended front door for the app you already run, or the whole runtime for a new one. Used well, it is the difference between spending your first month on the product and spending it on the plumbing.
The two things that make the difference are the same two throughout this article. Bring best-of-breed external services for payments, identity, secrets and backup, and wire them in through Functions and webhooks rather than trying to make everything Cloudflare. And manage your edge rules with a log-first, exception-narrow discipline, because the WAF is only as good as the care with which you tune it. Get those right, and Cloudflare lets you ship the platform and skip the plumbing, which for most small teams is exactly the trade worth making.
If you are choosing between an edge-first build and a hyperscaler, or you need the edge protection and pipeline set up so you can prove it rather than hope, that is the kind of work I do through Cyber Spartans.