Backstage 1.55 removes catalog compatibility APIs and raises the Elasticsearch floor

Backstage 1.55.0, published September 15, removes several deprecated catalog interfaces and raises the minimum supported Elasticsearch version for its search backend. The changes matter to platform teams that maintain custom catalog processors, TechDocs builds or software templates, including teams assessing future uptake through Red Hat Developer Hub.

What changed

The catalog backend no longer supports the catalog.enableRelationsCompatibility option. Entity relations now use the standard targetRef field; integrations that still read the compatibility-layer target field must move to targetRef.

The release also removes the deprecated CodeOwnersProcessor and AnnotateScmSlugEntityProcessor. Backstage directs users to the corresponding community catalog-backend modules instead. The old catalog.stitchingStrategy.mode setting is gone as well, while pollingInterval and stitchTimeout remain supported.

For search, @backstage/plugin-search-backend-module-elasticsearch now uses the Elasticsearch 8 client and requires Elasticsearch 8.19 or later. The AWS and OpenSearch providers continue to use the OpenSearch client and are not affected by that minimum-version change. Code that depends on raw Elasticsearch client response types must also adapt to the module's normalized response shape.

Backstage UI link components now delegate routing to the host application's client-side router. TechDocs generation strips MkDocs plugins that are outside its built-in allowlist unless operators explicitly permit them. The release also removes a set of github:repo:create inputs that were accepted but ignored.

Who it affects

The highest-risk upgrades are installations with custom catalog processors, code that consumes relation objects directly, Elasticsearch-backed search, additional MkDocs plugins, or templates that pass branch-protection and authoring options to github:repo:create.

The release notes describe upstream Backstage behavior. They do not establish when or whether these changes will appear in a particular Red Hat Developer Hub release, but they give Developer Hub extension maintainers a concrete compatibility list to test against.

What to do

Before adopting Backstage 1.55, search application configuration and plugins for the removed catalog settings and processors. Update relation consumers to targetRef, replace the deprecated processors with the named community modules, and verify that Elasticsearch is at least 8.19 when using the Elasticsearch provider.

TechDocs operators should review their MkDocs plugin list and explicitly allow any additional plugins they intend to retain. Template owners should remove obsolete github:repo:create inputs and move supported branch-protection, authoring and publishing options to github:repo:push where appropriate.