Craft 6 deleted craft:on and craft:off — proof the Laravel rewrite isn't just marketing
When Craft announced it was rebuilding Craft 6 on Laravel, the framing was "(mostly) a strict port, with little refactoring." That's the kind of claim that's easy to nod along to and hard to actually verify from a blog post. 6.0.0-alpha.18, released 1 September 2026, is a genuine receipt for it — because what it does is delete a piece of Craft's own infrastructure and hand the job to Laravel's equivalent outright.
What actually got removed
Craft's own system-status mechanism — the thing behind "put the site into maintenance mode" — is gone. In its place: Laravel's native maintenance mode, with an admin-only Maintenance Mode control added to General Settings. Specifically removed: GeneralConfig::$isSystemLive, app()->isLive(), and the core craft:on/craft:off console commands. That's not "deprecated, still works" — those APIs are gone from 6.0.0-alpha.18 onward. The one safety net: deprecated compatibility remains available through craftcms/yii2-adapter, which is exactly the kind of transition shim you'd want if you were actually serious about not breaking the plugin ecosystem overnight, rather than just saying you were.
The same release moved asset-transform configuration onto equally Laravel-flavored footing: new AssetTransformers and AssetTransformDrivers classes, a GeneralConfig::$defaultAssetTransformer setting, and transformers now configured per volume by handle under Settings → Assets → Asset Transformers — replacing the old core transform-arguments API, whose per-call immediate-generation arguments were removed from both the PHP API and GraphQL.
Why this is the interesting receipt, not the maintenance-mode feature itself
Nobody needed convincing that maintenance mode is a useful feature — Craft already had one. What this release actually demonstrates is that the "strict port to Laravel" framing means replacing Craft's own subsystems with Laravel's rather than keeping Craft's implementation running in parallel underneath a compatible API. If the rewrite were mostly marketing, the path of least resistance would be: keep isSystemLive() working, make it call into Laravel under the hood, ship a deprecation notice, move on. Instead the public API itself is gone, and what's left standing in for it is a compatibility shim through a dedicated adapter package — a real migration cost for plugin authors, cushioned but not hidden.
The Drupal comparison
Drupal's equivalent is system.maintenance_mode state plus drush sset system.maintenance_mode 1, or the UI toggle under Configuration → Maintenance mode — a Drupal-native mechanism that's never had a reason to defer to an underlying framework because Drupal doesn't sit on top of one the way Craft now sits on Laravel. It's a fair comparison point precisely because it highlights what's actually new here: Craft previously had its own equivalent of exactly this, independent of any framework underneath it, and 6.0 is the release where that independence started getting traded away piece by piece for alignment with Laravel's own primitives.
What this means if you maintain a Craft plugin
If any plugin code calls Craft::$app->isLive(), checks GeneralConfig::isSystemLive, or shells out to craft:on/craft:off, it still works today through the yii2-adapter shim — but it's calling a deprecated path, not a stable one, and alpha.18 is the commit where the countdown on that actually started. I'd rather migrate that kind of plugin code on my own schedule than wait for the shim's deprecation window to actually close.