Backstage just made a deceptively small change that will cause more immediate headaches than any new API: UnifiedThemeProvider no longer injects a global CssBaseline. That means every Backstage app that counted on implicit global CSS now has to explicitly import the Backstage global stylesheet from the core components package; otherwise your app will render unstyled components or suffer layout shifts.
This is the most consequential piece of v1.44.0 because it exposes a longstanding footgun. Implicit global styles are convenient while youre onboarding, but they hide coupling. When many micro-frontends inherit a single baseline CSS, a change to that baseline is a global blast radius. Making the import explicit forces auditing, versioned control, and clearer theming contracts across IDPs.
The immediate work: search your app manifests and entrypoints for UnifiedThemeProvider usage and add this import at the top of your root entry file:
import '@backstage/core-components/styles.css';Do this before you upgrade or your pages will render unstyled components, layout shifts, or broken spacing. Yes, its tedious; no, it isnt a bug its deliberate.
Why this matters beyond a missing CSS file
v1.44.0 doesnt stop at stylistic hygiene. Backstage ships a new Themer plugin intended to help teams centralize and migrate theme generation (for example, consolidating custom Material UI themes to a consistent Backstage theme). Together, the two moves follow a pattern: reduce implicit framework behavior, and give teams tooling to adopt explicit, consistent design systems. If your org is standardizing a golden path for DX, the Themer plugin reduces friction for that consolidation. If youve been letting teams use their own Material UI forks and hoping for the best, this release forces a conversation.
Also of note: the local dev tooling now accepts an --entrypoint flag when starting a Backstage app (for example via the CLI/yarn start command). For platform engineers running complex monorepos with multiple dev app roots, that option makes local development predictable without hacking package.json scripts: point your dev server at the correct directory and stop juggling symlinks and custom scripts.
Operational guardrails you should fold into your upgrade plan
Backstage also continues to publish supported Postgres compatibility guidance (covering a moving window of recent major versions), which gives you concrete upgrade math to use when planning maintenance windows and rolling policies for your IDP. Long-lived portals that lag on upgrades will need to schedule updates sooner to stay within supported database versions not a bad nudge for operability, but one that needs calendar time and testing.
Plugin surface area is growing too. Third-party integrations (for example, release and workflow catalog plugins) are increasingly making Backstage a central place to orchestrate release pipelines. Spotifys runtime notes also tightened behavior around cache retention and collectors warnings the kind of operational detail platform teams should bake into observability and DORA-aligned metrics dashboards. If you treat your IDP like a product, these are the incremental features that buy better telemetry and safer golden paths. If you dont, you'll end up with fragmented release signals and finger-pointing during incidents. See why treating platforms as products matters in practice in Google Cloud's platform engineering research on DORA and IDPs.
Opinion: This is the right call and overdue. Backstage is maturing from an opinionated convenience to a composable platform: fewer hidden globals, clearer upgrade contracts, and tooling to help teams standardize. That discipline will hurt in the short term (search-and-fix migrations are boring, risky work), but it prevents the far worse long-term problem of global style regressions and brittle UI drift across dozens of micro-frontends.
If you run a Backstage IDP, do not treat this as a cosmetic upgrade. Audit entrypoints for the CSS import, adopt Themer if you want consistent component behavior, and schedule a Postgres compatibility checkpoint. The next Backstage upgrade will be easier if you stop letting the framework carry hidden assumptions for you.
Final thought: Backstage's small API nudges are now where platform engineering trade-offs live convenience versus explicit contracts. v1.44.0 chose explicitness, and the teams that treat their IDP as a product will win on stability and predictability. The ones that dont will be surprised by a week of broken UIs.
Sources
- Backstage v1.44.0 drops, and many plugins have new features added (Roadie Backstage Weekly #101)
- Releases · backstage/backstage (GitHub)
- Release & Versioning Policy | Backstage Software Catalog and Developer Platform
- v1.21.0 | Backstage Software Catalog and Developer Platform
- Spotify Plugins for Backstage Release Notes
- Using the Release Plugin in Backstage - Digital.ai Release
- Upgrade Backstage applications (Upgrade Helper)