Upgrade, opt out, remove¶
Upgrade¶
composer update "nebula/*"
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
bin/magento nebula:compile # production mode
bin/magento cache:flush
cachetool opcache:reset # or reload PHP-FPM; production mode
cache:flush does not touch the compiled manifest, so reset the opcache or reload PHP-FPM whenever nebula:compile has rewritten it. An upgrade rewrites the file at a path PHP has already compiled, which a fresh install does not. See Caching and production mode.
Every package in the set is released at the same version, and you should keep them there. The metapackage does not enforce it. It requires each package as ^1.0, so Composer resolves every module independently to the newest version your repository offers, and the set can drift apart. Keeping it on one version is your job: commit composer.lock and deploy from it.
An installed store carries no changelog to read. The metapackage installs no files of its own, so nothing lands under vendor/nebula/admin. Read the release notes for what changed, then run composer update --dry-run "nebula/*" before the upgrade. It names every package that would move and the version it would move to, and writes nothing.
Switch back to the stock admin without uninstalling¶
Nebula_ThemeSwitcher ships in the metapackage. Use its widget in the admin menu. Under Nebula it sits at the foot of the sidebar, and under a legacy admin theme it is appended to the menu bar. The widget checks the theme code against the registered adminhtml themes before it writes anything, and it keeps Magento's own admin/system_admin_design/active_theme in step with the switcher's own setting.
The same two values sit under Stores › Configuration › Nebula › Theme Switcher. Enable Module is already Yes on a fresh install, so normally you change only Active Admin Theme. Enable Module does more than hide the widget. Set it to No and the widget disappears, the forced-theme override stands down, and AdminThemeStateInterface::isNebulaRendering() answers true again, so Nebula renders again no matter what Active Admin Theme says. A legacy value left in Active Admin Theme no longer matters once the module is off: since 2026-09-13 every one of the module's plugins answers "Nebula" while it is disabled (before that, six of them read the stale value and stripped Nebula's own layout from a page that was rendering Nebula). A registered child of Nebula/backend recorded there counts as Nebula too — the child renders and every Nebula plugin stays on. Active Admin Theme is free text with no source model and no validation, and Magento throws Unable to load theme by specified key when it cannot find the path, so a typo takes every admin page down until the value is corrected from the CLI. That is why the widget is the better route, and why the field is worth reserving for recovery afterwards.
With another theme chosen, the switcher overrides the forced-theme plugin, and every Nebula DI preference and plugin that asks AdminThemeStateInterface::isNebulaRendering() stands down. Nebula's layout XML is filtered out under the other theme as well, so the stock admin renders as stock. Content editing is the exception, described below.
Two modules stay active under the stock theme on purpose: the switcher itself, so you can get back, and the passkey module, so you can get in.
bin/magento config:set nebula_theme_switcher/general/enabled 1
bin/magento config:set nebula_theme_switcher/general/active_theme Magento/backend
bin/magento cache:flush
Content editing does not come back with the stock theme
The install patch leaves cms/wysiwyg/editor pointing at Nebula_Quill/js/wysiwyg/quill-adapter and cms/pagebuilder/enabled at 0, and the switcher changes neither. That adapter is a shim whose setup() only unhides the textarea. The real editor ships in the Nebula theme bundle, which the switcher strips under a legacy theme so it cannot 404. CMS and product content fields therefore render as a plain textarea, with Adobe's Page Builder off. To edit content during a stock-admin day, choose another editor under Stores › Configuration › General › Content Management and set cms/pagebuilder/enabled to 1. Put both back before you switch to Nebula: Nebula checks for that exact editor value, and without it its own wysiwyg field falls back to a plain textarea too.
Disable Nebula¶
Nebula_Core cannot be disabled on its own. Nebula_Theme, Nebula_Menu, Nebula_Skin, Nebula_ProMarketing and Nebula_ThemeSwitcher each declare nebula/module-core in composer.json, and every other module reaches it transitively through one of those five, most of them by way of Nebula_Component and Nebula_Skin. Magento builds its disable check from those Composer requires and walks them transitively, so bin/magento module:disable Nebula_Core exits with a "cannot be disabled because modules depend on it" constraint listing the whole enabled set.
Do not reach for --force. It skips the check and leaves Nebula_Theme and Nebula_ThemeSwitcher still declaring DI arguments on Nebula\Core\Block\Menu and a preference for Nebula\Core\Api\V1\AdminThemeStateInterface while the shell module's own DI, layout and routes are gone. The result is a half-configured admin.
To stand Nebula down while everything stays installed, use the theme switcher above. To take the modules out of the loading order, disable the whole set at once:
# Review the enabled modules and disable the complete Admin package set together.
# Do not include separately installed Nebula products such as Multiblog.
bin/magento module:status --enabled
bin/magento setup:upgrade
bin/magento cache:flush
The set really does go as one. Nebula_ThemeSwitcher requires Nebula_Core, Nebula_Component, Nebula_Form and Nebula_UiRemoval, and Nebula_Passkey requires Nebula_Theme, so module:disable refuses any subset that disables a dependency and leaves one of those two enabled. The two modules that stay active under the stock theme cannot be kept while the rest are disabled. If you want Nebula out of the way but still want a way back in, switch the theme instead of disabling modules.
Check second factors before you disable the passkey module
Nebula_Passkey registers the nebula_passkey two-factor provider, and its etc/config.xml puts that code into twofactorauth/general/force_providers as google,nebula_passkey. Disabling the module takes the provider with it, so an administrator whose only enrolment is a passkey loses their second factor and cannot sign in. Clear any saved Force providers value naming nebula_passkey first, and have those administrators enrol an authenticator app, before you disable anything. nebula:passkey:reset-two-step does not help here. It clears only Nebula's own two-step secret and recovery codes and never touches Magento_TwoFactorAuth.
Roll back to a previous version¶
composer require nebula/admin:<previous-version> does not roll anything back. The metapackage carries no code and pins nothing, and the metapackage allows compatible ^1.0 dependency versions, so Composer leaves the newer modules exactly where they are.
Roll back by restoring the composer.lock from before the upgrade and installing from it:
git checkout <commit-before-the-upgrade> -- composer.lock
composer install
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento nebula:compile # production mode
bin/magento cache:flush
cachetool opcache:reset # or reload PHP-FPM; production mode
A rollback rewrites the manifest at that same path, and cache:flush does not touch it, so reset the opcache or reload PHP-FPM here as well. See Caching and production mode.
With no lock file to go back to, name every package at the old version on one composer require line. composer require takes no wildcards, so that means the metapackage, every module listed in The modules, nebula/module-theme-switcher and nebula/theme-adminhtml-backend.
Take a database dump first
Six modules ship declarative schema: Nebula_EmailTemplateEditor, Nebula_Grid, Nebula_LandingPage, Nebula_Media, Nebula_Merchandiser and Nebula_Passkey. setup:upgrade reconciles the database down to what the installed version declares, so a downgrade drops the columns and tables the older db_schema.xml no longer names.
A rollback does not revert the configuration written on install. The data patch that set cms/wysiwyg/enabled, cms/wysiwyg/editor and cms/pagebuilder/enabled has no revert step, and it is already recorded in patch_list, so those three values survive the rollback and the patch will not run again. Set them by hand if the older version needs different ones.
Remove¶
composer remove nebula/admin
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento cache:flush
Composer removes every package the metapackage pulled in that nothing else requires. Removal does not revert the configuration values written on install. If you want Adobe's Page Builder back, set cms/pagebuilder/enabled to 1 and choose an editor under Stores › Configuration › General › Content Management.
The database tables Nebula added are not dropped. The nineteen are named in ACL resources and events, and they are two different kinds of leftover. Operational data you can drop when convenient: nebula_grid_view, the six nebula_media_* tables, nebula_email_document, nebula_merchandiser_preference and the three nebula_landing_page* tables. Credential data, which is a retention decision rather than a tidy-up: admin_passkey_credential, customer_passkey_credential, admin_totp_secret, customer_totp_secret, admin_totp_recovery_code, customer_totp_recovery_code and admin_passkey_challenge.
Removal also leaves the customer attribute nebula_must_change_password on the customer entity. It is inert once the modules are gone, and removing it means deleting the eav_attribute row and its values.