Statamic Cloudflare Laravel Package

Technical Evaluation

Architecture fit

• The package is a Laravel/PHP package with Statamic bindings; release 2.1.0 adds Statamic 5 support via a community contribution. This confirms the package sits in the CMS-addon layer of a Laravel stack rather than core application infrastructure, so its upgrade cadence is coupled to Statamic majors, not to our own release schedule.
• Statamic 5 implies Laravel 11 and PHP 8.2+, which materially narrows the set of host applications this release can serve. Any project still on Laravel 10 / Statamic 4 must remain on the prior package line.
• No prior assessment exists and the only input is a single-line changelog entry, so this evaluation is provisional and should be treated as a screening pass, not a sign-off.

Integration feasibility

• Feasible for Statamic 5 / Laravel 11 / PHP 8.2+ projects. For Statamic 4 projects, feasibility is conditional entirely on whether 2.1.0 retains Statamic 4 constraints — the changelog says "Statamic 5 support" but not "in addition to," and that distinction is the whole decision.
• Verify against composer.json directly: the require block for statamic/cms and laravel/framework, plus php. An additive constraint (^4.0|^5.0) means a safe drop-in; a replacement constraint (^5.0 only) delivered in a minor bump is a semver violation and effectively a breaking change for anyone pinned below.
• Confirm the package is actually exercised against Statamic 5 in CI, not merely permitted by composer. A widened constraint without a green test matrix on Statamic 5 is a claim, not a capability.

Technical risk

• Medium-low for greenfield or already-migrated Statamic 5 projects; medium for any project mid-upgrade.
• Primary risk is silent constraint widening: composer resolves successfully, but runtime behaviour differs because Statamic 5 changed APIs that this package touches. The contributor credit suggests the change was made to unblock a specific use case rather than a full compatibility audit.
• Secondary risk is the opposite — dropping Statamic 4 support in a minor release — which breaks pinned environments on composer update without an obvious signal.
• Low direct security risk from the change itself.

Key questions

• Does 2.1.0 add Statamic 5 alongside 4, or replace it? Which Statamic and Laravel versions are in the require constraints before and after?
• Is there CI coverage for Statamic 5 × Laravel 11 × PHP 8.2/8.3, and did it pass on the release commit?
• What is the minimum Statamic 4 version still supported, and is there a documented upgrade note for teams moving 4 → 5?
• Is the contributor a one-off patch author or now a recurring maintainer? What is the bus factor?
• Are there open issues referencing Statamic 5 breakage after this release?

Integration Approach

Stack fit

• Target stack: PHP 8.2+, Laravel 11, Statamic 5. This aligns with a modern Laravel baseline; projects on Laravel 10 / PHP 8.1 are out of scope for this line.
• Confirm the package has no transitive dependency conflicts with our existing addon set (other Statamic addons, SEO/asset/cache addons are the usual collision points).

Migration path

• Already on Statamic 5 and blocked from upgrading this package: low-risk bump, pin ^2.1, run the suite.
• On Statamic 4: do not upgrade until the constraint question is answered. If 2.1.0 is additive, stay put and upgrade at leisure. If it drops Statamic 4, hold at 2.0.x and treat the package upgrade as gated on the Statamic 5 migration.
• Statamic 4 → 5 is the real migration, not this release. Sequence the CMS upgrade first, validate the package against it, then bump the package.

Compatibility

• Build an explicit support matrix (package version × Statamic × Laravel × PHP) from composer.json plus CI config, and check it into our dependency register. This package's matrix is now the constraint that governs our CMS upgrade timing.
• Confirm the package doesn't rely on any Statamic API deprecated in 5 but still functional in 4 — these are the latent failures that surface one release later.

Sequencing

1. Read composer.json at the 2.1.0 tag and diff constraints against 2.0.x.
2. Confirm CI/test coverage for Statamic 5.
3. Pilot on one non-critical Statamic 5 project with the full test suite and a manual pass over the feature the package provides.
4. Roll to remaining Statamic 5 projects.
5. Defer Statamic 4 projects until the CMS upgrade is separately scheduled.

Operational Impact

Maintenance

• Support for two Statamic majors (if additive) roughly doubles the test surface the maintainer must keep green; watch whether the CI matrix actually reflects both, or whether one line is untested and rots.
• Statamic majors ship on a cadence tied to Laravel; expect a comparable compatibility release from this package within a few weeks of each Statamic major. Budget for that lag in upgrade planning.

Support

• Community-contributed compatibility patches are a positive health signal but also indicate the maintainer is not proactively tracking upstream releases. Assume we may need to self-patch or pin in the window between a Statamic major and this package's compatibility release.
• Escalation path is limited: an open-source addon with a small maintainer pool means our own team is the de facto second line of support.

Scaling

• Negligible runtime scaling impact — the change is a compatibility constraint, not a performance or architectural change.
• Operational scaling concern is portfolio scale: each additional Statamic/Laravel combination in our estate multiplies the matrix we must validate. Standardise on Statamic 5 / Laravel 11 to keep it at one supported cell.

Failure modes

• Composer resolves to 2.1.0 on a Statamic 4 project and the package fails at runtime — most likely if constraints were replaced rather than widened.
• Constraint widened but untested: installs cleanly on Statamic 5, fails on a specific code path the contributor didn't exercise.
• Silent divergence across environments if some deploy targets pin 2.0.* and others float — enforce a single constraint per project repo.
• Upstream: a subsequent Statamic 5.x point release changes something this package assumes, with no fast patch available.

Ramp-up

• Low for engineers already fluent in Statamic and Laravel; the package surface is small.
• Budget roughly half a day of engineering to read the constraints, run the existing suite against Statamic 5, and manually exercise the package's feature in a staging environment.
• No meaningful training burden; the real cost is the CMS upgrade, which is out of scope for this review.