Where Cloudflare fits on a long engagement.

Putting a global network in front of an origin changes both performance and exposure. Cached content is served near the user, and traffic that should never reach the application — volumetric attacks, known-bad patterns — is dropped before it costs anything.

Cache configuration is where most of the available value goes unclaimed. Default rules cache static assets and little else, while the dynamic pages that would benefit most are passed through untouched. Getting cache keys, vary behaviour and purge strategy right is real work that most deployments never do.

What an assigned team does with Cloudflare.

A WAF in blocking mode without tuning will eventually block legitimate traffic, usually something important and usually at a bad moment. Starting in monitoring mode and tuning from observed traffic is the sequence that avoids that.

Running that sequence properly is standing platform work assigned under devops as a service, rather than a configuration set once at launch.

What we use Cloudflare for.

  • Cache rules that actually reduce origin load Dynamic content cached deliberately with a purge strategy, not just static assets.
  • Attack traffic dropped at the edge Volumetric and known-bad requests filtered before they reach or cost anything.
  • WAF tuned before it blocks Monitoring mode first, so rules are calibrated against real traffic.

How Cloudflare capacity is assigned.

Edge configuration is treated as an ongoing activity rather than a launch step, held within an agreed committed monthly capacity.

Tell us what your roadmap needs Cloudflare for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

Loading the contact form… You can also email hello@azendo.co.

We reply within one working day. No obligation, and no newsletter.