Product Decisions This Supports
- Cache invalidation strategy (edge vs. origin): The package makes Cloudflare purging an automatic consequence of content changes in Statamic, so the question shifts from "do we purge manually or accept stale pages?" to "how granular should purges be?" v1.5.0's optional Statamic static-cache integration is the meaningful shift here — it enables targeted purges tied to the URLs the static cache actually wrote, rather than blunt full-zone flushes.
- Roadmap: whether to adopt Statamic static caching at all. Static caching is the single biggest performance lever in Statamic, and the main objection to it is stale content after publish. This release removes a chunk of that objection. If static caching is on your roadmap, this addon belongs in the same milestone, not a later one.
- Build vs. buy: The alternative is a custom Cloudflare API integration wired into Statamic's event lifecycle — roughly a few days of engineering plus ongoing ownership of retry/error handling and API versioning. For a well-scoped addon, buying (adopting) wins unless you have non-standard purge requirements (tag-based purging, multi-zone routing, custom cache keys).
- Content-operations commitments: Enables a credible promise to editors of "publish and it's live everywhere within seconds," which affects CMS training, editorial workflow design, and whether you need a manual "clear cache" button in the control panel.
- Use cases that justify it: marketing/brochure sites behind Cloudflare, multi-site or multi-domain Statamic installs, high-traffic sites where origin load matters, and any site where editors publish frequently and notice staleness.
- Release-level signal: v1.5.0 is additive and opt-in — no breaking changes, no migration. Low-risk to evaluate; the integration is a config flag, not a rewrite.
When to Consider This Package
Consider it when:
- You run Statamic (Laravel-based) with a Cloudflare zone in front of production, and content freshness after publish is a live complaint or a known gap.
- You use, or plan to use, Statamic's static caching — v1.5.0's targeted purge integration is specifically for you, and it's the difference between static caching being operationally safe and being a stale-content generator.
- Your team is small enough that owning a bespoke Cloudflare purge integration is a real cost, and the standard
Purge-Cache API surface covers your needs.
- You want the purge behavior to be declarative/config-driven rather than embedded in application code, so it can be toggled per environment.
Look elsewhere when:
- You're not on Statamic. This is a Statamic addon; a plain Laravel app should reach for a generic Cloudflare SDK wrapper or Cloudflare's own tooling.
- You're on a CDN other than Cloudflare (Fastly, Akamai, CloudFront) — the purge semantics don't transfer.
- You need tag-based/surrogate-key purging at scale, per-asset purge orchestration, or multi-provider cache abstraction. Those are custom-build or enterprise-CDN territory.
- You require a vendor with a support contract, SLA, or security review paperwork. This is a single-maintainer community addon; v1.5.0's contribution is AI-assisted (
@Copilot), which is fine for a small opt-in feature but worth noting if your dependency policy scrutinizes provenance.
- Your static caching is handled by a different addon or a custom pipeline — verify overlap before adding another actor to the invalidation path.
How to Pitch It (Stakeholders)
To executives: This is a small, low-risk addon that lets us put Cloudflare's edge cache in front of the site without editors seeing stale pages. The business effect is faster pages (better conversion and SEO) at lower origin cost, with publishing behavior that doesn't change for the editorial team. v1.5.0 adds the piece that makes Statamic's static caching safe to switch on: when a page changes, we purge exactly the affected URLs instead of wiping the whole site's cache — so a single edit doesn't cause a traffic spike to origin. It's opt-in and backward compatible, so the evaluation cost is a config change in staging, not a project.
To engineering: Addon hooks Statamic's save/publish events and issues targeted Cloudflare cache purges. v1.5.0 adds an optional integration with Statamic's static cache so purges align with the URLs the static cache generated — no full-zone flush, no origin stampede on publish. No breaking changes from v1.4.0; the integration is behind config. Evaluate on: purge correctness across multi-site locales, behavior when the Cloudflare API errors or rate-limits (does publish fail loudly or silently?), token scoping (zone-scoped Cache Purge token only), and whether purge latency is acceptable for your editorial SLA. Caveats: single-maintainer project, community-supported, and the new integration arrived via an AI-assisted contribution — read the diff before adopting, and pin the version.
To the wider business (one line): Faster site, lower hosting bill, editors see their changes immediately — with a contained, reversible dependency.