Craft 6 deleted its filesystem layer and handed my assets to Laravel
Here's a Craft 6 change that reads like a footnote and is actually a philosophy: the alpha deleted its own filesystem layer. Volumes and asset transforms no longer point at Craft-managed "filesystems" — they point at Laravel disks you configure in config/filesystems.php. For a Drupal developer raised on stream wrappers and contrib adapter modules, watching a CMS remove its own storage abstraction and defer to the host framework is the whole "Craft is becoming a Laravel app" story in one commit.
What got removed
From the alpha.19 changelog (1 Oct 2026): "Removed Craft-managed filesystems and their control panel settings. Volumes and Craft asset transformers now reference Laravel filesystem disks configured in config/filesystems.php, and each defines whether its assets have public URLs. Existing filesystem references are migrated to matching disks automatically, with an actionable error if a disk isn't configured." The Filesystems settings page is gone, and — this is the ecosystem part — "Plugins can no longer register custom Craft filesystem types" (HasFilesystemTypes removed). PR #19650 is blunt about why: Craft's Filesystems were "merely a small wrapper around Laravel's filesystem disks." If it's a thin wrapper, delete it and use the real thing.
The 6.x upgrade guide says each old filesystem should become a disk keeping its handle; the existing values live in the fs key of the project config, and the upgrade tool (composer global require craftcms/craft6-revamp, then craft6-revamp) suggests what to add to the disks array. It's part of a bigger Laravel-shaped reshuffle, by the way: web/ → public/, templates/ → resources/views/, translations/ → lang/, config/* → config/craft/.
The catch a Drupal hand feels immediately
In Drupal, your storage lives behind stream wrappers (public://, private://) and, for S3 and friends, a contrib Flysystem adapter module — but the wiring is still, broadly, Drupal's concept. Craft 6 goes the other way: it drops its own concept entirely. The practical consequence is where configuration moves. Storage config leaves project config (the fs key, editable in the control panel) and becomes code in config/filesystems.php, with secrets in env. That's cleaner if you already think in Flysystem — and it means the control panel is no longer the place you wire up storage. "Less code in core" is also "my CP can't configure a bucket anymore." Whether that's a win depends entirely on who maintains the site.
There's an ecosystem question I can't fully answer: every third-party filesystem plugin concept is gone, and PR #19650 doesn't discuss the fallout. The first-party aws-s3 repo README still says it needs "Craft CMS 4.0.0+ or 5.0.0+" — I found nothing about a Craft 6 build. I'm not going to claim any specific plugin is stranded, only that the transition page is clear that Craft 6 plugins need a new major and cross-compatible ^5.0.0|^6.0.0 releases "will not be possible."
The payoff: BlurHash and colors, free, in GraphQL
The same release cycle hands the frontend something nice. Image assets now carry a BlurHash string (asset.blurhash in Twig, blurhash in GraphQL), plus colors and placeholderDataUrl fields in GraphQL, and the CP shows a blurred placeholder while thumbnails load. For anyone building a headless frontend, that's exactly the lazy-load-placeholder data you'd otherwise compute yourself. Dominant color comes from Intervention Image's palette analysis (k-means in Oklab on a 100px downscale, working with GD, Imagick or libvips) and is stored on the asset; uploads even sample colors in the browser so the server doesn't have to.
This is the real headless win of the batch: BlurHash and a dominant-color palette in your GraphQL response, with no plugin and no custom resolver. The catch is the small print.
And there is small print. BlurHash is computed on request, not stored (per PR #19755), encoded from a 4×3 grid for landscape/square and 3×4 for portrait; it has no alpha channel, so transparent regions blend over white. Dominant color is backfilled only "the next time they're indexed" — there's no dedicated backfill command mentioned — so existing assets simply won't have this data until re-sampled. I haven't measured what on-request BlurHash costs under load, so I won't tell you it's free in CPU terms; I'll only tell you it's free in code.
The takeaway
If you know Laravel and Flysystem, Craft 6's storage story is a simplification you'll like — fewer abstractions, a config file instead of a CP screen, and genuinely useful image metadata handed to your frontend for nothing. If you don't, or if your site's operators expect to point a volume at a bucket from the admin UI, this is a real shift in where the controls live. It's also an alpha: remote-storage drivers lean on Laravel 13.x's docs (the requirements page doesn't even pin a Laravel version), old assets lack the new metadata until reindexed, and I haven't run the upgrade tool. Read the storage section of the upgrade guide before you get excited about the BlurHash.