- How do I install sebdesign/artisan-cloudflare in a Laravel application?
- Install it with Composer using composer require sebdesign/artisan-cloudflare, then publish the package config so a cloudflare.php file lands in your config directory. Add your Cloudflare credentials to .env and confirm the commands are registered by listing them with php artisan list. There are no migrations and no database tables, so the install is config-only. Run a purge against a staging zone before wiring it into anything production-facing.
- Which PHP and Laravel versions does version 2.9.0 support?
- Version 2.9.0 is a breaking platform-matrix change that drops PHP 7.x and Laravel 5.x support entirely. Laravel 13 compatibility was contributed through laravel-shift, which is a good sign the package is being kept current with framework releases. The release notes do not state the new minimum PHP floor, so check the require block in composer.json at that tag rather than assuming 8.2 or 8.3. If you are still on PHP 7.x or Laravel 5.x you should stay pinned to ^2.8.
- Should I use a scoped Cloudflare API token or the legacy email plus global API key?
- Prefer a zone-scoped API token over the legacy email plus global API key combination, since a global key grants far broader access than cache purging requires. The package has historically supported both credential models, so the config file exposes more than one path. Credential handling is the real integration work here, not the Composer install. Confirm the exact config keys accepted at v2.9.0 against the published config/cloudflare.php and the README before committing to one model.
- Can this package purge individual URLs or cache tags, or only purge everything?
- The package exposes Cloudflare's cache purge operations through Artisan commands, but which granularities are available depends on the version and on your Cloudflare plan tier. Tag-based purging in particular requires a plan that supports it, so this is as much a Cloudflare account question as a package question. Purge-everything is a blunt instrument that can spike origin load on the next request wave and is subject to Cloudflare rate limits. Check the README at your installed version to confirm whether targeted purges by URL, tag, or hostname are wired up.
- How do I schedule a Cloudflare cache purge in Laravel?
- Because the package ships Artisan commands, you schedule purges with Laravel's task scheduler by referencing the command name in your console kernel or routes/console.php. That keeps purge logic out of your application code and inside the same cron entry that already runs your other scheduled work. Verify the exact command signature with php artisan list before wiring it in, since namespaces can change between majors. Purging after a deploy or content update is generally safer than purging on a fixed timer that may fire during peak traffic.
- Can I purge the Cloudflare cache from application code instead of the CLI?
- The package includes a facade that wraps the Cloudflare API, so purges can be triggered from code, model lifecycle events, or observers rather than only from a terminal. That is useful for invalidating cached pages the moment a record is saved. Because facade signatures are not guaranteed stable across major versions, confirm the exact method names against the README at v2.9.0 before relying on them. If a purge happens inside a request cycle, consider whether a failed API call should be allowed to break the user-facing operation.
- What happens if the Cloudflare API call fails during a purge?
- A failed API call surfaces as a command failure rather than being swallowed, but the practical risk is in your pipeline, not the package. The common failure mode is a deploy script that runs the purge and ignores the exit code, so the deploy passes while stale cache stays live. Add an assertion on the API response so a failed purge fails the deploy instead of passing silently. Also account for rate limiting and transient Cloudflare errors, which can break the call independently of the package version.
- How do I safely upgrade from 2.8.x to 2.9.0?
- If you are on PHP 7.x or Laravel 5.x, do not take this upgrade at all: pin ^2.8, treat it as a dead-end branch, and make the PHP 8 and Laravel 10+ framework upgrade the actual project. If you are already on PHP 8.x and Laravel 10 or newer, bump to ^2.9 in a branch and run the suite. Use composer why-not sebdesign/artisan-cloudflare 2.9.0 in CI as a fast blocker check, and diff the full changelog rather than the summary block. Check whether the published config/cloudflare.php shape changed between 2.8 and 2.9; if it did, republish and merge rather than overwriting your credentials.
- Is sebdesign/artisan-cloudflare actively maintained?
- It is a single-maintainer package with a correspondingly small contributor base, so the bus factor is one. Laravel 13 support arrived through laravel-shift, a framework-ecosystem compatibility vendor, which is a reasonable signal that the package is being kept current. Day-to-day operational cost is low: no schema, no daemons, and no queue dependency of its own. The real cost is upgrade cadence, since it tracks Laravel majors and inherits a version bump each framework cycle.
- Do I actually need this package, or should I call the Cloudflare API directly?
- It is a convenience wrapper, not infrastructure. If your deploy pipeline already purges the cache with a curl step, the value you gain is centralized config management and Artisan ergonomics rather than new capability. Calling the Cloudflare API through Guzzle directly, or using the official Cloudflare SDK, is a viable alternative if you only need one purge call and do not want another dependency tracking Laravel majors. Choose the package if you want DNS and zone management alongside purging, all driven from the CLI and scheduler.