Statamic Clear Assets Laravel Package

Technical Evaluation

Architecture fit

• swiftmade/statamic-clear-assets is a narrow-scope Statamic addon sitting on top of the Laravel + Statamic stack we already run; it is an operational utility (asset cache invalidation), not a framework-level dependency.
• Because it hooks into Statamic's asset container / Glide pipeline rather than our domain code, it composes cleanly: no service-provider conflicts, no route or middleware footprint beyond what the addon registers.
• v3.4.0 is a compatibility-only release: a single PR (#25, automated Laravel Shift contribution) adding Laravel 13.x support. No new features, no deprecations, no documented breaking changes.

Integration feasibility

• Low effort. Adoption is a Composer constraint change plus a cache-purge workflow; no schema changes, no data migration, no API surface for us to code against.
• Feasible as a dev/ops-facing tool immediately (CLI command or CP utility) without touching customer-facing code paths.
• Requires the surrounding stack to already be on a Laravel 13-compatible Statamic release — that dependency chain, not this package, is the real gate.

Technical risk

• Low blast radius, non-trivial blast content. The package's job is deletion of cached assets. A mis-scoped purge can evict warm Glide derivatives and trigger a cold-render stampede on origin/CDN.
• Dependency-chain risk. Laravel 13.x support implies a Statamic major/minor that supports Laravel 13.x; a version-skew mismatch is the most likely failure mode, and Composer should surface it as a solver conflict rather than a runtime error — verify, don't assume.
• Constraint-relaxation risk. Compatibility PRs from automated tooling sometimes widen illuminate/* and statamic/cms constraints beyond what was tested. Review the diff in composer.json rather than trusting the changelog.
• Maintainer concentration. Single-maintainer package; the only change in this release was tooling-generated. Low but non-zero abandonment risk.
• Unverified in our context. We have no prior assessment and no repository metadata supplied (composer.json, CI status, test coverage, PHP constraint, Statamic constraint) — all of the above is release-note-derived.

Key questions

1. What are the exact php, laravel/framework (or illuminate/*), and statamic/cms constraints in v3.4.0, and does the bump drop Laravel 10/11 or older Statamic support?
2. Does the addon mutate originals or only derivative/cache paths — and does it behave correctly against S3/cloud containers (object listing cost, rate limits, partial deletion)?
3. Is there a dry-run / scoped purge (per-container, per-directory), or is it all-or-nothing?
4. Who can trigger it from the Control Panel — is it gated by Statamic permissions, and is it audit-logged?
5. What is the test/CI story for the Laravel 13 job, and is there a tagged support matrix?
6. Is there a documented rollback (pin to v3.3.x) if the constraint bump interacts badly with our Statamic version?

Integration Approach

Stack fit

• Native fit: Composer-installed Laravel package + Statamic addon, auto-discovered service provider, no build-step or asset-pipeline coupling.
• Purely additive — it does not replace our cache strategy, it gives us a supported lever for invalidating Statamic asset caches; CDN/edge invalidation remains a separate concern we must coordinate with.
• Fits the ops/tooling lane, not the application lane: treat it as infrastructure, owned by platform/DevOps, consumed by content teams.

Migration path

• Greenfield adoption (no prior version in our estate), so there is no migration — only an evaluation gate.
• Path: pin ^3.3.0 on current Laravel → confirm baseline behavior in staging → bump to ^3.4.0 only when the host app is on Laravel 13 (or confirm v3.4.0 still supports our current Laravel, in which case upgrade early for the wider constraint window).
• Keep the version pinned exactly in composer.json; this is a package where an unattended minor bump is cheap but a behavioral surprise is expensive.

Compatibility

• Hard requirements to verify before merge: PHP version floor, statamic/cms version range, Laravel 13 alignment with the rest of our dependency graph (Sanctum, Horizon, Nova, Pest, etc.).
• Check whether the Laravel 13 job also exercises older Laravel versions in CI; a green Laravel 13 badge does not imply Laravel 12 is still tested.
• Confirm filesystem driver coverage matches ours (local vs. S3 vs. both).

Sequencing

1. Read the composer.json diff for #25; record the exact constraint matrix.
2. Install in a staging environment against a non-production asset container; exercise purge with a dry-run if available.
3. Instrument one purge run: duration, object count touched, origin hit-rate and CDN egress delta for the following 24h.
4. Define the runbook (who, when, post-purge warm-up) and permission gating in the CP.
5. Promote to production behind a scheduled/off-peak window; keep the pin and a documented revert to the prior tag.

Operational Impact

Maintenance

• Near-zero code maintenance — we consume, we don't extend. Budget a recurring ~30-minute review per upstream release, plus a dependency-matrix re-check whenever Laravel or Statamic majors move.
• Track upstream release cadence; a compatibility-only release signals the maintainer is relying on automated tooling, so human review of each diff is warranted.
• We own the risk if the package stalls: worst case we fork a small addon or replace it with a bespoke Artisan command — a contained, few-hour exit.

Support

• Community/volunteer support; no vendor SLA. Escalation path is GitHub issues, so plan for self-service debugging.
• Internal support burden is low and concentrated in platform/DevOps; content editors only need the CP-level "when and how to purge" guidance.
• Document the internal owner explicitly — this class of utility tends to become orphaned because no team considers it "theirs."

Scaling

• Purge cost scales with asset/derivative count and filesystem latency, not with traffic. Large containers or S3-backed containers make this an O(n) remote-object operation with API rate-limit exposure.
• Concurrency is the real scaling concern: simultaneous purges plus cold derivative regeneration can saturate PHP workers; serialize purges and cap concurrency.
• Multi-node/multi-environment estates need per-environment discipline — a purge in staging is harmless, an unbounded purge in production is a self-inflicted traffic spike.

Failure modes

• Cold-cache stampede: purge during peak → Glide regenerates on demand → CPU/IO spike and elevated origin egress.
• Partial purge: timeouts or S3 throttling leave an inconsistent cache; retries can compound load. Needs idempotency and observable completion.
• Over-broad deletion: a mis-scoped purge removing more than intended derivatives (or, worst case, touching original assets on cloud storage).
• Version skew: Laravel 13 constraint bump resolves against an incompatible Statamic release; surfaces at boot or first command invocation.
• Silent no-op: purge reports success but the underlying driver/container was misconfigured — mitigated by verifying post-purge derivative counts, not exit codes.

Ramp-up

• Minimal: ~1–2 hours for a developer to install, read the command surface, and validate in staging; ~30 minutes of enablement for content/ops staff.
• Prerequisites: an existing Statamic asset-container owner, a staging environment with a representative container, and access to CDN/origin metrics for baseline comparison.
• Recommend a short internal runbook (trigger, scope, timing window, warm-up step, rollback pin) as the actual deliverable of adoption — the package itself is the easy part.