Backstage 1.44.0 ships a small-seeming change that will immediately wreck a lot of developer portals if you upgrade without scanning the release notes: the UnifiedThemeProvider no longer injects CssBaseline for you. If your app relied on that implicit CSS, your app’s typography, spacing, and resets will vanish until you explicitly import the stylesheet.
This is the single most consequential line in the changelog. It forces explicitness in theming — good — but it also creates an obvious upgrade hazard for platform teams that roll Backstage across many tenants and plugins.
Why the CssBaseline change will break your skin
UnifiedThemeProvider used to include CssBaseline so themes behaved consistently out of the box. Backstage removed that built-in injection and now requires the stylesheet import to preserve the previous appearance. Add the stylesheet import near your app root:
// add this to your root entry (e.g. packages/app/src/index.tsx or packages/app/src/App.tsx)
import '@backstage/core-components/styles.css';
import { UnifiedThemeProvider } from '@backstage/core-components';Why remove it? It’s the right call. Implicit global CSS is a time bomb in larger organizations: it hides coupling, makes theme overrides surprising, and blocks migration to different styling systems. But platform teams need to treat it like a breaking change — pin versions, run visual smoke tests, and include the import in automated upgrade playbooks. If you have custom plugins that rely on the implicit baseline, they’ll look wrong after upgrade.
Themer plugin: migration assistance, not a silver bullet
Backstage also introduces Themer — a UI plugin designed to help migrate Material-UI styles into Backstage’s UI patterns. Themer is pragmatic and overdue. After years of plugin authors mixing MUI and Backstage UI, a dedicated tool for mapping palettes, spacing, and component overrides will save a lot of manual work.
That said, Themer is a migration aid, not a migration guarantee. Expect fiddly edge cases: custom theme tokens, deeply styled Material-UI overrides, and CSS-in-JS idiosyncrasies will still require human attention. Themer signals that the Backstage maintainers understand frontend drift is a first-class platform problem — and they’re finally investing in tooling rather than docs alone.
Entrypoint flag: local dev gets predictable
The new --entrypoint option for the package start command is smaller but genuinely useful. Monorepos and custom app entries have been awkward to run locally: you often needed to hack scripts or symlink directories. With --entrypoint you can point the dev server at a specific entry directory during local development, which makes testing alternate app shells, feature-flags or tenant-specific entries far cleaner. Example usage looks like:
# point the dev server at a specific entry directory
yarn backstage-cli package start --entrypoint ./packages/my-app/src
# or with npx if you prefer
npx backstage-cli package start --entrypoint ./packages/my-app/srcThis is a practical win for platform teams that support multiple app variants from a single monorepo.
Weekly cadence and what it means for upgrade discipline
Backstage continues its weekly Tuesday cadence. That cadence is deliberate and helpful: predictable, small releases make it possible to automate upgrades and catch regressions early. But the cadence only helps if teams have upgrade discipline. The CssBaseline change is exactly the sort of small, semantically significant tweak that gets lost in automated upgrades unless you run visual tests or have a manual QA gate.
Opinion: treat Backstage like a product, not a dependency
Backstage is no longer a hobbyist SDK sitting at the edge of infra — it’s a core piece of developer experience. That means upgrades should be treated like product releases: changelog reviews, pinned rollouts, visual regression tests, and a plan for plugin compatibility. The changes in 1.44.0 are sensible, but they expose how many teams still treat Backstage as a dependency you can auto-update without read-throughs.
If you run Backstage at scale, add one item to your platform checklist: when a new Backstage release drops, scan the changelog for theme and entry-point changes, run your visual diff pipeline, and stage the release behind a feature flag. Ignore this and you’ll ship a broken developer portal — quickly, and to everyone.
For a short, focused look at what shipped in 1.44.0, see the companion write-up Backstage 1.44.0: UI revamp and Themer plugin.
Final thought: Backstage is maturing frontends into a platform concern. Expect more of these cross-cutting UI housekeeping changes. Teams that treat them as routine maintenance will benefit; the ones that treat Backstage like a library will get surprised in production.