Skip to main content
Version: Next

v1.40.0

These are the release notes for the v1.40.0 release of Backstage.

A huge thanks to the whole team of maintainers and contributors as well as the amazing Backstage Community for the hard work in getting this release developed and done.

Highlights​

Scaffolder 2.0 Breaking Changes​

The deprecated legacy action formats have been removed and replaced with the new native zod formats.

This also cleaned up some deprecated logStream and WinstonLogger usages in the old patterns.

// really old legacy json schema
createTemplateAction<{ repoUrl: string }, { repoOutput: string }>({
  id: 'test',
  schema: {
    input: {
      type: 'object'
      required: ['repoUrl']
      properties: {
        repoUrl: {
          type: 'string',
          description: 'repository url description'
        }
      }
    }
  }
});

// old zod method
createTemplateAction({
  id: 'test'
  schema: {
    input: {
      repoUrl: z.string({ description: 'repository url description' })
    }
  }
})

// new method:
createTemplateAction({
  id: 'test',
  schema: {
    input: {
      repoUrl: z => z.string({ description: 'repository url description' })
    }
  }
})

The scaffolder-backend plugin has been converted to being New Backend System only, which means a lot of the public API has been cleaned up.

The createRouter and createBuiltinActions have been removed as they were only used in the legacy backend system.

A lot of deprecated types which were re-exported in the -backend package from -common and -node have been removed, and can be fixed by importing them from the correct package.

The deprecated copyWithoutRender option has been removed from fetch:template and should be renamed to copyWithoutTemplating.

The re-exported action creators from the provider packages such as createPublishAzureAction and createPublishGithubAction should now be imported from the provider modules themselves.

As always you can head over the latest changelogs for @backstage/plugin-scaffolder-backend and @backstage/plugin-scaffolder-node for more detailed information.

There’s also a number of new deprecation for types which are currently exported from plugin-scaffolder-node. We’re going to be looking at re-working the Scaffolder architecture in the future, so we’re going to be removing these types in a future version to iterate on the new API surfaces. Stay tuned for more updates!

Actions Registry​

We’ve added two new alpha services which can be used to define distributed Actions across Backstage. Plugins can use the ActionsRegistry to define actions that are automatically installed with their associated plugin.

On top of this Actions Registry is a new mcp-actions backend plugin, which will surface these actions as tools as an MCP server. This can be used to expose plugin Actions with your favourite AI tools, such as Cursor, Claude or ChatGPT.

You can find out more information about the ActionsRegistry and MCP integration in this RFC.

We’re actively working on this area, therefore it’s currently highly experimental and could be subject to breaking changes in future releases. However we’d really appreciate some feedback if you want to try and create some Actions for your plugins and surface them in an MCP server!

In the next release we’ll be looking to integrate these Actions with the Scaffolder allowing you to call these actions from a template.

TechDocs deep linking​

Introduced backstage.io/techdocs-entity-path annotation which allows deep linking into other TechDocs in conjunction with backstage.io/techdocs-entity.

Contributed by @csuich2 in #29760

Catalog modules Breaking Changes​

  • BitbucketCloudEntityProvider now accepts a CatalogService instead of CatalogApi
  • User and Group discovery for GitLab will default to ingesting all users in sub groups that belong to the specified root group in config. Disable by setting restrictUsersToGroup: true in app-config under your module settings.

New Module drop: @backstage/plugin-events-backend-module-kafka​

The module introduces the KafkaConsumerClient which creates a Kafka client used to establish consumer connections. It also provides the KafkaConsumingEventPublisher, a consumer that subscribes to configured Kafka topics and publishes received messages to the Backstage events service where Backstage plugins can access them.

Contributed by @Jonas-Beck in #29315

New lint rule added​

A new lint rule @backstage/no-mixed-plugin-imports was added to the defaults. This enforces rules that were always true but until now were implicit: that you should not import across frontend and backend package boundaries, isomorphic packages should not import non-isomorphic, etc.

This rule is initially only set at a warning level, to give you some time to react. You may see warnings appear in your build output that were not there before - do pay attention to them, because they may expose some issues that you had not yet noticed.

We intend to make this rule be at an error level in a future release.

The rule has an option excludedTargetPackages that lets you opt out of enforcement in specific packages. You can put something like this in your root .eslintrc.js:

module.exports = {
  root: true,
  plugins: ['@spotify', 'react', 'testing-library', '@backstage'],
  rules: {
    '@backstage/no-mixed-plugin-imports': [
      'error', // if you want to opt in to strict checks early
      {
        excludedTargetPackages: [
          '@internal/plugin-foo',
          // ...

Contributed by @drodil in #30227

CLI: movement toward rspack​

The BACKSTAGE_CLI_EXPERIMENTAL_BUILD_CACHE flag has been removed entirely. If you were using this flag, we encourage you to switch to EXPERIMENTAL_RSPACK instead. In the near future, we hope to make rspack the default out of the box.

While making these changes, the experimental FORCE_REACT_DEVELOPMENT flag was removed as well.

Backend rate limiting​

The backend system now has builtin support for rate limiting of incoming requests, both for your entire backends and on a per-plugin basis. It can use different backing stores for its state, and in-memory and redis is currently implemented out of the box.

You can read more about this opt-in feature in the documentation for the HTTP router service.

Contributed by @drodil in #28708

New Frontend System plugin info​

Plugins in the new frontend system can now expose rich, extensible metadata about themselves. This data is accessible at runtime inside your app. This is for example useful for adding contact and support information, and much more - and you can even overlay your own data on top of what is provided by open-source plugins.

You can read more about this in the frontend app and plugin architecture documentation.

Notifications retention​

Notifications that are stored by the notifications backend plugin now have a default retention of one year before being deleted. This helps keep the storage size in check over time. You can override this using the notifications.retention duration setting in your app-config.

Contributed by @drodil in #30206

Lots of i18n work​

A bunch of work was done to enable i18n (translations) in several plugins! This affected at least the following:

  • core components
  • the org plugin
  • the catalog import plugin
  • the home plugin
  • the search plugin
  • the user settings plugin

Contributed by @mario-mui

Canon steams ahead​

While it’s still early days, we still want to call out that the canon design system work steams ahead with various controls added and improvements made. Hang tight!

Security Fixes​

This release does not contain any security fixes.

Upgrade path​

We recommend that you keep your Backstage project up to date with this latest release. For more guidance on how to upgrade, check out the documentation for keeping Backstage updated.

Below you can find a list of links and references to help you learn about and start using this new release.

Sign up for our newsletter if you want to be informed about what is happening in the world of Backstage.