Statamic Advanced Invalidator Laravel Package

Technical Evaluation

Architecture fit. visuellverstehen/statamic-advanced-invalidator is a Statamic addon distributed as a Composer package, so it slots into the standard Laravel package lifecycle (service provider, publishable config, facade/events). Its job is cache invalidation — reacting to Statamic content lifecycle events (entry saved, deleted, published, etc.) and purging the corresponding cached surfaces (CDN, reverse proxy, or static cache). That is an event-driven, additive concern: it does not own content, routing, or storage, which keeps architectural coupling low. For a Statamic-backed Laravel monolith fronted by a CDN, this is a natural fit rather than an invasive one.

Integration feasibility. Installation is conventional: composer require, publish config, supply credentials, optionally wire a queue. The v1.1.0 change is a Laravel 12 compatibility declaration, which is the single highest-value item for us — it removes the "held back on Laravel 11" blocker that would otherwise have forced either a fork or an upgrade deferral. Effort to first successful invalidation in a dev environment is measured in hours, not days.

Technical risk. The dominant risk is not code quality but silent failure: a cache invalidator that stops working produces stale public content, not exceptions. Secondary risks are vendor concentration (small agency-maintained package, low bus factor), thin public test coverage, and release hygiene — the notes are internally inconsistent (headline says v1.1.0, changelog compares v1.0.2...v1.0.3), which suggests a manual release process. No deprecations or breaking changes are signalled, and a Laravel constraint bump is normally additive, but the exact diff should be reviewed before adoption.

Key questions.

• Which invalidation backends/targets are supported, and is the one we use first-class or best-effort?
• Does it batch and de-duplicate invalidations, or fire one API call per entry event?
• Is queue/async dispatch supported, and what happens on queue failure — retry, dead-letter, or drop?
• How does it handle multi-site and localised URL variants?
• What is the credential model (per-environment config, secrets manager compatibility, least-privilege API scope)?
• What exactly changed between 1.0.x and 1.1.0 beyond the Laravel constraint — dependency bumps, code changes, CI additions?
• Is there a supported Statamic version matrix (v5 vs v6) and a PHP floor?
• What is the maintainer's stated support/response expectation?

Integration Approach

Stack fit. Target stack is Laravel 11/12 + Statamic (5.x/6.x) + a CDN or reverse-proxy cache. The package is environment-agnostic and config-driven, so it fits dev/staging/prod uniformly provided secrets are injected per environment.

Migration path. Two paths: (a) net-new install — add the dependency, publish config, add credentials, register the invalidation targets; (b) upgrade from 1.0.x — treat as a low-risk constraint bump, but pin the version, run the full content-publish smoke test, and diff the lockfile. For teams currently blocked on Laravel 12, this release is the unblocking event and should be sequenced into the next dependency-upgrade window rather than a standalone project.

Compatibility. Verify three constraints before committing: the package's Laravel constraint against our Laravel version, the package's Statamic constraint against our Statamic version, and the PHP floor against our runtime. Also confirm the queue driver we use is the one the package documents for async invalidation (sync vs Redis vs SQS changes the failure semantics materially).

Sequencing.

1. Pin and install in a dev environment against a non-production CDN zone.
2. Publish config; wire credentials through the secrets store, not .env commits.
3. Enable event hooks for a single collection first; validate that one publish produces exactly the expected purge calls (and no duplicates).
4. Expand to all collections; add the queue worker if async is supported.
5. Run in observe-only alongside existing manual/CI purge in staging for one release cycle; compare invalidation logs.
6. Cut over in production; keep the manual purge runbook live for at least one month as a fallback.

Operational Impact

Maintenance. Low code surface, but ongoing ownership sits with a small third-party agency. Budget for a periodic health check (does the package track new Laravel/Statamic majors promptly?) and accept that we may eventually need to vendor or fork. The Laravel 12 bump itself is evidence the maintainer is keeping pace — a positive signal to weigh against the bus-factor concern.

Support. Expect GitHub-issues-level support with no SLA. Internally, designate one owner who understands the invalidation topology, because debugging "why is this page stale" requires knowing both the CMS event flow and the CDN's cache-key rules.

Scaling. Invalidation volume scales with editorial activity, not traffic — which is reassuring. The real ceiling is the CDN/provider API rate limit. Bulk operations (imports, mass status changes, scheduled publishes) can generate invalidation storms; confirm batching/dedupe exists or add debouncing before enabling on high-volume collections. Async dispatch via a queue worker is strongly preferred over synchronous in-request purging, since a slow provider API should never sit in an editor's save path.

Failure modes.

• Expired or rotated API credentials → invalidations rejected; content silently stale.
• Provider rate limiting (HTTP 429) → dropped or throttled purges.
• Queue backlog or dead workers → delayed invalidation windows.
• Silent no-op after a CMS upgrade changes event names → the package appears installed but does nothing.
• Environment config drift (staging pointed at prod zone, or vice versa).
• Partial invalidation leaving mixed cached/stale variants across multi-site URLs.

Mitigations: alert on invalidation error rate and on zero-invalidation anomalies; add a synthetic canary that publishes a test entry and asserts the purge occurred; keep the manual purge runbook current.

Ramp-up. Low. A developer familiar with Laravel packages and Statamic's event model needs roughly half a day to install, configure, and verify a single-collection purge in a non-production environment. The larger time investment is not the package but the surrounding work: mapping the cache-key/tag strategy, agreeing least-privilege API credentials, and building the observability to detect silent failures. Communications-wise, editors need a short note that publishing now purges caches automatically, plus the escalation path for "my change isn't showing" reports.