Weave Code
Laravel Cloudflare Cache Laravel Package
yediyuz/laravel-cloudflare-cache
Integrate Cloudflare edge caching into Laravel: cache responses, automatically purge URLs or tags on model changes, and manage cache behavior from familiar Laravel APIs. Reduce origin load and speed up responses with minimal configuration.
Serve millions of requests by caching with Cloudflare
Frequently asked questions about Laravel Cloudflare Cache
- How do I install and configure yediyuz/laravel-cloudflare-cache in a Laravel app?
- Install it with composer require yediyuz/laravel-cloudflare-cache, then publish the config file and set CLOUDFLARE_API_TOKEN and CLOUDFLARE_ZONE_ID in your environment. Attach the provided middleware to the route group you want cached, typically a public GET-only group. Verify the result with curl -I against a staging host behind Cloudflare and confirm the Cache-Control, CDN-Cache-Control and cache-tag headers plus the cf-cache-status value. Expect roughly one to three engineer-days for a staging pilot including verification.
- Do I need a Cloudflare Enterprise plan to use cache tags with this package?
- Tag-based purging relies on Cloudflare Cache Tags, which is generally an Enterprise-tier capability. If your zone is on Pro or Business, the practical pattern collapses to purge-by-URL or purge-everything, which changes both your invalidation design and the blast radius of a bad purge. Confirm your plan tier and tag entitlement before committing to an architecture. Also note that a later plan downgrade silently removes tag support.
- Which routes are safe to cache with this Laravel Cloudflare middleware?
- Use it for anonymous, read-heavy, idempotent GET surfaces: marketing pages, catalog and listing pages, public API reads, sitemaps and documentation. It is a poor fit for anything personalized, session-scoped or authorization-dependent, because the package cannot infer that for you. Caching a response that should have been private is a data-exposure incident, not a performance bug, so review Vary, Set-Cookie and Authorization handling explicitly. Define an acceptable staleness window per route before enabling caching.
- How does automatic purging work when an Eloquent model changes?
- The package ships optional Eloquent observers so model writes trigger tag invalidation through the Cloudflare API. That requires you to define a tag taxonomy first, for example per model, per tenant or per route, and to own it over time. Observers give you the mechanism, not the policy, so you still decide which writes invalidate which tags. Purge calls are destructive and rate-limited, so over-purging costs money and origin load while under-purging causes staleness.
- Which Laravel and PHP versions does laravel-cloudflare-cache support?
- Check the composer.json constraints on Packagist or the GitHub repository before adopting, since version support moves with each release. The package is a thin wrapper around a service provider, middleware, facade and artisan commands, so it generally tracks recent Laravel releases without deep framework coupling. Run it against your own Laravel and PHP matrix in staging rather than assuming compatibility. Pin the version you validate so a minor release cannot shift behavior under you.
- Does this package work with Laravel Octane?
- The package operates at the HTTP response layer through middleware and API calls, so it does not fork the framework or patch the runtime. That design is generally Octane-friendly, but edge behavior and long-lived workers should still be verified on staging behind real Cloudflare DNS. Watch for things like cached config and static state in your own middleware stack rather than assuming the package is the culprit. Test the actual header output under Octane before rollout.
- How can I test Cloudflare caching locally during development?
- You cannot reproduce edge behavior locally, because Cloudflare's cache only exists in front of proxied DNS. Unit test the middleware in Laravel to assert the emitted Cache-Control, CDN-Cache-Control and cache-tag headers. Then validate real caching on a staging host behind Cloudflare by inspecting cf-cache-status and measuring origin request reduction. Treat local tests as header tests, not caching tests.
- What happens if the Cloudflare purge API is unavailable or the token expires?
- Purge calls are best-effort network requests, so a failure leaves stale content at the edge until a later purge succeeds. Plan for that: wrap purge calls with error handling and logging, alert on repeated failures, and watch for expired or revoked tokens. The package provides the mechanism for invalidation but not the monitoring, so detection and recovery are your responsibility. This matters most for content where a wrong or stale response has business impact.
- What API token scope should I use for Cloudflare cache purging?
- Request the narrowest scope that works, typically Zone.Cache Purge limited to the specific zone you are caching. Keep the token in environment variables or a secrets manager, never in version control, and have a named owner plus a rotation schedule. Broader account-level tokens turn a leaked credential into a much larger incident.
- Is yediyuz/laravel-cloudflare-cache actively maintained, and what is the bus factor?
- It is a single-maintainer package with roughly 283 stars and no foundation or corporate backing, so treat the bus factor as a real risk. The pragmatic approach is to treat it as a thin convenience wrapper you may need to vendor or fork rather than a strategic dependency worth deep coupling. It is MIT-licensed and small in surface area, which keeps an exit cheap. Pin the version and budget time to review it before upgrading major Laravel releases.
Weaver
How can I help you explore Laravel packages today?