Why patching Backstage depends on the six-month backport window
Your self-hosted Backstage portal is only as safe as the release line it runs on, and the project's versioning policy decides which fixes you can receive without a larger upgrade. Backstage ships a main release line once a month on the Tuesday before the third Wednesday, and a next release line every week on Tuesdays. Fixes land on the main line and are then carried into older releases. The policy commits to backporting high and critical severity vulnerabilities to releases from the last six months where that is feasible, and says other security fixes may be backported. Lower severity fixes are therefore not guaranteed a path back to older versions.
The practical consequence is that the six-month window is a clock you must watch. An installation that has fallen behind, for example one still on a release that has aged out of the window, may find that the fix it needs exists only on a newer line. In that case the patch is not a dependency bump; it is an upgrade, and it can carry template changes, Node.js changes and plugin compatibility work with it. Confirm the current window and the release you run against the Backstage release and versioning policy before you schedule a maintenance window, and record the date your release line will age out.
Plan your cadence around that clock rather than around ad hoc alerts. Decide how far behind the latest monthly release you will allow the portal to run, and who approves an out-of-cycle upgrade when an advisory lands on a release near the edge of the window. Ask any partner or internal team to show how they track both the monthly and weekly lines, and how they will test a jump across several monthly releases in a staging copy of your catalog and plugins before production.
Which tools and sources to watch for Backstage patches
Backstage patches reach you through several channels, and none of them covers everything. Automated dependency tools watch your lockfile, the Backstage releases and versioning policy tell you what the project will fix and when, and plugin repositories carry the fixes you depend on but do not control. Use them together and confirm what each one sees in your own repository.
Dependabot on the app repository
Dependabot opens pull requests when a package in your lockfile has a newer version or a published advisory. It usually reads the @backstage packages in package.json and the resolved tree in yarn.lock, so it can flag a vulnerable transitive Node.js dependency. Confirm that it is enabled for the repository, that it scans the lockfile, and whether it groups @backstage bumps into one pull request. Check whether it reads plugin packages from private registries at all.
Renovate on the app repository
Renovate can update the same packages as Dependabot and offers more control over grouping, schedules and automerge rules. Its coverage of the Node.js runtime and container base images depends on the managers you enable, so confirm those separately. Set a rule that keeps all @backstage packages moving together, since a partial bump can break the build. Confirm that private plugin packages are included in the scan.
Snyk on dependencies and images
Snyk reports known vulnerabilities in your dependency tree and, depending on your plan and setup, in container images and infrastructure definitions. It may report a transitive issue that a version bump of @backstage/core-app-api does not resolve, so check whether a fix exists before you upgrade. Confirm which manifests Snyk scans, whether it reads the lockfile, and how it handles packages it cannot identify, such as those from internal registries.
Backstage releases and versioning policy
The GitHub releases page lists each published version, and the versioning policy states that high and critical vulnerabilities are backported to releases from the last six months where feasible. Read the policy to learn which line you are on and when your current version falls outside the backport window. Other security fixes may be backported, so do not assume a lower severity fix will reach your line. Watch the release notes for the upgrade steps that accompany security fixes.
Plugin repositories and their releases
Third-party and community plugins publish their own advisories, releases and changelogs, and the Backstage project does not backport fixes for them. Subscribe to the release feed or watch each plugin repository for every plugin in your packages/ directory and in your plugin list. Note that a plugin can pin an older @backstage version, which keeps you from taking a core fix until the plugin catches up. Record each plugin's owner and maintenance status in your inventory.
Your own advisory triage log
No single feed tells you that your deployment is exposed, so keep a record of each advisory you received, the affected package and version, whether your instance uses the affected code path, and the date you patched or accepted the risk. This log is the evidence auditors and security teams ask for during change management reviews. Assign an owner for triage each week, and confirm that your alerts reach a shared channel rather than one person's inbox.
How a Backstage security fix reaches your installation
A security fix reaches your installation only after it passes through four steps: a commit to the backstage/backstage repository, a published release on the GitHub releases page, a dependency bump in your own app repository, and a rebuilt container image that your platform deploys. Each step can be delayed, so your patch timing depends on the slowest one. The latest release listed on the Backstage releases page at the time of writing was v1.55.3, published September 29, 2026, with 1.56.0 in the next release line. Check that page for the current release before you plan, because the number will have moved.
Your app is not a single package. Every @backstage package in your repository must move to the same release, and you do that with yarn backstage-cli versions:bump, which updates them together. Mixing versions, for example bumping only the backend while the frontend stays behind, is a common cause of broken builds and is how teams end up delaying a security fix. Before you bump, open the Backstage Upgrade Helper to see which template files changed between your current version and the target, since configuration and code edits often come along with the security fix. Plan those edits as part of the same change.
The versioning policy backports high and critical vulnerabilities to releases from the last six months where feasible, and other security fixes only sometimes. If your installation is on a release older than that window, a fix may exist only on a newer line, which forces a minor version upgrade rather than a patch. Confirm with the policy which release lines are currently covered and measure how far behind your installation sits, because the gap determines whether a fix is a small bump or a planned upgrade. Also confirm your Node.js version against the supported pair in the same policy, since a platform change can block a bump that otherwise looks routine.
Which patching cadence fits which operating model
This table compares three ways to take Backstage releases and security fixes, measured against risk exposure, test effort and the six-month backport window. Read each row as a trade-off: faster cadences shrink exposure but increase the number of upgrades your team must test. The main takeaway is that the monthly main line is the usual baseline, and the weekly next line suits teams that accept more frequent change.
| Operating model | Risk and exposure | Test effort and staying inside the window |
|---|---|---|
| Monthly main line | Moves with the main release line shipped monthly, so fixes arrive on a predictable schedule and most teams stay on supported code. | One scheduled test cycle per month. Staying inside the six-month backport window is straightforward if the team upgrades at least that often. |
| Weekly next line | Gets fixes and features earliest, which suits teams that want early exposure to changes, but new code has had less time in production. | Weekly test cycles and frequent plugin compatibility checks. Requires a staffed owner who can triage breaking changes every week. |
| Quarterly with emergency patches | Routine upgrades wait for the quarter, so the gap to the latest release grows. High and critical fixes still need an out-of-cycle upgrade path. | Fewer routine tests, but each emergency patch needs a fast, practiced process. Confirm the release you run stays inside the six-month window. |
| Pinned to a single release line with no schedule | Highest risk. Fixes may be backported only if feasible, and lagging plugins make the gap harder to close. | Low routine effort until a backport is needed. Confirm with the project which of your versions still receive high and critical backports. |
| Monthly main line with a weekly advisory watch | Keeps the routine cadence while reacting quickly to published advisories between releases. | Adds a short weekly review of advisories and dependency alerts. Upgrades still follow the monthly test cycle unless a severe fix requires faster action. |
| Dependency bot pull requests reviewed as they arrive | Keeps dependency gaps small, but changes can land without a planned release window. | Continuous small reviews. Works best when automated tests cover the catalog, scaffolder and sign-in paths. |
Setting up dependency bots and advisory monitoring
This sequence puts an automated dependency bot, a pinned Node.js runtime and a named review owner in front of every Backstage update, so security fixes reach your app inside the project's backport window. The output is a repository that proposes upgrades on a schedule, a release feed you actually read, and a written patch calendar.
Choose and enable the dependency bot
The platform or security engineer who owns the Backstage app repository selects one of the supported tools (Dependabot, Renovate or Snyk) and enables it on that repository only. Confirm the bot can read the lockfile, open pull requests and run your CI workflows, and check that it is scanning the workspace root, not just a subfolder. The step is done when the bot opens its first dependency pull request or reports a clean scan of the lockfile.
Group Backstage packages into one pull request
Configure the bot to batch every @backstage scoped package into a single pull request, because Backstage expects its packages to move together. The upgrade path in the project's keeping-updated guide uses yarn backstage-cli versions:bump for this purpose, so a grouped update should match that tooling rather than bumping packages one at a time. Check that the grouped pull request changes all @backstage entries to matching versions and that the lockfile resolves without duplicate Backstage versions.
Pin Node.js to a supported even-numbered release
The platform owner sets the Node.js version in the repository and in the container build to one of the two adjacent even-numbered releases that the versioning policy supports. As of Backstage 1.46.0 those are Node.js 22 and 24, but confirm the current list against the policy before you pin, because the supported set changes with Backstage releases. Verify by running the build and tests on the pinned version and confirming the runtime version in your CI logs and deployed image.
Subscribe to the Backstage releases feed
The security owner watches the Backstage releases page on GitHub, using the repository's watch settings for releases, and routes notifications to a shared channel that the review rota reads. Pair this with the versioning policy so the team knows that high and critical fixes are backported to recent release lines when feasible, while other security fixes may or may not be. The step is complete when a test release notification reaches the channel and the team lead confirms who receives it.
Assign a review owner and test gate
Name one engineer as the review owner for dependency pull requests and one as backup, and write down which CI jobs must pass before merge, including the app build, unit tests and a smoke test of sign-in and the catalog. Require the owner to read the upstream release notes and the Upgrade Helper changes for each grouped update. The step produces a short written rule in the repository's contributing notes, and you can confirm it works by checking that a branch protection rule blocks merging without the named approval.
Track third-party plugins separately
The owner of each installed community or custom plugin lists those packages in a separate tracking file with their source repository, current version and maintainer status. Many plugins are not on the core release line, so their updates may lag behind Backstage. Enable the bot for those packages too, but review them as their own items. The step is done when every installed plugin has a row in the file, and you have checked each source repository for recent activity and open security issues.
Record the patch calendar
The engineering manager writes a patch calendar that names who reviews dependency pull requests, when the team checks the releases feed, and how urgent advisories are escalated to an out-of-cycle update. Base the cadence on the monthly main release and the weekly next release lines described in the versioning policy, and state how far behind the team will allow the app to run before it is treated as an incident. The calendar is finished when it is stored with the runbook and a reviewer can point to the next scheduled review date.
Patching third-party plugins that lag behind core
Core Backstage patches do not reach your community and custom plugins, so each plugin you run is a separate patching decision. Start by inventorying every plugin in the app repository, including the @backstage/plugin-* packages you did not write, the community packages from other authors, and any internal plugins. For each one, record the installed version, the @backstage peer and dependency versions it pins, the upstream repository, and the date of its last release. A plugin that pins an older @backstage line is the most common reason a core bump stalls, because the bump cannot move every package together. Confirm this in your lockfile before you plan the upgrade window.
For each plugin, check three things against your target release: whether the maintainer still publishes releases, whether a version exists that supports the target @backstage line, and whether open security issues are fixed on the default branch. Read the plugin's changelog and issue tracker rather than relying on its download count. If no compatible version exists, you have three options: fork the plugin and carry the compatibility change yourself, replace it with another plugin or a small in-house plugin, or remove it. Forking adds recurring work for your team every time core moves, so ask who will own that code before choosing it. Removal is often the correct answer for a plugin that is unmaintained, unpatched and not tied to a business process. Keeping such a plugin on an unpatched version should be a time-limited, written exception with an owner and an end date.
Security risks in a delayed or incomplete patch process
Backstage security fixes only protect you if they reach your running instance in time and are reviewed properly. The risks below sit at different points in the patch cycle, from release timing and runtime support to bots, plugins and CI pipelines, and each has a named owner who can check it.
Falling outside the backport window
Backstage backports high and critical severity fixes to releases from the last six months where feasible, so a deployment that stays on an older minor line can lose that coverage. Platform engineering owns the upgrade cadence. Check monthly which release line you run, how far behind the latest release you are, and whether a planned upgrade can land before the window closes for your version.
Unpatched Node.js runtime
Backstage supports two adjacent even-numbered Node.js releases, so a runtime that falls out of that pair stops receiving the support the project relies on. The platform team owns the container base image and the Node.js version pinned in the build. Confirm which Node.js major version your image uses, check it against the versioning policy for your Backstage release, and rebuild the image when the base image receives security updates.
Lagging plugins with broad permissions
Third-party plugins often update more slowly than core Backstage and may hold credentials, proxy routes or scaffolder actions that reach sensitive systems. A stale plugin can block the core upgrade or stay vulnerable after the core is patched. The plugin owner in your team should list every installed plugin with its version, its maintainer and the permissions and secrets it can use, then decide whether each one can be updated, replaced or removed.
Bots that auto-merge without tests
Dependabot, Renovate and similar tools can open and merge version bumps faster than anyone reviews them. If the merge gate skips the build, the test suite or the authentication and catalog checks, a broken or malicious update can reach production. The repository owner should require passing CI and a human approval for changes to package.json and lock files, and allow automatic merge only for patch updates that pass the full test suite.
Secrets exposed in CI logs during upgrades
Upgrade jobs often print environment variables, configuration dumps or debug output while they install packages or run the build. Those logs can expose integration tokens, signing keys or database passwords to everyone with read access to the pipeline. The DevOps or security engineer should mask secret variables in CI, avoid echoing configuration during yarn backstage-cli versions:bump, and restrict who can view or download job logs.
Unreviewed dependency changes
Version bumps that move transitive dependencies can add new code paths that nobody has read, including packages that change install scripts or network calls. Reviewers who only read the version number miss these changes. The application owner should review the lock file diff for new or removed packages, check the Backstage Upgrade Helper for template changes, and record who approved each upgrade so the change history matches what is running.
Common questions about patching Backstage
How much effort does a Backstage patch cycle take?
The effort depends on how far your app has drifted from the current release line, how many custom or third-party plugins you run, and how much testing your portal needs before a change reaches production. A routine bump that moves all @backstage packages together with yarn backstage-cli versions:bump is usually the smallest case. Larger drivers include template changes shown in the Backstage Upgrade Helper, Node.js changes, and plugins that need code edits to compile against new APIs. Ask any partner for a written scope that lists the current version, the target version, the plugins in use and the test environments you will provide, because those inputs set the work. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and provides a quote from that scope.
Can our own team patch Backstage without outside help?
Yes, many teams run the cycle in-house if they have a platform engineer who reads release notes, a test environment that mirrors production, and time set aside each month. The Backstage release and versioning policy ships a main release line monthly and a next release line weekly, so the cadence is predictable. The harder parts are reading security advisories quickly, testing custom plugins that the community does not maintain, and keeping the app within the six-month backport window for high and critical fixes. Check whether your team has someone who can own the upgrade on a fixed schedule, and whether that person has time that does not compete with feature delivery.
What does a retainer cover compared with a one-time upgrade?
A one-time upgrade is a fixed-scope job: it moves your Backstage app from a stated version to a stated version, updates the affected code and configuration, and hands over documentation and test results. A retainer is a recurring agreement for ongoing work such as tracking advisories, applying patches within the agreed scope, running upgrades on a set cadence and responding to plugin breakage. DeployOpen offers ongoing support, upgrades and continuous testing as retainers. The written scope should state which advisories are covered, which plugins are in scope, what response expectations apply, and whether any SLA is included. Ask for those terms in writing, because a retainer without them is hard to evaluate.
How do we handle third-party plugins that lag behind core releases?
Start by listing every plugin in your app and recording its package version, its source repository and its last release date. A plugin that does not support the current @backstage packages blocks the core bump, so you need a decision for each one: upgrade it, fork it and patch it, replace it, or remove it. Vetting before install matters here, because an unmaintained plugin becomes a permanent patch obligation. Some plugins move repositories or change their APIs between versions, which adds work to the upgrade. Confirm with each plugin maintainer whether a compatible release is planned, and treat any fork you maintain as code your team or partner owns from that point on.
Which advisories should we track and how do we read them?
Track the security advisories published for the Backstage repository on GitHub, the GitHub releases page, and the advisories for each Node.js release line and each third-party plugin you run. Backstage's versioning policy says high and critical severity vulnerabilities will always be backported to releases from the last six months if feasible, and other security fixes may be backported. Read each advisory for three things: the affected package and version range, the severity, and whether your app uses the affected code path. Your dependency scanner, whether Dependabot, Renovate or Snyk, can flag affected packages, but a person still needs to decide whether the exposure applies to your configuration.
What do we need to provide before patching starts?
The work needs repository access to the Backstage app and its plugin code, a staging environment that matches production closely enough to catch configuration problems, and a database snapshot or backup process you can restore from. You also need named owners: one person who approves scope and risk, one who answers questions about each custom plugin, and one who can approve the production change window. Provide the current version, the list of installed plugins, the authentication providers in use and any custom backend modules. Missing inputs usually extend the first cycle more than the work itself, so confirm them before you ask for a quote.
Does a patch cycle change how Node.js versions are handled?
It can. Backstage supports exactly two adjacent even-numbered Node.js releases, and the versioning policy names the supported pair for each Backstage release line. As of Backstage 1.46.0, the supported releases are Node.js 22 and 24. When a patch cycle moves you to a newer Backstage line, check whether the Node.js runtime in your container image and CI pipeline is still in the supported pair. Node.js changes can alter build behavior, native module compatibility and container base images, so include the runtime in the test plan rather than treating it as a separate task. Confirm the current pair in the versioning policy before you schedule the work.
What to confirm before you rely on a patch schedule
A patch schedule is only as reliable as the assumptions behind it. The items below are the facts you should confirm with the Backstage project and against your own plugin inventory before you promise a patch window to your security team. Each one changes how fast you can actually move.
Current supported Node.js versions
Backstage supports two adjacent even-numbered Node.js releases, and the set changes as the project moves forward. As of Backstage 1.46.0 the supported pair is Node.js 22 and 24, but you should confirm the current pair in the versioning policy before you choose a runtime image. If your container base image sits on an unsupported Node.js line, a Backstage security fix can require a runtime change you did not plan for.
Backport coverage for a specific advisory
The project commits to backporting high and critical severity fixes to releases from the last six months where feasible, and other security fixes only may be backported. Confirm for each advisory which release lines receive the fix, because your pinned version may fall outside the window. Record the answer in your change ticket so the decision to upgrade or accept risk is traceable.
Bot coverage of your plugin set
Dependabot, Renovate or Snyk only opens pull requests for packages it can see in your manifests and lockfile. Check that the bot scans every workspace in your monorepo, every plugin you installed from npm, and any plugin vendored into your repository. Plugins installed by Git URL or copied source often fall outside automatic detection and need a manual review step.
Plugin support for the target @backstage version
Third-party and community plugins may lag behind the core release line, and some depend on @backstage packages that the next bump removes or renames. Before you move the whole @backstage set with the version bump command, confirm each plugin publishes a release compatible with the target version. A plugin without a compatible release is a decision point: fork it, replace it, or delay the bump.
Your release cadence and test environment
The main line ships monthly and the next line ships weekly, so the version you run determines how often you must absorb changes. Confirm that a staging environment with your real plugins, auth providers and PostgreSQL exists and can be upgraded before production. Without it, the schedule depends on assumptions the first failing upgrade will expose.
Ownership of advisory triage
Someone must read advisories, decide severity against your deployment, and assign the upgrade. Confirm which team owns this, how they receive project notices, and who approves an exception when a fix is not backported to your line. Without a named owner, bot pull requests accumulate unreviewed and the window closes silently.
How DeployOpen works on this
DeployOpen scopes Backstage patching as a fixed, written piece of work covering your app repository, your dependency tooling, your advisory process and your third-party plugins. We build the update workflow in your own environment, document how your team triages advisories, and offer ongoing support as a retainer if you want help keeping pace with releases.
How we scope
- The written scope names the Backstage app repository, the update tool (Dependabot, Renovate or Snyk) and who reviews its pull requests.
- We list every third-party plugin in use, its source, and whether its maintainer keeps pace with Backstage releases.
- The scope states the target release line and which advisories your team must act on, and how quickly, in your own terms.
How we build
- We configure automated dependency updates so all @backstage packages move together, grouped the way the Backstage upgrade tooling expects.
- We set up a test pipeline that builds the app, runs the test suite and checks the Node.js versions your release line supports.
- We align plugin version pins with the Backstage release in use and record any plugin that needs a fork or manual patch.
How we hand over
- You receive a runbook covering how advisories are read, triaged, tested in staging and promoted to production.
- The handover documents the update tool configuration, branch rules and the owner for each third-party plugin.
- We walk your platform team through a live patch cycle so they can run the next one without DeployOpen involved.
How we support
- Ongoing support, upgrades and continuous checks are available as a retainer, and the retainer scope is agreed in writing.
- Retainer work can include reviewing monthly and weekly release changes and preparing patch branches for your team to approve.
- Support scope, response expectations and reporting cadence are confirmed in the contract, so ask for them in your quote.
