Static Cache Buster Laravel Package

Technical Evaluation

Architecture fit. This is a Statamic addon (Statamic being a Laravel-based CMS), not a general Laravel package. Its value proposition targets a real, known pain point in Statamic's Static Caching feature: file-based static caching writes rendered HTML to disk, and when those files are invalidated (content publish, static:clear), subsequent visitors hit a cold cache and pay a full Statamic render — often seconds on entry-heavy pages. The package's stated goal — warm the cache "without causing cache misses for visitors" — implies an ordering discipline (warm-before-purge, atomic write/swap, or stale-while-revalidate) rather than the naive static:clear && static:warm sequence most teams script in CI. That is architecturally the right place to intervene: in the invalidation lifecycle, not in the request path.

Integration feasibility. High, structurally. Composer-installable, addon auto-discovery, MIT-licensed, and Statamic exposes the necessary extension points (invalidation events, console commands, the static cache manifest). Expected footprint is small — a service provider, a command, and invalidation listeners. The real feasibility question is whether it hooks Statamic's invalidation manifest correctly across the file and application strategies; the description strongly suggests file only.

Technical risk. Concentrated in maturity and identity, not in concept:

• Bus factor 1. Zero stars, zero dependents, a single release (2025-06-25), no release cadence history. Untested by the ecosystem.
• Namespace/repository mismatch. Package handle f_roepstorf vs. repository owner FlorianRiquelme. This may be benign (renamed org/handle) but is exactly the signal a supply-chain review must resolve before install.
• Concurrency. Warming into a live-served filesystem cache invites partial-file races and truncated HTML served to real users — the worst-case failure is worse than a cache miss.
• Topology. Statamic's file static cache is node-local. On load-balanced infrastructure the package's benefit is only realized with shared storage or per-node warming.

Key questions for the maintainer / source audit. Which Statamic versions (4.x/5.x) and PHP floor? File strategy only, or application cache too? Full-site warm or only the invalidated URLs? Synchronous on publish or queued? Does it respect static_caching.exclude, entry previews, and logged-in sessions? Multisite handling? Octane compatibility? Does it supersede or duplicate Statamic's own static:warm command? Any exec, network, or telemetry calls in the source?

Integration Approach

Stack fit. Laravel + Statamic 4/5 on PHP 8.1+, standard Composer workflow, writable static/ path (or configured static cache disk). No new infrastructure required in a single-node setup; shared storage or a per-node warm step required otherwise.

Migration path. Treat as an additive optimization, not a replacement. Install in staging with a production-sized content set, verify it does not mutate core static_caching config, and confirm rollback is a composer remove plus a config revert. Pin the exact version and commit the lock file.

Compatibility. Primary overlap risk is with Statamic's built-in static:warm. If both run, you get duplicated render load and ambiguous ordering. Decide explicitly which owns warming. Secondary risk: CDN/edge layers caching the stale HTML independently — warming origin files does nothing for a stale edge PoP unless the purge is coordinated.

Sequencing.

1. Source audit and namespace/ownership verification (cheap — likely a few hundred lines).
2. Staging pilot: instrument static cache hit ratio and origin p95 TTFB before/after.
3. Introduce warming into the deploy pipeline pre-traffic-cutover as the first, lowest-risk win.
4. Only then enable invalidation-triggered warming on publish.
5. Add targeted/queued warming for large sites; move full-site warm to a scheduled off-peak job.
6. Coordinate edge/CDN purge ordering with cache invalidation.

Operational Impact

Maintenance. Small code surface, MIT, forkable — the pragmatic posture is vendor-or-fork into an internal repository and treat upstream as a reference implementation rather than a dependency. Pin, review diffs on update, no auto-merge from a zero-dependent package.

Support. No community, no documented support commitment, GitHub issues only. An internal owner must be named. Budget roughly half a day to a day for a Laravel developer to learn Statamic's static cache manifest well enough to debug failures.

Scaling. Warming cost is O(pages). A 10k-entry site makes full warm expensive in time and memory — targeted warming keyed to the invalidation event is the only viable mode at scale. The package solves the thundering-herd-on-clear problem, but a full clear on a large site remains a self-inflicted capacity event; pair with queued warming and publish batching. Multi-node deployments invert the benefit unless storage is shared.

Failure modes to instrument for:

• Partial warm leaving a stale/missing mix across the site.
• File-write race producing truncated HTML to live visitors.
• Warm job OOM or timeout on large content sets.
• Invalidation loop: warming emits events that re-invalidate.
• Ordering bug where warm runs concurrently with purge, resurrecting stale content.
• Static directory permission failures post-deploy.
• Warm step blocking the deploy pipeline (treat as non-blocking with alerting).
• Excluded routes (forms, search, previews) being warmed and served anonymously.

Ramp-up. Low for any Laravel-comfortable engineer; the learning curve is Statamic's static caching internals, not this package. Recommend an internal spike plus source review before adoption beyond a single staging pilot. Verdict: conceptually sound and worth a scoped pilot; not advisable as an unvetted production dependency given zero adoption, a single release, and an unresolved namespace mismatch.