Why Backstage upgrades and support need a planned owner
Picture a Backstage portal that is running well in production. The team that built it has moved on to other work, and the app now sits several versions behind the current release line. Nobody was assigned to the upgrades, so the portal keeps working until a plugin needs a newer version, a security advisory lands, or a Node.js change breaks the build. Upgrades and support are recurring work, and most teams can do that work in-house if they staff it on purpose. A partner usually fills the gap in three places: spare capacity, security response outside business hours, or a fixed-scope upgrade that clears a backlog in one agreed block of work.
Backstage is licensed under the Apache License 2.0 (SPDX: Apache-2.0), according to its GitHub repository. The project itself offers no paid edition, so there is no vendor contract that automatically delivers upgrades or patches to your app. Every fix you receive reaches you because someone on your side or a contracted team pulls it in. The project's versioning policy describes a main release line shipped monthly, on the Tuesday before the third Wednesday of each month, and a next release line shipped weekly on Tuesdays. Your team has to decide which line to follow and how often to take changes from it. Confirm that choice with your engineering leads before you agree on any upgrade cadence.
The work does not end once the app is current, because the release cadence never pauses. Each monthly main release can move the @backstage packages, the plugin APIs and the template files your app was generated from. The Upgrade Helper shows which template changes apply between two versions, and the versions:bump command moves all @backstage packages together. Plan for a standing slot in your calendar, not a single project. Ask any proposed partner to show how they would run that slot each month, who reviews the diff, and how a failed bump is rolled back without taking the portal offline.
What an upgrade and support engagement includes
Backstage upgrades touch the same few places every cycle: the @backstage package set, the template changes the Upgrade Helper lists, the Node.js runtime, the plugins you depend on and the core features your developers use daily. The cards below separate that work into parts you can scope, price and check, and the written scope fixes the exact deliverables for each.
Upgrade assessment
Before any version changes, we inventory your current Backstage release, your installed @backstage packages, your custom and community plugins, and your Node.js version. The output is an assessment note that lists the gap to the target release, the risky areas and the items that need your decision. Ask for this note to name each plugin and its owner, so nothing is left unclear when the upgrade branch is opened.
Moving @backstage packages together
Backstage expects all @backstage packages to move to matching versions in one pass, and we use yarn backstage-cli versions:bump for that step rather than hand-editing package.json files. The deliverable is a branch where the package set is aligned and the lockfile is regenerated, with a short note on any package that could not be bumped and why. Confirm with us how dependency pins outside the @backstage scope are handled.
Resolving Upgrade Helper template changes
The Backstage Upgrade Helper shows the template and configuration changes between two versions, and each listed change affects app code, configuration or both. We work through every change in the helper output for your app and record what was applied, what was skipped and why. Codemod use depends on the versions involved, so we confirm per project which codemods apply before anyone runs them.
Node.js runtime alignment
Backstage supports exactly two adjacent even-numbered Node.js releases at any time, so the runtime must sit inside the supported pair for the target version. We check your base images, CI runners and local development guidance against that pair and update them together. The deliverable is a runtime matrix that shows the Node.js version used in each environment, plus a note on any build step that fails under the new runtime.
Plugin compatibility review
Each community and internal plugin has its own release line, and some lag behind the core framework. We check every plugin against the target @backstage packages, record which versions are compatible, and flag any plugin that needs a patch, a replacement or removal. Ask for a compatibility table with one row per plugin, the owner for each row and a decision for every flagged item.
Regression testing of core features
After the upgrade branch builds, we test the features your teams rely on most: the Software Catalog, Software Templates, TechDocs and sign-in through your configured authentication provider. Each area gets a scripted check list, run against an environment that mirrors production configuration. The deliverable is a test report with pass and fail results, plus a tested upgrade branch ready for your change process.
Support agreement for security fixes
Backstage backports high and critical severity vulnerabilities to releases from the last six months where feasible, but your team still has to apply them. A support agreement covers advice on which fixes apply to your version, help applying them, and a runbook for the next upgrade cycle. Confirm response expectations, coverage hours and what is excluded in the written scope before you sign.
What makes a Backstage upgrade larger or smaller
This table lists the factors that most change how much work a Backstage version upgrade takes and what you can do about each one. Read each row as a lever: the first column names the factor, the second explains the mechanism, and the third gives the practical step that keeps the effort contained. The main takeaway is that plugin count, customization depth and how far behind the app has fallen matter more than the upgrade command itself.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of custom and third-party plugins | Each plugin pins its own @backstage package versions and may depend on APIs that changed between releases, so every plugin needs review and testing after a bump. | Inventory every plugin with its owner and source, retire unused ones, and prefer plugins that track the main release line. |
| Degree of customization in the app shell and backend wiring | Heavy edits to the app shell, backend index file or core extensions turn template diffs from the Upgrade Helper into manual merges. | Keep wiring thin, move logic into separate plugins, and record every deliberate deviation from the default template. |
| Legacy or new backend and frontend systems | Apps on the legacy wiring need a separate migration path, so an upgrade can combine a version change with a structural rewrite. | Decide on the migration as its own project before the version bump, or confirm the timing with your platform team. |
| Number of environments and release gates | Each environment needs its own build, test run and sign-off, so effort grows with every stage a change must pass through. | Automate the build and smoke tests per environment and agree on a fixed set of gate criteria before the upgrade starts. |
| Distance behind the current version | Skipping several monthly main releases stacks template changes, breaking changes and deprecations into one large diff. | Upgrade on a regular cadence against the monthly main line so each change set stays small and reviewable. |
| Node.js version alignment | Backstage supports only two adjacent even-numbered Node.js releases, so an app on an unsupported runtime must change its runtime and its packages together. | Check the supported Node.js pair for your target version in the versioning policy and align CI images and hosting runtimes early. |
| Authentication and sign-in resolver setup | Each sign-in provider and resolver must still map every identity to the same user, and resolver changes can break login for all users at once. | Test each provider in a staging environment after every upgrade and confirm guest access is still disabled in production. |
| Compliance evidence required for each upgrade | Assessors may ask for change records, test results and approvals per release, which adds documentation work beyond the technical change. | Ask your compliance lead which evidence is required, then generate change logs, test output and approvals as part of the upgrade pipeline. |
How an upgrade moves from assessment to handover
The sequence turns an aging Backstage app into a tested, documented upgrade that the client's team can repeat on later releases. Each phase closes with a written output the client can review before the next phase begins.
Assess the current state of the app
The team inventories the installed @backstage package versions, the plugin list including community and custom plugins, the Node.js version in use, the database and cache configuration, and any custom code that extends core packages. The output is a written current-state report that lists each item, its version, and its upgrade risk. The step is done when the client confirms the inventory matches the running environment.
Select the target version and Node.js version
The team compares the current release with the main and next release lines and checks the Backstage versioning policy for the Node.js releases currently supported. The target is chosen so the Node.js version sits inside the supported window and the release is recent enough to receive security backports. The output is a short decision record naming the target Backstage version, the Node.js version, and the reason for each choice.
Create the upgrade branch with version changes
The team creates a dedicated upgrade branch and runs yarn backstage-cli versions:bump so all @backstage packages move to the same target. It then reviews the template changes shown by the Backstage Upgrade Helper for each intermediate version and applies the ones that affect this app, including config and codemod updates. The output is a branch that installs cleanly and builds, with a change log that maps each edit to its source.
Fix plugin compatibility issues
Each community and custom plugin is checked against the target version, and any breaking API change is fixed or the plugin is replaced or pinned. Custom plugins and catalog processors are tested against the new core packages, and the team records which plugins needed code changes and which were left alone. The output is a plugin compatibility matrix with the status and owner of every plugin. The step is done when the app starts and every plugin loads without errors.
Validate in test and staging
The upgraded build runs in a non-production environment with production-like configuration, including the same authentication providers, database engine, and cache. The team exercises the catalog, scaffolder templates, TechDocs builds, and integrations, and checks logs and database migrations. The output is a validation report listing each test, its result, and any open defects with their agreed resolution. The client signs off before cutover is scheduled.
Cut over to production with a rollback plan
The team deploys the validated build to production in a window the client agrees, after a database backup has been taken and verified. A rollback plan states the exact steps to return to the previous image and schema state, who decides to roll back, and how long the team will monitor before closing the change. The output is a completed change record with the deployed version, smoke test results, and monitoring confirmation.
Hand over the runbook and support cadence
The team delivers a repeatable upgrade runbook that the client's engineers can follow for the next release, covering the version selection rules, the versions:bump steps, the compatibility checklist, and the rollback procedure. A recurring support cadence is agreed in writing, stating how often releases are reviewed and who receives security advisories. The output is the runbook, the cadence document, and a walkthrough recorded in the handover notes. Ask each partner for the phase timeline and the handover deliverables in the written scope.
Which upgrade tasks teams keep in-house and which they outsource
This table compares each recurring Backstage upgrade and support task by who usually keeps it, who usually takes it on from a partner, and the skills it needs. Read it as a starting split to adjust against your own team's TypeScript, React and CI experience. The main takeaway is that product ownership usually stays in-house, while repeatable upgrade work and security response are the parts most often bought as capacity.
| Task | Usually kept in-house | Usually outsourced | Skills required |
|---|---|---|---|
| Owning app business logic and plugin choices | Catalog model, which plugins to adopt, and decisions about what the portal must do for developers | Advisory input on plugin options and trade-offs during planning reviews | Product ownership, developer workflow knowledge, enough Backstage familiarity to judge options |
| Routine dependency bumps | Approving changes that touch product behavior and reviewing test results | Running versions:bump on a schedule and opening the resulting pull requests | TypeScript, yarn workspaces, familiarity with the @backstage packages |
| Reviewing Upgrade Helper diffs | Deciding which template changes apply to custom code and sign-off | Producing the diff review and drafting the change list against the local app | React and TypeScript for frontend changes, Node.js for backend changes |
| Node.js runtime changes | Confirming the runtime in use is inside the supported window and approving the switch | Migrating the runtime and fixing breakages in build tooling and native dependencies | Node.js operations, package manager tooling, container image updates |
| Security advisory triage and backport response | Deciding risk acceptance and coordinating with the security team | Assessing advisories against your configuration, applying backports and testing the patched release | Vulnerability analysis, dependency auditing, release engineering |
| Plugin compatibility testing | Confirming that business-critical plugins still work for your users | Testing third-party and custom plugins against new releases and reporting incompatibilities | TypeScript, React testing, familiarity with each plugin's API and configuration |
| CI and deployment pipeline changes | Owning deployment targets, approvals and environment access | Updating build and test workflows for new Node.js versions and changed package layout | CI system administration, container builds, infrastructure access patterns |
| On-call for the portal | Incident ownership, service-level expectations and escalation to owning teams | Out-of-hours monitoring or response under a support agreement, if contracted | Site reliability practice, PostgreSQL and cache awareness, incident response runbooks |
What goes wrong when Backstage upgrades slip
Most Backstage upgrade problems build up slowly. A team skips a monthly release, a Node.js version drifts outside the supported pair, or one person holds the knowledge needed to move the app forward. Each card names a failure mode and the step that prevents it.
Falling behind the release line
Backstage ships a main release line monthly and a next line weekly. A team that upgrades once a year faces a multi-version jump with many template changes to review at once. The versioning policy also says high and critical vulnerabilities will be backported to releases from the last 6 months if feasible, while other security fixes may be backported. A deployment that stays on an older release can fall outside that window. Prevention: schedule a recurring upgrade window, bump on a short cadence, and confirm in writing how your support provider handles fixes for older releases.
Node.js drift
Backstage supports exactly two adjacent even-numbered Node.js releases. As of Backstage 1.46.0, those are Node.js 22 and 24, according to the versioning policy. When the host image, CI runner or developer machines run a version outside that pair, builds and runtime behavior can fail in ways that look like application bugs. Prevention: pin the Node.js version in the repository and container images, check the policy for the current pair before each upgrade, and make CI use the same version.
Custom plugins breaking on template changes
Custom plugins, scaffolder actions and catalog processors depend on Backstage interfaces that change between releases. The Upgrade Helper shows changes to the app template, so your own plugin code still needs its own review. A plugin written against an older release can fail to compile or start after a version bump. Prevention: keep custom code in separate packages, run a test suite on every bump, and review each plugin against the template diff before merging.
Auth resolver regressions
Sign-in resolvers map each provider identity to a catalog user. An upgrade or a provider configuration change can alter which claim is read or how users are matched, so some users cannot sign in or are matched to the wrong identity. The authentication documentation advises that every provider resolves to the same identity and that guest access is not offered in production. Prevention: keep a test set of sample users for each provider, run it after every bump, and confirm guest access is disabled in the production configuration.
One engineer owning every upgrade
When one engineer knows the current versions, the pinned runtime and the custom plugins, upgrades stop whenever that person is unavailable. Changes accumulate and the next jump becomes harder to review. Prevention: write the upgrade runbook in the repository, assign the upgrade task to at least two named engineers, and record each bump in a changelog. Ask any partner which people will carry the work and how handover is handled.
Untested production cutover
Staging and production drift apart when upgrades go straight to production. A cutover without a rehearsal leaves the team unsure which catalog ingestion, database migration or plugin change will fail. Production runs on PostgreSQL, so rehearsals should use that engine and a recent restored backup rather than an in-memory or SQLite setup. Prevention: rehearse each bump in staging, define a rollback path before cutover, and record the results of each rehearsal.
What recurs after go-live and what is one-time
The Apache-2.0 license means Backstage carries no license fee, so every recurring cost of running it is a cost of people and infrastructure. The project itself offers no paid support tier, which means the upgrade work, security response and plugin upkeep fall to whoever operates the portal, either your own platform team or a partner you pay under a support agreement. When you compare options, separate the cost of the framework (zero) from the cost of keeping it current, because the second is where budgets usually drift. The largest recurring line is upgrade effort. Backstage ships a main release line monthly, on the Tuesday before the third Wednesday of each month, and a next release line weekly on Tuesdays. You do not have to adopt every release, but you do need to move within a window that keeps you on supported code. Upgrades move all @backstage packages together with yarn backstage-cli versions:bump, and the Upgrade Helper shows the template changes between versions. Ask a partner how many upgrade cycles per year the quote assumes, how codemods and config changes are handled, and who tests the result against your authentication and catalog setup. Several other recurring costs sit beside upgrades. Plugin upkeep covers every community or custom plugin that must be checked against each new release, and it grows with the number of plugins you run. Security response time matters because the versioning policy says high and critical vulnerabilities will always be backported to releases from the last 6 months where feasible, so you need a named owner to apply those fixes quickly. Node.js support is limited to two adjacent even-numbered releases, so runtime moves also recur. Confirm which Node.js versions your current Backstage release supports before you set a schedule. Hosting and database maintenance also recur. Backstage uses PostgreSQL in production with a separate logical database per backend plugin, and any caching layer you add, such as Redis, adds its own patching and monitoring. CI runners for build and test pipelines, the people who hold platform engineering skills, and the time spent on onboarding new engineers to the portal all continue after launch. Ask the partner which of these the quote includes and which you must provide. One-time costs are different in kind. The first assessment of your app against current templates, remediation of technical debt left by early customizations, and creation of runbooks for upgrades, incident response and recovery are typically paid once, although they can reappear when you change major architecture. A quote should split one-time fees from recurring fees and state in writing what the support agreement covers and excludes, such as plugin fixes, security patches, out-of-hours response and hosting. For the multi-year model that combines these lines, see the cost-of-ownership topic.
How upgrade work changes by starting point
An app several major-line releases behind has the widest gap between its current packages and the latest release. The plan starts with choosing a target release and reading the Upgrade Helper output for every version in between, because template and configuration changes accumulate across releases. Work is usually staged in short hops so that each hop can be built and tested on its own.
- Inventory the gap: record the current Backstage release, the Node.js version in use, and every @backstage package version before choosing a target.
- Plan hops: agree the sequence of intermediate releases with your team and test each hop on a separate branch.
- Apply versions:bump per hop: move all @backstage packages together, then resolve the template differences the Upgrade Helper lists for that hop.
- Check Node.js alignment: confirm which Node.js releases the target release supports under the versioning policy before changing the runtime.
- Account for the backport window: the policy says high and critical vulnerabilities are backported to releases from the last 6 months where feasible, so a version older than that window may need a longer path.
Check: confirm the current release and the supported Node.js pair in the versioning policy before you fix the target.
An app that still uses the legacy backend and frontend wiring has two changes to plan: the version upgrade and the move to the new systems. Doing both in one pass makes it hard to tell which change caused a failure. Most teams split the work so the version upgrade lands first on the legacy wiring, then the wiring changes move to a separate, reviewed phase.
- Separate the two changes: keep the version upgrade and the wiring migration in different branches and release windows.
- Map custom wiring: list every place where the app registers backend modules, frontend extensions, or plugin routes by hand, since these need manual changes.
- Confirm feature parity: check which legacy features your portal relies on and verify each one in the new systems before cutover.
- Keep a rollback path: define how to return to the last working release if the wiring change fails in staging.
- Test the catalog and auth paths first: these are used by every user, so failures there affect the whole portal.
Check: confirm with your team which legacy features are in use, because that list drives most of the effort in this tab.
An app with many custom plugins and forked upstream packages has a second upgrade path to manage alongside the Backstage core. Each custom plugin depends on Backstage APIs that can change between releases, and each fork drifts further from upstream the longer it stays unmerged. The plan therefore starts with an inventory of plugins and forks, with an owner and a test plan for each.
- Classify each plugin: mark which plugins use only public APIs, which import internal modules, and which are forks of upstream packages.
- Shrink fork deltas: where a fork can be replaced by a configuration option or an upstream plugin, plan that change before the upgrade.
- Assign an owner per plugin: the owner reviews the upgrade diff for that plugin and signs off on its tests.
- Test plugins at each hop: run each plugin's test suite and a smoke test in the portal for every intermediate release.
- Record fork base versions: note the upstream version each fork was taken from so the merge is traceable.
Check: confirm that every plugin has a named owner and a test suite, because plugins without either usually block the upgrade.
An app running on Kubernetes with CI/CD gates has upgrade steps that depend on the pipeline. Each change to the app moves through build, test, and deployment stages, and the upgrade must pass the same gates as any other change. The plan therefore adds staging rehearsals and defines what each gate checks before the change reaches production.
- Rehearse in staging: deploy each hop to a staging environment that matches production configuration, including the database and cache.
- Define gate criteria: agree which tests, scans, and health checks must pass at each stage before promotion.
- Plan database changes: each backend plugin uses its own logical database, so review schema changes for each plugin before rollout.
- Choose a rollout method: decide whether the upgrade rolls out with a standard rolling update or a more gradual method, and confirm the cluster supports it.
- Keep the rollback artifact: retain the previous image and configuration so the pipeline can redeploy it quickly.
Check: ask your platform team which gates apply to the Backstage pipeline and who can approve a promotion to production.
An air-gapped or restricted network cannot reach public package registries, container registries, or the Backstage GitHub releases page directly. The upgrade therefore depends on mirroring every artifact the build needs, plus the release notes and template guidance the team reads during planning. The mirroring work often takes longer than the code changes, so it should be scoped first.
- Mirror the dependency tree: copy the npm packages, container base images, and Node.js runtime for each target release into the internal repositories.
- Bring in release notes and guidance: copy the release notes and upgrade guidance into the internal documentation space so reviewers can read them offline.
- Precompute the upgrade diffs: because the Upgrade Helper runs online, generate the template differences on a connected machine and transfer them with the mirrored artifacts.
- Scan mirrored artifacts: run your own vulnerability scans on the mirrored packages and images before the build uses them.
- Record each transfer: keep a log of what was imported, when, and who approved it, since transfer approvals are often required in these networks.
Check: confirm with your security team which transfer process applies and whether a mirror already exists for the Node.js and npm sources you need.
What your team needs to provide before an upgrade starts
Most delays and re-scoped work on a Backstage upgrade trace back to a short list of inputs that the client has not yet put in place. Before a fixed-scope agreement is signed, confirm that each item below exists, that the right people can reach it, and that someone with authority has agreed to own it. The upgrade itself is usually mechanical compared with the time spent waiting for access, data or decisions.
Start with access. The upgrade team needs read and write access to the Backstage application repository, including any forks, and to the CI system that builds, tests and deploys it. Confirm who can approve merges to the main branch and who holds the credentials that deploy to each environment. If the app lives in several repositories, such as a separate plugins repo or a monorepo with private packages, list all of them. A missing repository discovered in week two is the most common reason for a re-scope.
Next, confirm a staging environment that mirrors production in the parts that matter for upgrades: the same Node.js runtime, the same PostgreSQL major version and configuration, the same authentication provider, and the same catalog ingestion sources. Staging should also hold a recent copy of the PostgreSQL databases, one logical database per backend plugin, and you should have a tested backup and restore path for them. Ask the operations owner to demonstrate a restore to a scratch instance before the upgrade begins, and record how long it took. Upgrades that touch database schemas cannot be rolled back safely without this.
Then produce two inventories. The first is every plugin and fork in use, with the Backstage package name, the version pinned, whether it is maintained upstream, and whether your team has modified its source. The second is every integration the portal depends on, such as the source control provider, the identity provider, Kubernetes clusters, the search index and any ticketing or cloud APIs. Name a human owner for each integration and for the catalog data each team relies on. Owners who can answer questions about an integration's credentials and expected behavior shorten the investigation time when a plugin breaks after a version bump.
Finally, make three decisions and assign sign-offs. Decide which release line you will target: the main line ships monthly, while the next line ships weekly and is intended for earlier testing, so the choice affects how much churn you accept. Set a maintenance window policy that states when staging and production can be changed and who can approve an emergency change. Name a sign-off owner for each environment who can accept the upgrade as complete. Put these decisions in writing before the statement of work is finalized, because each one changes the test effort and schedule in the quote.
Questions buyers ask about Backstage upgrades and support
Can our own team upgrade Backstage without an outside partner?
Yes. Backstage is Apache-2.0 software, so your team can run upgrades itself if it has the time and skills. The standard path is to move all @backstage packages together with yarn backstage-cli versions:bump, then work through the template changes shown in the Backstage Upgrade Helper and apply any codemods the release calls for. The work is largely review and testing. It needs a named owner, a staging environment that mirrors production, and engineers who know your custom plugins. Teams that have fallen several releases behind usually find the size of the gap, more than the mechanics, is what consumes time.
What does a Backstage upgrade cost and what drives the price?
The cost is the people time required to move your app to a newer release, plus any outside effort you buy. If your team does the work, the cost is internal engineering hours and the delay to planned features. If you hire a partner, DeployOpen works from a written scope and quotes a fixed scope, so you pay for agreed deliverables. The main drivers are the number of releases you cross, how many third-party and custom plugins you run, how much of your code depends on changed APIs, how thorough your automated tests are, and how many environments must be verified. Ask any provider to split the quote into planning, upgrade, testing and handover so you can see what each part covers.
How long does a Backstage upgrade take in practice?
Duration depends mainly on how far the app sits behind the current release and how many plugins it uses. A small app a few releases behind, with few plugins, is a very different job from a large app that skipped a year of main releases and runs many custom plugins. Your change approval process, test coverage and the speed of plugin owners' reviews also matter. No general timeline fits every app. Ask for the duration in the written scope and check the assumptions behind it, such as the plugins in scope, the environments to be tested and the production cutover window. Any figure given before someone has reviewed your repository is an estimate, not a commitment.
What does a Backstage upgrade need from our team?
An upgrade needs decisions and access more than unusual skills. Expect to provide repository access, a staging environment that matches production, a backup plan for the PostgreSQL databases and CI pipelines that run the full test suite. You also need a product or platform owner who approves behavior changes, plugin owners who can confirm their plugins work on the new version, and a change window for production cutover. Someone with authority should own the decision to ship. If sign-in is connected to your identity provider, include identity administrators in testing, because sign-in resolver behavior is easy to break and hard to spot in a quick smoke test.
Can we keep up with the monthly Backstage release cadence?
Yes, if you treat the cadence as a standing staffing commitment. The Backstage versioning policy ships a main release line monthly, on the Tuesday before the third Wednesday of each month, and a next release line weekly on Tuesdays. Many teams do not apply every release. They choose a rhythm, such as tracking the main line monthly and batching changes, and they keep the gap small enough that each upgrade stays manageable. The policy says high and critical vulnerabilities will be backported to releases from the last six months where feasible, so falling behind that window removes a protection you would otherwise have. Decide the cadence before you build the portal, and staff it accordingly.
What does a Backstage support agreement cover and exclude?
A support agreement covers the work written into it, and nothing beyond that. DeployOpen offers ongoing support, upgrades and continuous testing as retainers. A typical scope includes tracking release notes, applying version bumps, fixing breakage in named plugins, responding through agreed channels and documenting changes. Typical exclusions include new feature development, plugins not named in the scope, changes to your hosting platform or identity provider, and custom code outside the agreed list. Response times, availability terms and how security backports are handled belong in the written agreement, so ask for each one explicitly rather than assuming a default.
How do Node.js changes affect a Backstage upgrade plan?
Node.js changes can force a runtime move alongside a Backstage version bump, so they belong in the same plan. Backstage supports exactly two adjacent even-numbered Node.js releases. As of Backstage 1.46.0, those are Node.js 22 and 24, according to the versioning policy. When the supported pair moves, your CI runners, container base images and developer machines need matching Node versions. Native modules and some third-party plugins may need rebuilding or updates for a new runtime. Check the Node.js requirements in each release's notes before scheduling, and test the build and full test suite on the target version before production.
Does the Backstage project offer a paid edition?
No. Backstage is open source under the Apache License 2.0, and the project does not sell a paid edition of its own. You can run it without a license fee, but you then carry the platform team, hosting, upgrades and plugin upkeep. Some other vendors sell hosted or supported Backstage products. Those are separate offerings with their own terms, so review them directly. DeployOpen is not a reseller or certified provider of Backstage. It plans, implements, customizes, hardens and supports self-hosted Backstage inside your own infrastructure, and it quotes support from a written scope.
How DeployOpen scopes, delivers and supports Backstage upgrades
DeployOpen plans, implements, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and Backstage upgrades follow the same written-scope method. Engagements are fixed-scope, with ongoing support available as a retainer once the upgrade work is complete.
How we scope
- We review your current Backstage version, plugin list and custom code before agreeing any upgrade work in writing.
- The written scope names the target release line, the plugins in and out of scope, and the environments that will be upgraded.
- We confirm your Node.js runtime and database versions against the Backstage versioning policy during scoping, not after the first failed build.
How we build
- We move all @backstage packages together with versions:bump, then work through template changes shown by the Upgrade Helper.
- We apply codemods where they fit and review each generated change in version control instead of accepting bulk edits unread.
- We test plugin compatibility one by one, including custom plugins, catalog processors and scaffolder actions your teams maintain.
How we hand over
- You receive an upgrade record listing each version step, the changed files, the plugins touched and the checks performed.
- We document the commands, the upgrade order and the known breaking points so your platform team can repeat the process.
- Handover includes a walkthrough of the monthly main release cadence and the weekly next line, so your team plans its own upgrades.
How we support
- Support covers scheduled upgrades, security fixes and plugin compatibility checks, as set out in the retainer scope you agree.
- We track the Node.js support window and flag when your running version falls outside the supported releases.
- Ask in your quote which security patch turnaround, test environments and response channels the retainer includes.
