Statamic Cache Evader Laravel Package

Product Decisions This Supports

• Upgrade urgency / risk triage: v1.4.1 is a security patch, not a feature release. The rendering URL signature for dynamic partials is now actually validated. Any environment running < 1.4.1 should be treated as having a security defect, which makes this a "schedule the upgrade now" decision rather than a backlog item.
• Build vs. buy for partial caching: This package is a narrow, single-purpose dependency that solves one problem — punching small dynamic regions into otherwise fully cached Statamic pages. It informs whether we own that plumbing (signed-URL endpoint, partial registry, cache-bypass semantics) or rent it.
• Feature scoping: Any roadmap item that depends on per-request fragments inside cached pages (personalized greetings, cart/basket counts, CSRF tokens, inventory or pricing counters, A/B slots, user-aware nav) is gated on whether we trust this package's security posture. That posture just changed for the better.
• Architecture decisions around caching strategy: Choosing between hole-punching (this package), edge-side includes, or client-side hydration. This release is a data point on the operational cost of the hole-punching approach — it requires us to track upstream security patches on an ongoing basis.
• Compliance / audit posture: If we make any claim that cached pages cannot be coerced into rendering arbitrary partials, that claim is only true from 1.4.1 onward. Worth capturing in our dependency register.

When to Consider This Package

Adopt when:

• You run a Statamic site with full-page caching (static cache, response cache, or CDN) and need a small number of dynamic regions inside otherwise-cacheable pages.
• The dynamic content is presentational and low-sensitivity — counts, tokens, greetings, toggles — where a per-fragment HTTP round-trip is acceptable.
• Your team has the maintenance capacity to track addon releases, since security fixes here are mandatory upgrades, as v1.4.1 demonstrates.
• You are already committed to Statamic and Laravel; this is not a portable solution.

Look elsewhere when:

• You need authenticated, per-user caching at scale — use a proper edge/ESI layer or client-side hydration instead of server-rendered fragments.
• All content is cacheable, in which case the dependency earns nothing.
• Dynamic fragments would carry sensitive data (PII, entitlements, prices that must be authoritative) — the signing mechanism protects the render endpoint, not the payload's confidentiality model, and adds an attack surface.
• You cannot guarantee the signing key is set, secret, and rotated on compromise. Prior to 1.4.1, forged or unsigned render URLs were not reliably rejected; a weak or leaked key materially weakens the fix.
• You want framework-agnostic caching primitives or are evaluating a move away from Statamic.

Adoption criteria for v1.4.1 specifically: pin to ^1.4.1 (or higher), confirm the signature configuration is present in each environment, and treat any environment that ran an earlier version with an exposed render endpoint as requiring a key rotation and a log review.

How to Pitch It (Stakeholders)

To executives: We depend on a small Statamic addon that lets us serve fully cached pages while keeping a few small elements live. A security patch shipped in v1.4.1 — previously, the addon did not reliably verify that requests to render those live fragments were legitimate. The upgrade is small, low-risk, and closes the gap. Recommendation: approve a routine maintenance window and add this package to the list we watch for security releases, because future patches will be mandatory rather than optional.

To engineering: Bump to ^1.4.1, verify the dynamic-partial signing configuration exists and uses a real secret in every environment, add a regression test asserting that an unsigned or tampered render URL is rejected, and audit access logs for the render endpoint. This is a hardening release — no new features, no API changes expected, so the blast radius should be limited to configuration validation.