The single most consequential change in Backstage v1.44.0 is petty but painful: the framework no longer injects a global CssBaseline for you. That sounds trivial until your plugin layout flips, fonts snap to defaults, or your CSS reset disappears in production because you relied on an implicit global side-effect. Backstage made a deliberate choice to make theme and global styles explicit, and platform teams upgrading will feel it immediately.
Heres what changed and what you need to do now
-
UnifiedThemeProvider no longer applies a built-in CssBaseline. If you upgrade and your UI looks unstyled, add the Backstage UI stylesheet to your app entry.
-
The dev tooling now supports a --entrypoint option on package start so development packages can point at custom entry directories. That helps when you keep several dev apps or experiment with alternate bootstraps.
-
A new Themer plugin arrived to help migrate from Material UI (MUI) to Backstage UI, which is the right move for large design-system transitions but wont eliminate the work of harmonizing tokens and component differences.
Concrete upgrade steps
- Add the stylesheet to your app entry. Put this near the top of your App.tsx or dev entry file:
// App.tsx (or dev entry)
import '@backstage/core-components/styles.css';The explicit import makes the dependency obvious in your bundle and prevents silent regressions in CI or staging.
- Use the new --entrypoint when running dev packages that don't use the default src/index or app entry. Example:
backstage-cli package start --entrypoint packages/my-plugin/dev-entryThis is handy for mono-repos that host multiple developer-facing apps or when you want to iterate on an alternative shell without disturbing the primary entry.
Why the CssBaseline removal matters more than it looks
Implicit global CSS is a long-term maintenance toxin in platform code. It hides coupling between plugins and the host UI and makes upgrades unpredictable. Backstage forcing an explicit import is the correct engineering move: it surfaces intent and makes styling dependencies visible to bundlers, CI, and code reviewers.
That said: it's a breaking change that will bite teams who treated Backstage as a black-box SDK. If you have custom font loading, global resets, or styling collisions, expect regressions during the upgrade window. The thing I dont like is that its a small change with big visible impact your dashboards will make Slack noise before the PR lands in your infra repo.
The Themer plugin: helpful, not magical
The Themer plugin is the project's answer to a real problem: teams migrating big design systems from MUI to the Backstage UI primitives. The plugin should speed theme token translation and surface the places where component behavior diverges, but its not an auto-migration. Expect manual audits of spacing, elevation, and interaction states. Treat Themer as scaffolding for the migration, not a converter that eliminates QA.
Ongoing cadence: watch pre-release tags
Watch pre-release tags on the Backstage repo for upcoming changes the project iterates quickly and keeps layering incremental cleanups. These are the kinds of tidy-ups platform teams should track closely; they improve long-term maintainability but increase short-term upgrade cost.
Final take
This is the right call: explicit global styling is healthier for long-lived platform code. But it raises the bar for upgrades teams that haven't automated visual checks or pinned UI-related transitive deps will pay for this with firefights and rollbacks. If your Backstage runs the whole developer portal, treat v1.44.0 as an infrastructural change, not a minor dependency update: add the stylesheet import, test all dev entrypoints with the new --entrypoint flag, and use the Themer plugin to systematize your MUIBackstage UI work.
If you ignore this, you won't just get a styling bug you'll get false confidence. Backstage is making its styling surface explicit. The sooner your platform treats UI surface area as part of the contract, the fewer surprise outages you'll have when the next "small" cleanup lands.