Artisan Cloudflare Laravel Package

Product Decisions This Supports

• Build vs. buy for CDN cache invalidation: this package wraps the Cloudflare cache-purge API in Artisan commands and Laravel-native config, so the decision is really "spend a sprint hand-rolling HTTP calls plus a config file, or adopt a small maintained dependency." For most teams the package wins on effort; for teams that already have a Cloudflare service class, it is redundant.
• Deploy-time cache hygiene: supports a roadmap decision to purge Cloudflare cache automatically as the final step of every release, removing a manual ops checklist item and a common source of "why is the site still showing the old CSS" incidents.
• Content-triggered invalidation: supports features where editorial or catalog changes must be visible immediately (headless CMS, product/price updates, marketing landing pages) by wiring purge calls to model events or queued jobs rather than relying on TTLs.
• Platform versioning roadmap: dropping PHP 7.x and Laravel 5.x is a forcing function — it tells you whether this package constrains your upgrade path. If you are already on PHP 8.2+/Laravel 10+, v2.9.0 unblocks a Laravel 13 upgrade rather than blocking it.
• Scope decision on Cloudflare ownership: whether CDN configuration lives with the app team (in-repo, versioned, testable) or with the platform/infra team (Terraform, dashboard). Adopting this package is an implicit vote for "app team owns purge behavior."

When to Consider This Package

Adopt when:

• The application sits behind Cloudflare and correctness depends on purging cached HTML/assets on deploy or on content change.
• The stack is PHP 8.x and Laravel 9+/10+, where v2.9.0's supported matrix applies cleanly.
• You want purge behavior expressed as Artisan commands and config — greppable, code-reviewable, and runnable from CI — rather than as dashboard clicks or a bash script with a curl call.
• You value a low-ceremony dependency: this is a thin integration layer, so the cost of removing it later is small.

Look elsewhere or postpone when:

• You are on PHP 7.x or Laravel 5.x/6.x. v2.9.0 is an explicit breaking change — support is dropped, not deprecated. Pin to v2.8.0 and plan the runtime upgrade, or you will be stuck on an unmaintained branch.
• You need broader Cloudflare management (DNS, WAF rules, Workers, cache rules, zone provisioning) — this package is not an API SDK; use the official Cloudflare PHP SDK or Terraform.
• Your caching is handled at the origin (Laravel response cache, Redis, Varnish) and Cloudflare is pass-through — the integration adds a dependency with no payoff.
• You only need a handful of one-off purges; a queued job with three lines of Guzzle may be simpler than a config file plus a dependency.
• You need guaranteed API coverage of newer Cloudflare purge semantics (tags, prefixes, hostnames) — verify the package exposes them before committing.

How to Pitch It (Stakeholders)

For executives: a small, low-risk integration that automates clearing Cloudflare's edge cache whenever we deploy or publish content, so customers stop seeing stale pages and our team stops doing manual cache clears. The v2.9.0 release is a maintenance signal — the package added support for the newest Laravel version and dropped end-of-life PHP and Laravel versions. That is good housekeeping, not a new risk, but it does mark a hard floor: any application still on PHP 7 or Laravel 5 can no longer take updates.

For engineering: v2.9.0 is a compatibility-only release — Laravel 13.x support, PHP 7.x and Laravel 5.x removed. No new features. Treat it as a routine bump if we are on PHP 8+ and Laravel 9+, and verify our CI matrix and composer.json constraints actually reflect that before merging. If any service is still on PHP 7, that service must stay pinned to v2.8.0 and be tracked as tech debt, since v2.8.0 will no longer receive fixes. Because the package is a thin wrapper rather than an API SDK, we should keep our purge calls behind a small internal interface so swapping it out — or dropping it — stays a contained change.