Magento vs Nebula
The same Magento, a very different admin
Nebula keeps your Magento backend intact and replaces the part you actually look at all day. Here's what changes — from the definition format down to the runtime — and why it matters for the people using it.
Default Magento Admin vs Nebula
Keep Magento. Replace the admin experience. Nebula gives teams a modern interface and gives developers a cleaner way to extend it.
Default Magento Admin
ui_component/product_listing.xml
<listing xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="urn:magento:...">
<settings>
<spinner>product_columns</spinner>
<deps>
<dep>product_listing.product_listing
_data_source</dep>
</deps>
</settings>
<dataSource name="product_listing_data_source"
component="Magento_Ui/js/grid/provider">
<settings>
<updateUrl path="mui/index/render"/>
</settings>
<aclResource>Magento_Catalog::products</aclResource>
<dataProvider
class="Magento\Catalog\Ui\DataProvider..."
name="product_listing_data_source">
<settings>
<requestFieldName>id</requestFieldName>
<primaryFieldName>entity_id</primaryFieldName>
</settings>
</dataProvider>
</dataSource>
<!-- 200+ more lines of XML... -->
<!-- + RequireJS module -->
<!-- + KnockoutJS template -->
<!-- + UI Component JS class -->
</listing>Nebula
grid/product_listing.json
{
"title": "Products",
"dataProvider": "catalog_product",
"columns": [
{
"field": "entity_id",
"label": "ID",
"sortable": true,
"width": "80px"
},
{
"field": "name",
"label": "Product Name",
"sortable": true,
"filterable": true
},
{
"field": "sku",
"label": "SKU",
"sortable": true,
"filterable": true
},
{
"field": "price",
"label": "Price",
"sortable": true,
"type": "currency"
},
{
"field": "status",
"label": "Status",
"@use": "snippet/status_badge"
}
],
"actions": {
"edit": {
"route": "catalog/product/edit",
"label": "Edit"
}
}
}What Changes With Nebula
Nebula improves the day-to-day admin experience and gives developers a cleaner foundation to build on.
| Feature | Default Magento Admin | Nebula |
|---|---|---|
| Frontend stack | RequireJS, KnockoutJS, jQuery, and older patterns | A modern frontend approach built around Tailwind CSS, Alpine.js, and cleaner PHP rendering |
| Admin experience | A dated backend look that feels separate from modern ecommerce tooling | A current, polished admin interface that feels faster and easier to use |
| Theming | Static backend styling with heavier theme work | Runtime skins, dark mode, and easier branding control |
| Navigation | Limited personalization in day-to-day admin navigation | Sidebar or top menu, pinned items, and quicker access to common tasks |
| Forms and grids | Heavier UI patterns with more frontend overhead | Cleaner admin definitions with less friction for ongoing customization |
| Accessibility | No dedicated accessibility themes built in | High contrast and color-blind-friendly skins included |
| Customization cost | More time spent working around legacy frontend behavior | Faster iteration for agencies, Magento teams, and extension developers |
| Adoption path | Modernization often implies a bigger platform-level change | Keep Magento or MageOS and replace the legacy admin theme |
| Compatibility | Legacy dependencies are embedded in the default experience | A safer modernization path with room for existing third-party modules |