Core Web Laravel Package

Product Decisions This Supports

• Platform decision: Laravel Cloud becomes a first-class target. Until now, Glide renditions and generated icons were quietly tied to a single container's public/img and local disks, so Cloud's multi-replica, redeploy-on-every-release model produced 404/400 image URLs and 500s on CP thumbnails. This release removes that as a reason not to move to Cloud — treat "can we host on Cloud?" as unblocked for image-heavy Statamic sites.
• Feature decisions that were previously Cloud-unsafe are now safe to ship: turning media on, relying on Peak Tools' generated favicon set, Peak SEO's generated social images, and image presets at upload. Previously these were per-replica or lost on deploy — a silent quality bug, not a visible one.
• Build vs buy: reinforces buying this package rather than hand-rolling Glide cache plumbing, a favicon/social-image pipeline, or a "which disk is this on?" abstraction. The package now owns the Cloud-vs-not branching so we don't.
• A cost/performance tradeoff decision we now have to make explicitly: on Cloud, Glide renders through PHP on every request and re-renders after each deploy (the true/hybrid caches are disabled by design). For a site with high image volume or large renditions, that is a real CPU/latency budget line. If image traffic dominates, the roadmap answer may be a CDN/edge image service rather than this package's caching — decide with numbers, not vibes.
• Release engineering becomes a checklist item, not a hope: image URLs change shape (/img/containers/... → /img/asset/...?s=), so static-cache invalidation belongs in the deploy path (core-web:deploy already handles it). Worth encoding in our deploy runbook and in any client handover docs.
• Support/incident load: removes a recurring class of "images broken after deploy / thumbnails 500" tickets on Cloud. That's a Deflection win, quantifiable if we were tracking those tickets.

When to Consider This Package

Consider it when:

• We are on Laravel Cloud, or actively evaluating it, and running Statamic with Glide — this release is the difference between "works" and "works correctly across replicas."
• The site runs more than one replica or deploys frequently (zero-downtime, container replacement), where any file written to a container's local disk is suspect.
• We depend on Peak Tools favicons or Peak SEO social images — those were being generated per-replica and lost on deploy; the bucket-backed disks fix a genuine correctness bug.
• We want media enabled and want asset uploads/presets to behave consistently rather than being disabled to work around Cloud.
• We're willing to accept one explicit, non-trivial upgrade in exchange for it (see below).

Look elsewhere, or defer, when:

• The site is single-server / Forge / VPS with persistent public/img. The Cloud fixes buy nothing there, while the upgrade still changes image URLs and requires a static-cache clear — cost without benefit. Don't take this release just to be current.
• Image delivery is performance-critical at scale (catalogs, galleries, high-traffic marketing). Uncached PHP rendering per image and re-rendering after every deploy may be the wrong trade; evaluate an external image CDN instead of leaning on Glide caching.
• We deliberately tuned image_manipulation.cache to true/hybrid for performance on Cloud and considered that acceptable — this release overrides that choice on Cloud. Confirm the perf impact before adopting.
• Not on Statamic/Glide, or the site is fully static with no CP usage.

Upgrade cost to budget (one deploy, but it needs a human):

• Confirm the Cloud image_manipulation.cache setting via grep -n "'cache' =>" config/statamic/assets.php; expect uncached rendering and changed image URLs.
• Clear the static cache once after deploy; verify a page image and a CP asset thumbnail.
• If media is on and favicons/social_images use the local driver: run php artisan media:sync push --force, regenerate any icon set Peak Tools created on Cloud, restore allow_uploads: true if it was disabled, and remove committed icons from public/favicons (Cloud serves public/ before the bucket redirect — otherwise stale files win).
• Verify with php artisan media:check --disk=favicons (and --disk=social_images) and check that the favicon link redirects to the bucket.

How to Pitch It (Stakeholders)

For executives (one paragraph): This release makes our Statamic image pipeline actually correct on Laravel Cloud. Previously, images, favicons and social-share images were generated inside a single container, so users saw broken images after deploys and editors saw error thumbnails in the control panel. That was the main technical objection to hosting on Cloud. This release removes it: images render reliably on every replica, and generated icons and social images live on shared storage instead of dying with the container. The tradeoff is deliberate and modest — image resizing now happens in PHP per request instead of being cached per container, and each deploy re-renders on demand. It requires a short, well-documented one-time upgrade (a deploy, a cache clear, a media sync and a favicon check), not a data migration.

For engineering (the ask):

• Adopt v0.24.0 before or alongside any Cloud migration; the cloud feature flag now owns the Cloud-specific branching, so we should not build our own workarounds.
• Accept the behavior change: no true/hybrid Glide cache on Cloud; every /img/asset/...?s= URL carries its source so each replica renders its own copy. Presets are also no longer generated at upload there — do not build features that assume otherwise.
• Treat the upgrade as a deploy task with verification, not a composer bump: cache clear, media:sync push --force, regenerate Peak Tools icons on Cloud, allow_uploads: true on those containers, delete committed public/favicons, and run media:check for both disks.
• Flag any place in our code, tests, or client documentation that hardcodes /img/containers/... URLs — they will change.
• If image traffic is a meaningful share of requests, bring a measurement to the next roadmap review; the fallback is an external image CDN, and that's a separate buy decision.