What changes on install

Nebula is not a skin over the stock admin. Installing it changes the backend in ways you should know before you run setup:upgrade on a store with history.

The admin theme is forced

A plugin on Magento\Theme\Model\View\Design returns Nebula/backend for every adminhtml theme lookup. The theme has no parent, so nothing from Magento/backend loads: no RequireJS in the head, no Knockout, no LESS. Layout XML shipped by Nebula's own modules is scoped to that theme by a second plugin, so a merchant who switches back to the stock theme gets a stock admin rather than a half-styled one.

Core screens are replaced

Three mechanisms replace core screens:

Mechanism	What it does	Where
UI Component removal	Skips a core <uiComponent> from layout only when a Nebula grid or form definition with the same name exists. Everything else renders as stock.	Nebula_UiRemoval
Route mounting	A form definition that declares a route is injected into that page's layout, and the legacy blocks it names in replaces are removed.	Nebula_Form
Layout XML and DI preferences	Hand-written layout handles mount grids, and DI preferences replace a set of core admin blocks.	Nebula_Theme and the screen modules

See How screens are replaced.

A few core blocks are removed outright rather than replaced. Empty layout overrides under Magento_AdminAnalytics drop Adobe's admin usage-analytics tracking block from the header and, on the dashboard, both the analytics notification and the opt-in modal that would record the answer. The Advanced Reporting teaser block on the dashboard goes for the same reason. Nobody is asked to allow admin usage data collection and no answer is recorded. Nothing else about Magento_AdminAnalytics changes. The module is not disabled and no configuration value is written, so switching back to the stock admin theme brings these blocks back. See Upgrade and opt-out.

Configuration values set on install

Path	Value	Written by	Effect
cms/wysiwyg/enabled	enabled	Nebula_Quill data patch	Turns the editor on
cms/wysiwyg/editor	Nebula Quill adapter	Nebula_Quill data patch	Quill becomes the WYSIWYG editor
cms/pagebuilder/enabled	0	Nebula_Quill data patch	Turns off Adobe's Page Builder so Nebula's editor and media browser stay active
twofactorauth/general/force_providers	google,nebula_passkey	Nebula_Passkey config default	The first administrator must enrol both a passkey and an authenticator app, and chooses which to set up first

This turns off Adobe's Page Builder

The value above turns off Magento_PageBuilder. The free package ships no block editor of its own: CMS content is edited in the Quill rich-text field.

Database tables added

Table	Module	Purpose
nebula_grid_view	Nebula_Grid	Saved grid views per administrator
nebula_media_*	Nebula_Media	The media browser index, its derivatives, aliases, trash and path journal
nebula_email_document	Nebula_EmailTemplateEditor	Email builder documents
nebula_merchandiser_preference	Nebula_Merchandiser	Merchandiser preferences per administrator
admin_passkey_*, customer_passkey_* and the TOTP tables	Nebula_Passkey	Passkey credentials, TOTP secrets, recovery codes and challenges for administrators and customers
nebula_landing_page and its relations	Nebula_LandingPage	Campaign landing pages

The complete list of nineteen tables is in ACL resources and events.

One customer attribute added

A second data patch, in Nebula_Theme, adds the customer EAV attribute nebula_must_change_password. It is a hidden boolean, labelled Must Choose Their Own Password, default 0, and it appears on no form. It is set when an administrator sets a customer's password and cleared when that customer changes the password from inside their own account. See Customers and security.

Menu, roles and ACL

The menu is rebuilt, not decorated

Nebula does not add entries to the stock admin menu. It replaces it. Nebula_Menu removes 16 stock entries and adds 40 of its own, and Nebula_Reports, Nebula_System and Nebula_LandingPage remove and add more between them. Sub-menus that existed only to hold three or four items are gone, and their contents sit directly under the top-level entry: Catalog loses Inventory, Sales loses Operations, Marketing loses all four of its groups, Content loses its Elements and Media containers, and Stores has Settings, Taxes and Attributes rebuilt as Nebula-owned groups. The Reports groups are rebuilt under Nebula ids with the same names. Section by section, this is in Finding your way around.

Entry ids change, ACL resources do not. Nebula_Menu::catalog_products replaces Magento_Catalog::catalog_products as the id of the Products entry, but the entry still carries core's Magento_Catalog::products resource. Every rebuilt entry works this way, so the roles you have already set keep working and nobody gains or loses access on install.

A few stock entries are removed rather than rebuilt, because each is a marketing page for a hosted Adobe product rather than a working admin screen. Reports, Business Intelligence goes, and the Advanced Reporting link inside it goes with it, as does core's BI Essentials link beside that. The top-level Find Partners & Extensions goes too. The routes still resolve, so an existing subscription is unaffected and a bookmark still opens the page. Only the menu entries go.

Switching back to the stock admin theme

Under a legacy admin theme a plugin takes Nebula's menu contributions back out, removals included, so the stock entries return rather than leaving you with entries that lead nowhere.

Roles and ACL

Nebula ships ten role templates, and adds ACL resources only where it adds an act core has no resource for. A screen that replaces a core screen reuses core's resource, so the permissions a merchant has already set still apply. Existing roles keep their resources. New resources default to denied for custom roles until you grant them.

Two-step verification

Nebula registers a passkey as a provider in Magento_TwoFactorAuth and sets the forced provider list. That list is cumulative, so every provider on it must be enrolled. An administrator who already has Google Authenticator configured keeps it and is still required to enrol a passkey before the dashboard opens. Because only one provider is then outstanding, the choice screen is skipped and Magento sends them into its own configuration flow, which emails a configuration link. An administrator with nothing configured is asked to choose on the next sign-in. See First sign-in.

What does not change

• Storefront themes are not touched, and almost all storefront behaviour is left alone. The passkey module is the loud exception: installing it changes the storefront at once, because it overrides the core customer login form to offer passkey sign-in and adds a passkey section to the customer account. There is no setting that turns that off. Its storefront configuration group sets the relying party name and id and whether a passkey satisfies two-factor authentication, and nothing more. Nebula_Theme is the quiet one: a customer carrying nebula_must_change_password is held on the account edit page until they choose their own password, and nothing else on the storefront changes.
• Your data. No entity table is restructured, and Nebula reads the same collections core does. The one thing it adds to a core entity is the hidden customer attribute described above.
• Core controllers. Nebula forms post to the core save controllers for products, categories, customers, CMS pages and every other core entity. Validation on those routes is core's.