Core Web Laravel Package

Technical Evaluation

Architecture fit. This package sits at the infrastructure/config seam of a Laravel + Statamic application, not in domain logic — its levers are feature flags (cloud, media), filesystem disks, Glide cache mode, and a handful of artisan commands. That is a favorable coupling surface for a TPM: adoption is a config-and-runbook change, not a refactor. v0.24.0 removes two per-container-local assumptions (Glide renditions cached in one container's public/img plus a key store; favicon/social-image disks on local) and replaces them with stateless/bucket-backed behavior. That is precisely the multi-replica correctness work a team would otherwise hand-roll and get wrong. The strategic value of the release is that it converts a class of intermittent, hard-to-reproduce production bugs (404/400 images, 500 CP thumbnails, icons vanishing at deploy) into documented, deterministic behavior.

Integration feasibility. High. The upgrade is detection plus commands, with no data migration:

• grep -n "'cache' =>" config/statamic/assets.php to find true/hybrid.
• grep -n "'favicons'\|'social_images'" config/filesystems.php to find local-driver disks.
• php artisan media:sync push --force (once, post-deploy), php artisan media:check --disk=favicons|social_images (verification), core-web:deploy (static cache clear). The one non-automatable step is regenerating a Peak Tools icon set from the CP.

Technical risk.

• Performance/cost regression on Cloud (highest). Glide now renders through PHP on every image request, uncached, and each replica renders its own copies — re-rendered again after every deploy. Deploy becomes an image cold-start event. Image-heavy pages with meaningful traffic are the exposure, and the cost shows up as PHP worker saturation, not as an error.
• Deploy-window correctness. Image URLs change shape (/img/containers/... → /img/asset/...?s=). If the static cache is not cleared, pages served across a mixed-replica window will 404. Ordering matters.
• External URL consumers. Signed ?s= URLs mean any hardcoded/parsed /img/ reference (email templates, sitemaps, social cards, static exports, test fixtures) breaks silently.
• public/ shadows the bucket. Cloud serves public/ before the redirect, so committed public/favicons produces stale favicons that read as a caching bug and are slow to diagnose.
• Leftover allow_uploads: false on those containers blocks editors with no obvious error path.
• Pre-1.0 semantics. A 0.24.0 minor bump changes Cloud defaults with no deprecation window. Version pinning is mandatory, not advisory.

Key questions.

1. What is our image request rate and p95 payload on Cloud pages? Does PHP-rendered Glide fit the request budget, or do we need a CDN in front of /img/?
2. The notes say "a cache on a disk of its own is kept" — can we point Glide at a shared disk and recover cross-replica caching, instead of accepting uncached rendering?
3. Is core-web:deploy wired into our deploy hook today, and does it run once per deploy or per replica?
4. Does the cloud flag auto-detect the environment, and do we have non-Cloud environments that must stay on true/hybrid?
5. Who owns the manual CP icon-set regeneration, and what is the recovery path if it's missed?
6. Do any downstream systems consume /img/ URLs directly?

Integration Approach

Stack fit. Laravel + Statamic on Laravel Cloud. The favicon/social-image remap requires the media feature to be on; the Glide change applies to any Cloud site regardless. Everything is expressed through config/statamic/assets.php and config/filesystems.php, so it composes with existing config management rather than introducing a new one.

Migration path (staged).

1. Inventory: enumerate feature flags per environment; grep for the Glide cache setting, the two disks, and any container with allow_uploads: false.
2. Preview on real topology: upgrade in a Cloud preview environment with 2+ replicas — the bug being fixed does not reproduce on a single container, so a single-replica test proves nothing.
3. Apply config + sync: let the cloud feature take effect, run media:sync push --force, regenerate the icon set from the CP, regenerate social images.
4. Clear and verify: run core-web:deploy, then check a page image, a CP asset thumbnail, and that a favicon link 302s to the bucket; run media:check on both disks.
5. Git hygiene: only after the push is confirmed, remove public/favicons from git; redeploy and re-verify no shadowing.
6. Promote, then watch image 4xx/5xx and PHP latency for 24–48h.

Compatibility. Cloud-only behavioral change; non-Cloud sites are unaffected and can stay on true/hybrid. Requires the Statamic assets config keys as documented and Peak Tools / Peak SEO present for the generation paths. Anything that parses or hardcodes image URLs needs review before promotion.

Sequencing constraints. Config → push → regenerate → cache clear → git cleanup. Clearing cache before pushing leaves favicon 404s; removing public/favicons from git before the push loses the only copy of the icons. Treat this as a fixed-order runbook, not a checklist.

Operational Impact

Maintenance. Two new commands enter the runbook: media:sync push --force after any media-set change, and media:check --disk=... as a post-deploy health check. Icon-set regeneration stays a manual CP step — assign an explicit owner and note it in the release checklist. Pin the package version; 0.x minors change Cloud defaults.

Support. Expect three ticket shapes, each with a one-line diagnostic worth writing into the on-call doc: broken page images after a deploy (static cache not cleared), stale/unupdated favicons (committed public/ shadowing the bucket), missing CP thumbnails (Glide cache residue). Editor-facing support is the real delta — the favicon upload/regeneration flow changes for them, not just for engineers.

Scaling. This is the release's central trade: horizontal correctness bought with per-request PHP rendering and a re-render on every deploy. Levers, in order of leverage: put a CDN in front of /img/ (respecting signed URLs and cache headers); evaluate a shared Glide cache disk to restore cross-replica reuse; audit image-heavy templates; right-size PHP workers. Run a load test before any campaign if image traffic is material.

Failure modes.

• 404/400 on cached pages post-deploy, and 500s on CP thumbnails — same root cause, same fix (static cache clear).
• Cold-start render storm immediately after each deploy.
• Favicon/social-card 404s or stale images for external crawlers and unfurlers.
• allow_uploads: false blocking editors silently.
• Old /img/containers/ URLs held externally, failing with no traceable origin.

Ramp-up. Low for engineers (config keys plus three commands), moderate for editors (CP regeneration step and new favicon flow), moderate for ops (new deploy-hook step and a verification checklist). Budget roughly half a day of engineering plus one full deploy cycle, and add a load test if image traffic is non-trivial.