Weave Code
Statamic Cloudflare Laravel Package
handmadeweb/statamic-cloudflare
A Statamic addon for Cloudflare integration that automatically purges Cloudflare cache when content changes, helping keep published entries, assets, and URLs fresh while reducing stale pages. Includes configurable purge rules for your site’s Cloudflare setup.
Cloudflare integration for Statamic with CLI, static caching integration and control panel integration.
Frequently asked questions about Statamic Cloudflare
- What does the handmadeweb/statamic-cloudflare addon actually do?
- It is a Statamic addon that connects your site to Cloudflare's cache and automatically purges cached content when entries, assets, or URLs change. That keeps published content fresh at the edge instead of serving stale pages after an edit. It ships with a CLI, static caching integration, and Control Panel integration, plus configurable purge rules so you can control what gets invalidated for your specific Cloudflare setup.
- How do I install handmadeweb/statamic-cloudflare in a Statamic project?
- Install it with Composer using composer require handmadeweb/statamic-cloudflare, then publish the addon's configuration file so you can define your purge rules. You will need Cloudflare credentials such as an API token with cache purge permissions and your zone ID, which the addon reads from config or environment variables. Check the published config file for the exact key names before wiring it into your deployment pipeline.
- Does this package support Statamic 5, Laravel 11, and PHP 8.2?
- Release 2.1.0 adds Statamic 5 support through a community contribution, and Statamic 5 implies a Laravel 11 and PHP 8.2+ baseline. That narrows the set of host applications this line can serve, so projects still on Laravel 10 and Statamic 4 need to stay on the earlier package line. Confirm the actual require constraints in composer.json rather than relying on the changelog wording alone.
- Does version 2.1.0 drop Statamic 4 support or add Statamic 5 alongside it?
- The changelog entry only says Statamic 5 support, which does not clarify whether Statamic 4 remains supported. Check the require block for statamic/cms in composer.json: an additive constraint such as ^4.0|^5.0 is a safe drop-in, while a replacement constraint of ^5.0 only delivered in a minor bump is effectively a breaking change. If Statamic 4 was dropped, hold at 2.0.x and treat the package upgrade as gated on your CMS migration.
- How does the automatic cache purge on content change work?
- The addon hooks into Statamic's content lifecycle and issues purge requests to Cloudflare when entries, assets, or URLs are updated, so visitors do not receive stale cached responses. Purge rules are configurable, letting you scope which URLs or tags are invalidated instead of purging everything. Because the purge behaviour is event driven, test it against your own content types and URL structure in staging before relying on it in production.
- Does it work with Statamic static caching?
- Yes, static caching integration is one of the addon's stated features, which matters because Cloudflare sits in front of your statically cached HTML. When content changes, the package can purge the relevant Cloudflare edge cache entries so the refreshed static output is served. Verify that your static cache invalidation and the addon's purge rules agree on which URLs are affected, otherwise you can end up with partial purges.
- Is there a CLI command to purge the Cloudflare cache manually?
- The package includes a CLI component, so you can trigger purges from the console as part of deployments or maintenance scripts instead of waiting for a content event. The exact command name depends on the version, so run php artisan list and look for the Cloudflare namespace after installing. This is useful for one-off purges after config or template changes that do not fire a normal content save event.
- Can I manage Cloudflare purges from the Statamic control panel?
- Control Panel integration is part of the addon, giving editors a way to interact with Cloudflare caching without leaving Statamic. The exact surface, whether a utility, action, or widget, depends on the version you install, so confirm after installation. For teams where non-technical editors publish frequently, this reduces reliance on developers running CLI purges.
- How do I verify the purge integration actually works before production?
- Use a Cloudflare API token scoped narrowly to cache purge for the target zone, run a content change in staging, and confirm the purge response and the resulting cache status in Cloudflare. Also check the package's CI configuration for a green matrix covering Statamic 5, Laravel 11, and PHP 8.2 or 8.3, because a widened Composer constraint without test coverage is a claim rather than a verified capability. Since the Statamic 5 support arrived as a community contribution, treat the first release as a screening pass.
- What are the upgrade risks of this addon for a project mid-migration to Statamic 5?
- The main risk is silent constraint widening: Composer resolves fine, but runtime behaviour differs because Statamic 5 changed APIs the addon touches. The opposite risk is dropping Statamic 4 support in a minor release, which breaks pinned environments on composer update without an obvious signal. Sequence the Statamic 4 to 5 migration first, validate the addon against it, then bump the package, and record an explicit package version by Statamic, Laravel, and PHP support matrix in your dependency register.
Weaver
How can I help you explore Laravel packages today?