Backstage just made a change that will be visible in every portal: v1.44.0 drops the built-in CssBaseline from UnifiedThemeProvider. That’s not a cosmetic tweak — it forces every platform that has leaned on implicit styling to take ownership of global CSS and theme wiring.
If your IDP has custom themes, heavy MUI overrides, or fragmented style imports, this will surface breakage quickly. The release expects you to explicitly opt into the new Backstage UI stylesheet from your app's UI package (for example, import the stylesheet exported by your UI components package) and to migrate custom themes to the new Backstage UI system. There’s help: a Themer plugin intended as a controlled migration path, plus a CLI option to run alternate entrypoints while you refactor.
Why this matters
CssBaseline was convenience and coupling. It hid complexity — but it also meant any change to global styles rippled unpredictably across consumers. Removing it forces teams to centralize the global styles pipeline. That’s the right move. The alternative was continuing to carry tech debt where different teams patched styles in their own corners of the monorepo and upstream changes caused silent visual or accessibility regressions.
But the work is real. Expect to do three things immediately:
- Add the stylesheet import where your app bootstraps:
// your-app/src/index.tsx
// example: import the stylesheet provided by your Backstage UI package
import '@backstage/core-components/styles.css';- Reconcile any MUI overrides and custom fonts with the Backstage UI tokens and component primitives.
- Use the Themer plugin to incrementally replace MUI patterns rather than trying a big-bang migration.
The Themer plugin is the practical part of this release. It’s designed to let platform engineers map MUI-based tokens and components onto the Backstage UI system, providing a predictable, testable path to update shared components across teams. In plain terms: don’t expect to swap imports and be done — plan for iterative updates and snapshot visual tests.
New CLI ergonomics: safe experiments
The app start command now supports a --entrypoint option so teams can run alternate entry directories without restructuring the whole monorepo. For example:
# example using yarn workspaces
yarn workspace my-app start --entrypoint=./entries/migrationUse this to spin up a migration branch in CI or a canary environment where you validate theme changes and accessibility before touching prod entrypoints.
Operational refinements and upgrade hygiene
Official plugins also picked up pragmatic tweaks — remote-file caching behavior was adjusted to reduce fetch churn for busy portals. More importantly, community guidance around upgrades is maturing: platform teams are encouraged to perform incremental upgrades using backstage-cli's version-bump tooling, selectively adopt nightly builds for specific packages, and audit changelogs package-by-package instead of chasing the monorepo tip.
My take: this is overdue and sensible. Backstage needed to break implicit styling guarantees to get a consistent, maintainable UI system. But teams that treat Backstage as just another dependency will pay. If your portal has not invested in centralized theme ownership, expect a sprint to unearth style debt and to shore up visual tests.
Practical next steps (two immediate bets)
- Add the styles import and run your app; catch regressions back-to-back with visual snapshot tests. 2) Use the app start --entrypoint flag to launch a migration canary wired to Themer so you can iterate without touching the main entrypoint.
This release isn’t about new bells and whistles — it’s a maturation move. Backstage is choosing stricter UI primitives over fragile convenience. Teams that treat this as an annoyance will end up with brittle portals; teams that treat it as an opportunity to centralize theme ownership will get a more predictable IDP. Expect a few weeks of churn across large orgs, and then steadier, safer UI changes going forward.