Laravel Cfcache Laravel Package

Product Decisions This Supports

• Cache-invalidation flows beyond the CLI. v1.6.0 makes the package's commands callable from application code, not just php artisan. That turns Cloudflare cache purging into a first-class building block: it can be invoked from model events (content published/updated), queued jobs, admin "purge now" buttons, or scheduled tasks without shelling out via Artisan::call() or wrapping the package in our own adapter.
• Roadmap: content freshness and publishing workflows. If we ship features where editors expect changes to appear immediately (CMS edits, pricing updates, landing page publishing), this release is the enabler. Previously this required custom glue code; now it's a supported usage.
• Build vs. buy: shifts toward buy. The main reason to write an in-house Cloudflare purge wrapper was control over invocation (from jobs, listeners, controllers). That argument weakens materially with this release — our remaining custom code would be thin, and the package now covers the integration surface we'd otherwise own.
• Use cases unlocked: programmatic purge on deploy hooks, per-entity targeted invalidation from Eloquent observers, self-service cache tools in an admin panel, and multi-tenant purge-on-tenant-change workflows.
• Operational decisions: enables moving purge logic out of deploy scripts and into application code, which improves observability (logs, retries via queues) and reduces dependence on CI/deploy tooling for correctness.

When to Consider This Package

Consider it when:

• We run Laravel behind Cloudflare and need cache invalidation driven by application events, not just manual or deploy-time console runs — this is precisely what v1.6.0 addresses.
• We want purge calls to run inside queues and jobs so they inherit retries, backoff, and failure visibility rather than living in shell scripts.
• We want to avoid maintaining an in-house Cloudflare API client and its auth/zone-ID/error-handling edge cases.
• We have modest, well-understood invalidation needs (single URLs, tags/prefixes) and want a small, focused dependency.

Look elsewhere when:

• We need broad CDN abstraction (Cloudflare + Fastly + CloudFront behind one interface) — a vendor-neutral layer or a dedicated CDN SDK is a better fit.
• Our invalidation requirements are complex (bulk-by-tag at very high volume, precise API rate-limit budgeting across services); verify the package's surface actually covers it before committing.
• We are not on Cloudflare, or we're on a Laravel version/PHP range outside the package's supported matrix.
• We need vendor-backed SLAs or a large maintainer team; this is a single-maintainer package, so bus-factor and upgrade cadence are real considerations to weigh against the low integration cost.

Adoption criteria I'd apply: confirm the programmatic API's stability and documented contract (how commands are invoked, what they return, how errors surface), confirm behaviour under queue workers, and check test coverage for the new entry point. Since this is the first release adding a non-CLI invocation path, treat it as new surface area and cover it with our own integration test on the publishing path.

How to Pitch It (Stakeholders)

For executives: A small, low-cost dependency just removed the main reason we'd have written cache-purge logic ourselves. The new version lets our application trigger Cloudflare cache clearing directly — when content changes, when a job runs, when an editor clicks a button — instead of relying on deploy scripts or manual console commands. That means fresher content for customers, fewer bespoke scripts to maintain, and less engineering time spent on plumbing. Risk is contained: single-purpose package, incremental feature addition, no breaking changes reported in this release.

For engineering: v1.6.0 exposes the existing command surface for programmatic invocation. Concretely, this lets us call purge logic from listeners, jobs, controllers, and scheduled tasks without Artisan::call() shims or a homegrown wrapper. Recommended next steps: (1) read the PR/README to confirm the invocation signature and error semantics; (2) prototype one real path — e.g. an Eloquent observer on publish that dispatches a queued purge job; (3) add an integration test around that path, since this is newly introduced API surface; (4) evaluate whether this replaces any existing custom purge code, and if so, retire it rather than running both. Flag the single-maintainer risk and pin the version; the payoff is deleting code we'd otherwise own.