More Roadie MCP Server(s)

Last month we launched a set of Model Context Protocol servers to provide data to any LLM-powered MCP client that can accept authenticated external servers, like Cursor or VSCode with Copilot.

This month we've extended that offering to include a few more of the bells and whistles you get with Roadie: backend config and the ability to manipulate Catalog entities via the Decorator.

For those not au fait with the current boom in MCP server creation, MCP is a protocol created by Anthropic last year to help standardise the way data is sent to LLMs and how models can access tools. Via an MCP server (or servers) you can give LLM-powered application access to data and tools that the foundational LLMs could never have.

We've added two new ones:

• The Backend Config Server provides specialized MCP tools for managing and querying backend configuration in Roadie.
• The Catalog Decorators Server provides MCP tools for managing catalog entity decorators/fragments in Roadie.

Now you can, from the comfort of your IDE or MCP client, in addition to accessing the Catalog and the Scaffolder, you can:

• List out proxies, lists ones which are correctly configured, and returns the path for any given proxy
• List the available secrets that can be used in proxy configurations
• Query and then append additional information to Catalog entities via a fragment, like new specifications, metadata, etc

All you need to get going is an API token from Roadie and away you go.

Full docs for all released MCP servers can be found here: https://roadie.io/docs/details/roadie-mcp/

API tokens for all

We've added a new role to api-token-creator which, when added to a user, allows them to (wait for it...) create API tokens.

This has previously been a permission attached by default to the Admin role, and for customers not paying for Role-based Access Control they wouldn't have been able to delegate that permission to non-Admins easily.

That API token opens up all the MCP server capabilities we've been working on, so it makes a lot of sense for us to make it as easy as possible to get a token.

En Masse Changes in the UI

To make it easier to add that role to all users (and general make mass changes for various Admin tasks) we've introduced en masse changes.

You can now make mass changes to:

• Add or remove roles to sets of users
• Mass deletion or cleanup of Locations if they're no longer necessary

Simple.

Moving to the AI SDK from Mastra

This is a quasi-behind-the-curtain update from us, but as we move forward with AI feature building we've made the choice to move from Mastra, a way to build agents in TS, to Vercels AI SDK, a more fully-fledged . Mastra wrapped AI SDK v4 and provided some added bells and whistles, but as this space moves so darn fast Vercel caught up (and actually out-paced Mastra) and we found ourselves looking longingly at the features we could unlock by adopting the AI SDK directly.

What this means for those beta testing new AI features from us is:

• Streaming of chats (and generally a 'hey this feels like ChatGPT or Cursor' feel)
• History, UI elements and a much more dynamic chat
• Chat as a pop-up or slideout (coming soon)

OpenSearch hits GA

OpenSearch has hit GA for Roadie so now all customers can benefit from our new search backend.

We'll be making tweaks to result ranking and indexing over the next few weeks and months as we gather more feedback from users, so let us know if your results are not what you'd intuitively expect.

Anything else?

No.

Happy Summer everyone (or at least for those in the Northern hemisphere)! 😎⛱️

Roadie MCP Server(s) for your LLM-powered Applications

We're launching a set of Model Context Protocol servers that can provide data to any LLM-powered MCP client that can accept authenticated external servers, like Cursor or VSCode with Copilot.

For those not au fait with the current boom in MCP server creation, MCP is a protocol created by Anthropic last year to help standardise the way data is sent to LLMs and how models can access tools. Via an MCP server (or servers) you can give LLM-powered application access to data and tools that the foundational LLMs could never have.

It's a client-server architecture, so you can then connect those MCP servers to whatever MCP client you wish. MCP clients range from chat interfaces like the Claude App to full blown AI IDEs like Cursor.

Now you can, from the comfort of your IDE or MCP client, do all kinds of things:

• Access Catalog entity data, relationships, and documentation
• Find, validate, and execute scaffolder templates
• Discover and retrieve API documentation and specifications to build API clients
• Access Tech Insights fact data (TI subscription needed, of course)

All you need to get going is an API token from Roadie and away you go.

Full docs for all released MCP servers can be found here: https://roadie.io/docs/details/roadie-mcp/

AI-enabled search [in beta]

In 2024 we open-source the RAG AI plugin to make AI features in Backstage as widely available as possible.

Implementing those features in Roadie though has taken some time. We wanted to generally improve search before bringing AI into the mix. With OpenSearch powered search results now fully rolled out, we turned out attention to integrating the RAG AI plugin fully into our search.

You can:

• Ask natural language questions of your Tech Docs and Catalog, like Summarise the Streelight service API docs or How does the Streelight service interact with other services?
• Focus on a specific Doc or Catalog entity to narrow results and ask detail questions only about that specific entity.

General availability expected in September / October.

Vibe code your own UI inside Roadie with MDX [in beta]

As part of a Support task, we accidentally allowed anyone to vibe code their own UI inside Roadie.

That might sound silly, but hear me out...

To cover a simple use-case of 'I just want to call and API and render some data back' we exposed an ApiViewerCard to call an API from the frontend (as long as you have a proxy configured for that call).

Then we added MDX configurability to that card and it morphed into the MdxPluginCard.

Then we exposed some common Roadie components to make it easier to compose a card that looked and felt at home in the rest of the UI.

When you put it all together (as some early customers have now started to do) you get some fairly nice cards that do exactly what you need them to.

Not only that, given the widespread use of MDX, you can also get an LLM to vibe code them for you.

For simple use-cases where you don't want to build a full custom plugin, but you do want some ability to pull in data that is not currently supported by a card or plugin: this is your guy.

The next step in this direction? The MDX can be fully generated from prompts inside Roadie, so you don't even have to leave your instance.

Then fully generated entity page layouts...

The future is now...

Tasks now exposed via the Scheduler

To take a small step back from AI-AI-AI-AI, ALL THE TIME, EVERYWHERE, we also introduced a new Scheduler page to the Admin interface. This allows you to see the active jobs and self-serve re-triggering them if necessary.

We're continuing to expose Admin controls like this as a necessary part of an AI work. As AI starts to take over Roadie, we want Platform teams to have more control and visibility, not less.

Improved Launch Darkly plugin

The Launch Darkly plugin we span up last year was looking a little lacklustre and so we've spruced it up.

For those that use Launch Darkly for feature flag management:

• There's now a card displaying environment statuses for each feature flag
• Updated visual indicators for feature flag status (pills rather than text)
• A general spruce of the card UI to make it easier to understand what's happening at a glance

More info can be found in the docs: https://roadie.io/docs/integrations/launchdarkly/

Anything else?

No.

That was quite a lot for one month :)

Introducing the Roadie MCP Server

Roadie has always served a wide range of users, but first and foremost we're a software catalog and automation portal for software engineers.

As such, Roadie (and Backstage, upon who's shoulders we stand) has always been a good dashboard, acting as a single pane of glass for all kinds of fragmented dev tools and scattered pieces of documentation.

But it's always been a tool that you had to step out of your development workflow in order to access.

The classic flow for most engineers using Roadie was to either have Roadie open as a broswer window as they worked, or to step out of the IDE to ask questions of the Catalog, get wider context on your work, or provision some new service using the Scaffolder.

That context switch has always been a problem we'd like to solve.

Luckily the answer is here: it's the Roadie Model Context Protocol (MCP) Server(s).

What's an MCP Server?

MCP is a protocol introduced by Anthropic in November 2024.

The protocol itself is based on a simple client-server architecture. MCP Clients - like the new wave of IDEs (Cursor, Windsurf, VSCode with Copilot, etc) - act as clients that can call MCP servers to get additional information.

MCP servers allow the LLMs at the heart of newer software development applications to receive additional, specific context about the query that a user is making which wouldn't be well represented in the foundational model. MCP servers are therefore great for enriching responses when a base LLM simply wouldn't be able to generate a good enough answer.

For example, if you ask ChatGPT or Claude to generate you a Backstage Scaffolder Template it will do a good-ish job because it was trained on enough open-source templates to do that. The format will be largely correct, for example. But, it will also hallucinate actions because it thinks they might logically exist. It also won't know which scaffolder actions you have installed. This isn't great if you want to actually run that template or automate a development flow involving the scaffolder.

If you tried the same case again but this time with an MCP which returned useable scaffolder actions upon request, then the LLM has a much better chance of generating a functional Template.

How can I use it?

The Roadie MCP server works with any tools that can act as an MCP client, including Claude Desktop, VSCode Copilot, and Windsurf Editor.

If you have your own MCP client with the capability to interact with remote MCP servers with authentication headers then this should also work.

You'll need a Roadie API key. Admins have access by default. There's a role in Roadie which, when enabled, can give users the ability to create their own API key.

Docs on how to get started can be found here: https://roadie.io/docs/details/roadie-mcp/

What can the Roadie MCP servers do?

With the four MCP servers we've currently exposed, you can:

• Access catalog entity data, relationships, and documentation
• Discover and retrieve API documentation and specifications
• Find, validate, and execute Backstage scaffolder templates
• Access operational metrics, security data, and compliance information from Tech Insights (if you're a Tech Insights customer)

Example: OpenAPI specs.

By asking questions in your MCP client, you can integrate two systems, assuming the one you're integrating with exposes OpenAPI specs documented in Roadie.

You would say something like this to you LLM:

“I need to integrate with our User Management system”

The MCP client will then make a call to our MCP server. The steps will look something like this:

• Searches for user-related APIs using find-api-specs
• Retrieves specifications for relevant APIs
• Explains available endpoints, authentication, and schemas
• Provides integration guidance and code examples

You'll then get an implementation of an integration between your current code base and the User Management system, that takes into account how the User Management API actually works.

Example: Creating a new project using the scaffolder

You would say something like this to you LLM:

“Create a new React frontend application”

The MCP client will then make a call to our MCP server. The steps will look something like this:

• Searches for React templates using find-scaffolder-templates
• Shows available templates and their requirements
• Guides user through providing necessary parameters
• Validates inputs using validate-template-values
• Executes template using run-scaffolder-template
• Monitors progress and reports results

You'll then get an complete application based on the provided template.

How does authentication & permissions work?

Getting permissions right in the context of MCP Servers, and AI and agentic systems more broadly, can be tricky.

To solve that for the Roadie MCP Server(s), we've architected the Roadie MCP to have access to the authentication and permissions that the same user would have in the web app. We do that by combining two things:

• Roadie RBAC plugin
• Roadie API using user-scoped tokens

A user generates an API token in the web app for use in their MCP Client of choice. That token inherits the permission that the user has. It's evaluated on each call to ensure the permissions stay in sync. Tokens expire after 1 year.

When will it be generally available?

Folks who have opted in to our early-access AI features will have access shortly. After that we'll begin a wider rollout. Existing customers will be sent a message in the communication tool of choice (Slack or Teams) to onboard them.

OpenSearch for all

The OpenSearch rollout began last month and has not reached general availability.

If you missed it last month that means:

• Casing is better handled: camelCase, kebab-case and snake_case are factored in, so the user doesn’t need to know which was used when they’re searching
• Partial search terms and descriptions are better handled: for example, skipping some-word in camel-some-word-case and just typing camel case will be returned as a result.
• Word fragments allow for partial word matches. We’re currently using 4-7 chars for the ngrams, so fragments of words should be well matched

But that's not the only thing happening with search...

Unified Search enters [beta]

We've also tweaked the UI to create a new search UI that captures more information and provides a generally slicker interaction with search.

The new UI allows you to:

• Use keyboard shortcuts (Cmd-K from anywhere in the app to bring it up)
• Navigate as well as search (try searching for “Catalog”) for example.
• Do things a little faster than before (performance is improved)

Unified search not only enables greater discoverability within Roadie, but is also our first step in enabling RAG AI-enhanced searching of the Catalog and Tech Docs. In fact, it'll be the entry point for a few different AI features we're dreaming up.

We're already seeing search volume and click-through to an entity that then doesn't result in a new search (i.e. "Yay, I found what I was looking for") go up as result.

More on that over the next couple of months as our AI journey continues...

Supporting both GitHub.com & GitHub Enterprise Server

As our customers grow, so do the number of different SCMs deployed in any given organisation.

For a while we've dealt with the GitHub Cloud <> BitBucket combo.

Now we can handle the GitHub.com <> GHES combo too. Aside from setting up both SCMs there's nothing additional you'll need to do - it's all handled by a new GitHub switcher.

Nice.

Roadie Local [beta] begins

Roadie Local, the locally runnable version of Roadie you can deploy on your infrastructure, has entered beta.

We weren't expecting a long beta but who knows when you get into the weird and wacky world of on-prem deployment. More to come here I'm sure...

Rootly Plugin

The Rootly plugin recently released v1.0.0 of their plugin, which we've dutifully upgraded. It comes with a lot of new fun stuff, including the ability to:

• View and search a list of entities
• View and search a list of services
• View and search a list of functionalities
• View and search a list of teams
• View and search a list of incidents

Rootly <> Roadie customers: enjoy. https://roadie.io/docs/integrations/rootly/

Terraform Plugin

We also introduced the Terraform plugins to help Terraform Cloud users manage their infrastructure.

Docs on it can be found here: https://roadie.io/docs/integrations/terraform/

Upgrade to v1.39

Last but not least, Roadie is now on Backstage version 1.39.

Full change notes for that update can be found here: https://backstage.io/docs/releases/v1.39.0/

AI is coming...

We've been playing around with AI features in Roadie for around 18 months now, ever since we open-sourced the RAG AI plugin way back in 2024.

We've struggled to understand how though.

A breakthrough came this month as we got stuck into the developments that have taken place in late 2024 and early 2025, notably the improvements in foundational models and in the introduction of the Model Context Protocol (MCP) paradigm.

We'll be pulling at a few different threads over the next few weeks and months to see what's feasible in the short-term, so watch this space for things like:

• RAG-AI-powered search
• MCP servers to return data and actions from your Roadie instance
• Integration of common (but complex) actions into the UI, powered by AI

Plugins, plugins, plugins

In the meantime, we've introduced two substantial plugin improvements into Roadie that radically improve ingestion of entities.

Kratix

The Kratix Platform has grown in popularity recently as more folks a) adopt the idea of an internal platform and b) want an open-source alternative to the proprietary platforms that exist out on the market.

That's something that we want to support and foster. We're big believers in open-source, as you'd imagine given we're built on top of an open-source product and regularly contribute to various oss projects.

Kratix plugins are now available in Roadie. You'll need to be a paid Kratix user to access them, as is the model for the folks behind Kratix (Syntasso, in case you were wondering) but we now suport:

• Kratix FE plugin
• Kratix BE plugin
• Kratix scaffolder actions

Enjoy. https://roadie.io/docs/integrations/kratix/

Terasky K8s Ingestor and Crossplane plugins

We also folded many of Terasky's Kubernetes plugins into Roadie.

Terasky have managed to thread the needle with improving the way Backstage interacts with Kubernetes and done so in order to ingest entities directly from K8s clusters.

They've also open-sourced Crossplane plugins to allow Backstage to:

• Ingest Kubernetes Components
• Ingest XRDs
• Ingest Claims

Check out our docs here.

Introducing OpenSearch for better discoverability

As the volume of data in the Catalog grows, we often see customers hit a discoverability problem: how do you find items when the Catatlog is tens of thousands of, often very similar seeming, entities?

Well: search. Duh.

But, how do you make sure search results are fast, accurate and scalable? Backstage supports different search engines, but the better ones (Elastic-like ones like OpenSearch) tend to get expensive at scale, especially when you run almost isolated stacks for each customer as we do.

This month we dedicated a bit of time to figuring out how to do it at scale, and voilà! Better search has arrived!

We stripped out the old search engine and brought in OpenSearch, an Elastic-search-like search engine (an open-source one, of course).

That means you get a few improvements out of the box:

• Casing is better handled: camelCase, kebab-case and snake_case are factored in, so the user doesn't need to know which was used when they're searching
• Partial search terms and descriptions are better handled: for example, skipping some-word in camel-some-word-case and just typing camel case will be returned as a result.
• Word fragments allow for partial word matches: We're currently using 4-7 chars for the ngrams, so fragments of words should be well matched

We also have brought ourselves a lot more headroom here for optimisation - we'd reached the end of the line with the pg_search after many years of trying to force it to be the search engine that we'd have liked it to be. OpenSearch has a lot more we can tweak.

So what's next? We'll be rolling out OpenSearch progressively to customers, starting this month.

Mobile UX gets some love

Being able to search for something in the Catalog is one thing, but if you can't readily view it or the experience is poor then that's not much use.

Roadie is largely optimised for web (big tables of software == a laptop or desktop-based experience is always going to be best) but there's a baseline for usability that should be met to make some key use-cases function.

This month we focused on the use of tech docs on mobile. If it's 4am, you've just been woken up by an incident, and you need to quickly read a runbook to see what to do next: probably best to not have to get your laptop out when you have your phone right there.

Tech Insights historical data ingestion gets 12x more data-ness

Tech Insights push-based Data Sources allow for historical data ingestion for our customers when migrating from other systems to Roadie. That's been in place for a while, but this month we bumped the volume of data you can ingest.

Over the last few months we've seen more and more customers want to ingest a lot of data. Part of that is the growing maturity of scorecards as a concept within the wider industry, but also part of the wider shift towrads managed Backstage as the IDP of choice for many orgs.

Down to brass tacts though: the push-based data source can now ingest one year of data. Previously it was 1 month.

DX Plugin

Last but not least, we've introduced the DX plugin to Roadie to help sync the Catalog between the two.

More details here for those that are interested: https://roadie.io/docs/integrations/dx/

This is something we're expecting to see a lot of in the coming months: dev tools that need a software Catalog simply sync to a Catalog like Roadie/Backstage rather than build it themselves. Tools like DataDog and Sentry are dipping their toes into the software Catalog world but it's a tricky business keeping up to date with all the different sources of truth and ingestion mechanisms: that's why open-source tools like Backstage will always have the edge.

More on this trend on the New Stack for those that are interested.

Performance Improvements: Catalog Pagination & Service Workers

We mentioned in the previous Changelog that we've been working on a buffet of different improvements to both performance and stability to enable us to handle large Catalogs.

Top of mind this month has been performance of the backend and response time when users make simple requests of the Catalog. That means: pagination time.

The first pass of pagination has proven we can dramatically reduce page load times without impacting the current UI or UX. For the first customers to receive a paginated Catalog we're already seeing a minimum of ~300ms decreases in load time for smaller Catalogs but at least 66% for XL Catalogs (i.e. 100s of thousands of entities).

This is comparing the P95 scores for page load that we see across all our customers. Red is the rollout where we migrated a few customers over but some customers remained on the older, unpaginated Catalog. Green is the period where the paginated Catalog was fully rolled out.

We've also tweaked the filtering UI to handle more filters, while disabling some (Some of the in-table filtering and sorting options are not possible with a paginated catalog).

And last but not least we’ve also changed the UI a little around filtering to clean up how crowded it can become if you have a table with lots of potential filters in place.

We're also separately using service workers to pre-load some elements of the application to further speed up page load. More on that to come.

The rollout of the paginated Catalog has already begun, so more on this soon.

Fun stuff!

All hail the All tab

On a similar theme, the Catalog has also received a major update in the form of an All tab.

About a year ago we started the effort to make the Roadie Catalog as composable as possible.

The Backstage Catalog is extremely extensible and configurable, but sometimes the UI belies that flexibility and makes it feel a little restrictive.

We wanted to highlight the power and extensibility of Backstage in the Roadie-fied version, but also make it significantly easier to make changes to the Catalog.

That's why we have Catalog Tabs (for making easy filters of the Catalog) and the Decorator (to make changes to entities via the UI or the API, without having to use YAML).

One issue with this novel approach is it created a long-tail of issues with plugins upstream. OSS plugins sometimes assume things like a Domain filter can be applied over the Catalog and a filtered list of Domains will be presented to the user. We don't really have that concept by default (and we allow users to remove it) so we've hit a few bugs over the last few months.

The All tab solves that.

The All tab shows you your whole, unfiltered Catalog. You can apply filters over the top of it, as you like. Previous cards that linked through to filtered lists of Domains, Systems etc, will now land here.

We like it a lot - we hope you like it too.

Enjoy!

Admin Area glam-up [in beta]

The Admin area has also seem some significant changes this month.

The old Admin area had grown into a bit of a sprawl in recent times. 70+ plugins and integrations all mixed together, doesn't lend itself to a clean and easy to navigate UX.

We decided a revamp was in order. We focused on the discoverability of plugins - namely moving to a card-based layout and refreshing the search. We also took the opportunity to make changes to the information architecture of this area to chunk up the config options into different tabs.

Next up we'll be standardising each page to make adding secrets, seeing which cards and tabs that plugin exposes are being used, and understanding at a glance how it is configured. After that we'll be looking at how simple health checks and status indicators for each plugin can give greater feedback to users about the health of that connection.

Enjoy.

💈 Roadie Local [coming soon]

We're going on-prem.

We've been toying with this idea for a long-time and we've decided to go all-in on enabling Roadie to be run on customer infrastructure.

We call it Roadie Local.

More soon - we're aiming for a beta launch in March, moving to general availability in Q2 2025.

💈 State of Backstage launches

We're also launching a survey.

When a community reaches a certain level of maturity getting a good lay of the land each year becomes a good idea. Backstage has hit that point - maybe we're even a little late to realise it - so we thought it was time to launch an annual State of Backstage survey.

This is a non-commercial activity for us. It’s solely to foster a greater sense of community and information sharing.

We’ll publish the report from this survey in Spring 2025 for free (of course).

Check it out on the state of backstage.io site.

🔌 Plugins & Integrations roundup

• Announcements plugin: we pulled in the Announcements plugin to give customers the ability to post updates and requests to their userbase within Roadie. It's a plugin that's been around for some time, but it's developed markedly in the last year or so so we thought it was time. Enjoy!

💈 Performance, Stability & Pagination

We've been working on a bunch of different improvements to both performance and stability.

First among them is pagination of the Catalog, without losing filtering.

We'll be tweaking the filtering UI in the next few weeks and months but the first pass of pagination has proven we can dramatically reduce page load times without impacting the current UI or UX. We're already seeing ~300ms decreases in load time and increased stability for giant Catalogs (i.e. 100s of thousands of entities).

We're separately using service workers to pre-load some elements of the application to further speed up page load. More on that to come.

Last but not least, we've also been chunking up Backstage into separate pods to help us scale the application as usage grows. More on that to come in blog posts, but if you're running a giant instance or have reached scale with Tech Insights, splitting individual parts of the application out into separate pods is generally a good idea.

Fun stuff!

Tech Insights Facts: Aggregated

Sometimes you want to just see a Fact in Tech Insights. You don't want to look at whether it passed or failed a check or whether it is meeting a Scorecard requirement: sometimes you just want the data.

An entity-by-entity view is one thing (which we implemented with Fact Tables) but often you'll want to see a team-by-team view of fact data.

For checks and scorecards we have roll-ups, and now for Facts we have Fact Cards.

Say you're tracking DORA metrics or want to see mean time to resolution for incidents. Now you can :)

GitHub Enterprise Server (GHES) support

We now support both GHES using the Roadie Agent and GHES combined with github.com (if that floats your boat).

Previous iterations of our GHES support have relied on a connection to the GHES instance over the public internet. This is ok for some organizations but not all, and usually if you're using GHES you're pretty pro-security and pro-don't-send-things-over-the-public-internet.

In the past for these use-cases we used the Roadie Agent, which is based on the open-source Snyk Broker, to create a long-lived websockets connection that is fully controlled by the customer. That hasn't, up until this point, worked with GHES though.

Now it does! :)

For good measure we threw in the ability to configure both GHES and github.com simulatenously to allow folks who are migrating from one to the other to support both SCMs on their Roadie instnace.

Enjoy!

🧘‍♂️ Scaffolder Actions table

We have also just launched some good ol' fashioned documentation.

The Scaffolder is an extremely powerful tool, but it doesn't have the same level of documentation or cataloging that plugins receive. It can be tricky to find out which open-source actions exist and how to use them.

To solve that, we created the Scaffolder Actions Directory. We searched the internet high and low to find all the actions we could. Most of them we support, some are hot of the press and not yet included in Roadie. We'll keep updating it as the Actions ecosystem evolves.

Check it out: https://roadie.io/docs/scaffolder/scaffolder-actions-directory/

🔌 Plugins & Integrations roundup

• Wiz plugin: Our Wiz plugin is now certified! The new Wiz security frontend plugin surfaces Wiz data inside Backstage. We've worked with Wiz to give it ol' seal of approval. It's available both inside Roadie and as an OSS plugin. 👩‍🚀🚀

🚨👮 RBAC with Fine-Grained Control

Earlier this year we launched our Role-based Access Control (RBAC) feature to help our customers have greater control over who does what within Roadie.

That started off at a fairly coarse-grain, with the ability to restrict basic CRUD actions within the application to a subset of users.

The ultimate goal was always to have much tighter and more specific controls than that though, so we built a new layer for our RBAC controls.

Now, with our RBAC plugin you can:

• Create and surface custom permissions for your Custom Plugins
• Create custom permissions policies to group those permissions together, either using our built-in permissions or Custom Plugin permissions you've created
• Attach ALLOW or DENY options to those permissions policies so that you can more flexibily articulate the policy you'd like to create
• Target annotations and other entity metadata to attach permissions

That means you'll be able to:

• Target specific catalog items
• Block scaffolder templates that you only want certain users to be able to see or run

🏛️ New Backstage Backend (and we're now on v1.30)

We've made the jump to the new Backend now that it's officially stable. It wasn't a trivial thing though, and there are a few potholes that we hit along the way. To help others making the transition we even wrote a blog about it.

We also took the opportunity to upgrade to v1.30 of the core project, so that's fun.

🎨 Notifications have come to Roadie

A set of Notifications plugins landed with Backstage v1.28 and they've recently been integrated into Roadie. There's still some way to go for Notifications to mature in the OSS project (for example, individual plugins are responsible for emitting notifications and there currently isn't a way to really manage those - they're all just transparently sent to users 😅) but it's moving fast. There should be some notification management in the next release for example.

We'll be working in the next few months on integrating Notifications into various plugins that we manage, including Tech Insights. Exciting stuff!

💈 Scaling, scaling, scaling

Roadie customers have pushed the limits of Backstage lately.

Multiple Roadie customers now have:

• Catalogs with 200k+ Component and Resource entities
• Catlaogs with 10k+ users and groups entities
• Tech Insights facts with millions of data points captured

That presented some major scaling challenges for our infrastructure and the way we have architected our version of Backstage.

After a lot of work to identify bottlenecks, scale cloud resources where required, and signficant engineering time introducing performance improvements, we're now able to comfortably handle even the largest Backstage installations in the world.

🧘‍♂️ Custom Columns v2 & Fact Tables(in beta)

Software Catalogs tend to be tables. They're the most intuitive mechanism for displaying large quantities of information.

Making those tables super-flexible is top-of-mind for Roadie at the moment. So much so that we have not one but two features in beta-testing to help introduce much more flexibility into our tables.

The first is Custom Columns v2. The first cut of Custom Columns allows you to take arbitrary metadata from each Catalog entity and add it to your Catalog tab as a new column. The values were rendered as strings though, so we're adding a whole bunch more types to allow easier comprehension of the information. Think: numbers, colourful ranges, links and Catalog entities, all accessible and filterable from within a Custom Catalog Tab.

The second is Fact Tables, which allow you to display Fact data that you've ingested for your entities from Tech Insights Data Sources (either built-in ones that we provide or custom ones you've created). You can filter it by team and display multiple Data Sources side-by-side.

Soon the two worlds will collide 🌚 🌝, with facts accessible inside Custom Columns. That means you'll be able to have a Catalog tab with data from any configured source alongside existing Catalog data.

🔌 Plugins & Integrations roundup

• Wiz plugin: we made a new plugin! The new Wiz security frontend plugin now surfaces Wiz data inside Backstage. It's available both inside Roadie and as an OSS plugin. Wiz certification for this plugin is ongoing but should happen soon. We'll be working on a Wiz Tech Insights data source after that. Watch this space 👩‍🚀🚀
• LaunchDarkly plugin: we also made a LaunchDarkly plugin for managing feature flags and surfacing configuration inside your Backstage instance.
• Shortcut plugin: we made a Shortcut plugin. It's not quite as widespread as Jira (that's a pretty high bar...) but Shortcut is gaining some traction as a nicer way to engage with software development tickets and workflows. We use Shortcut internaly and we're big fans. Check it out.
• Okta & Jira plugins: we've refreshed our Okta and Jira plugins to make them more seamlessly work with the new Backstage backend. Enjoy.
• AWS account creation: last but by no not least, on the topic of catalog data sources this time rather than plugins - our AWS provider has been modified to ingest EKS clusters and containers auto-magically. This is the first step in allowing a one-hit configuration of both AWS and the Kubernetes plugin (we're currently modifying the K8s plugin to ingest these resources and take the config from AWS).

🚨 A new Product kind

A new kind has made its way into Roadie.

You can now leverage the Product kind in your catalog. It works in much the same way as other business-level kinds like domain and system, which seek to collate and create boundaries around other elements of your architecture.

It's flexible Kind, designed to provide a neat wrapper or intemediary between existing concepts.

You might have:

• Domain > Product > System
• Product > Domain > System
• Domain > System > Product

The relationships and structure of this are up to you. If you have any problems or run into unexpected inability to articulate the model you're after then just let us know on Slack/Teams.

Enjoy. https://roadie.io/docs/getting-started/model-software/

🧘‍♂️ More (and more-flexible) relationships between entities

We have extended the number of permissible relationships between entities to cover different arrangements of entities.

We've also introduced the managedBy and managerOf relationships to provide referential integrity between entities that managed things and the entities themselves. People manage people and people manage services (distinct from ownedBy which is often not accurate at describing responsibilities within a system).

If you want to surface those relationships on an entity page you now can, using the EntityRelationsCard. This allows you to filter the displayed relations and only show the ones that are relevant for your use-case.

More info here about what is now possible. https://roadie.io/docs/catalog/showing-dependencies/

If you require additional flexibility in relationships between entity kinds that is not supported, you can request this to be added via the Roadie Support.

🏛️ Custom columns for your Catalog (in beta)

Ever wanted more control over the columns you have in the catalog? Well now you have it. We expose the setting of default columns and creating custom columns based on entity metadata, for each tab you create in the catalog.

We currently have this in beta, so let us know if you want some custom columns and we'll create them for you.

🎨 Type-based entity layouts

In the past you used to be able to set different entity page layouts for the Component kind based on types, but for all other kinds (Resources, Domains etc) it was limited to one per kind.

This doesn't really make much sense when you think about Resources for example, where an entity that is looking at a kubernetes cluster really needs different information from one looking at a AWS RDS instance.

So we changed it. Type-based layouts are now available for all kinds. https://roadie.io/docs/getting-started/configure-ui/

💈 New sidebar configuration options (in beta)

We've been adding new functionality to the Sidebar for a while in a piecemeal fashion, so we decided it needed a full revamp. You can now:

• Add sidebar items that start with the root pages (i.e. /catalog) resolving a particularly annoying issue where you were blocked from doing so because one of those root pages already existed.
• You can hide the Login to GitHub option entirely for all users.

More info here:

🔌 Plugins & Integrations roundup

• Incident.io plugin: we now expose the Humanitec plugin, so you can view deployment information insider Roadie. Fun.
• AWS account creation: last but by no not least, on the topic of catalog data sources this time rather than plugins - our AWS provider can now create AWS accounts and associated resources auto-magically. We also now ingest AWS tags as part of AWS automatic resource discovery. You can use tags to build relationships between newly ingested AWS resources and other entities in the catalog. Neat.

🚨 Controlling your Catalog with Role-based Access Control (RBAC)

We've been working on this for a while and it is with some fanfare that we announce Role-based Access Control (RBAC) on Roadie. 🤝✨🙌

Transparency of information is at the heart of Roadie (and one of the key philosophical principles of Backstage), but there are often valid reasons for gating access to information and maintaining the principle of least privilege.

For example, let's say you want to onboard Customer Service agents to your catalog so they can quickly find information about a service that may be experiencing some issues. You don't necessarily want to give Customer Service folks the ability to execute a scaffolder run or browse through Tech Insights Scorecards: that's just unnecessary and may even be confusing.

What you need in that situation is fine-grained control over your Roadie instance.

What is RBAC in Roadie?

• A new framework for access control in Roadie
• Every customer will have access to this new framework
• Some features are part of a paid add-on

And how does it work?

• Every part of Roadie is behind a Permission
• Roles are made up of sets of Permissions
• Users have Roles
• Admins can manage roles
• Admins can manage users

🎭 Role management

Several roles are available out of the box. They cover our existing access management setup as well as well as introduce some convenient shortcuts for new user groups that we've seen emerge recently:

• Admin
• Tech Insights Admin
• Maintainer
• Viewer

📚 Roles from a variety of sources, like your identity provider

The new permissions system will be allow you to send us roles from your identity provider as well as define them in the Roadie UI. This will mean the old GitHub Admin group is no longer required

Roles from all sources appear in the Role Management UI so you can understand where a user is inheriting a role from.

🆔 User management

You can then attach users to roles in the User Management UI and update the roles (and therefore permissions) that a user has access to on-the-fly.

As part of the switch-over to the new permissions system we run a background task to map the old roles system to the new one so there's no switching cost for existing customers.

🛃 Custom permissions and roles

The out of the box roles will get you so far, but any organisations need or want a higher degree of control over who can see what in their Catalog, who has the right permissions to trigger Scaffolder actions, and which elements of Tech Insights are or aren't displayed to certain users.

That's where custom permissions policies and roles step in.

The ability to create new roles and attach fine-grained permissions are optional paid extras and will cover use cases like hiding services in the catalog or controlling who can run individual scaffolder templates. We can setup trials/start discussions if you’re interested.

What's next for RBAC?

Individual entity permissions

At the moment, while we allow for a much higher degree of control over the catalog than before, we haven't drilled down to the individual entity level to say You need to have permissions-to-view-X-component` to view X component'. That's next.

That will mean you can:

• Control access to individual components or entities
• Control access to scaffolder templates and actions
• And create your own extremely specific permissions to target these entities

🙌 Backstage 1.26

We've now upgraded everyone to 1.26. This upgrade introduced some significant changes to the authentication system and lays the groundwork for the notification systems that lands fully in the next few versions.

🔌 Plugins & Integrations roundup

• Humanitec plugin: we now expose the Humanitec plugin, so you can view deployment information insider Roadie. Fun.
• Coder plugin: speaking of plugins, we also integrated the new Coder plugin. Tying neatly together Humanitec and Coder, Humanitec recently ran a webinar on how Coder thinks about integrating into Backstage which is worth checking out.
• AWS tag-based relationships: last but not least, on the topic of catalog data sources this time rather than plugins - we now ingest AWS tags as part of AWS automatic resource discovery. You can use tags to build relationships between newly ingested AWS resources and other entities in the catalog. Neat.

🗂️ Customising the Catalog UI

Your Catalog should match how you organise teams and build software. In the past, you've had to use Backstage nomenclature to model those concepts in the Catalog, but no more.

We've introduced Catalog Customisation in the Admin area so you can use your own naming conventions and concepts to define your Catalog using Kinds and Types and simplify the UI for everyone.

Add, edit, and reorder Catalog tabs to your hearts content.

Docs can be found here on how to get started.

💈 Sidebar slimming

In the same vein, we have also opened up support for full customisation of the sidebar.

This was possible in a limited capacity in the past, but you can now modify the whole kit and caboodle. This applies across your instance of Roadie for all users, allowing Admins to slim down the sidebar and reduce information overhead for everyone.

🌅 Surfacing metadata

We've also making customisation easier by introducing a EntityMetadataCard. The new card allows you to pull in any metadata you'd like from a catalog-info.yaml file and surface it on an Entity page. This allows you to pull in rich information on things like ownership or the last time an entity was updated, without the effort of writing a custom Typescript plugin to do the same job.

🌈 New default fonts, padding and colours

You may also have noticed Roadie has had a general facelift. This is part of our efforts to make it easier for users to consume visual information on any given Roadie page. This will be a long-running piece of work for us, but expect Roadie to just look and feel nicer in the weeks and months to come.

🙌 Filters for all!

We've also added Advanced Filters to all Catalog Kinds. This allows you to create a filtered, linkable views to share with colleagues. It has previously been possible to use Advanced Filters for a number of different Catalog Kinds, but now it's available for all.

Happy filtering :)

🔌 Plugin roundup

We've added a new Dynatrace plugin. This is the best plugin for customers of hosted Dynatrace services. You can also access the Dynatrace plugin for self-managed users, which has been renamed Dynatrace for Managed in line with Dynatrace naming conventions.

This is part of our efforts to more closely sync up with plugin maintainers like Dynatrace to make sure Roadie customer feedback reaches them. Their plugins get better, Roadie gets better, you get a better service from both. Win, win, win. 🤝

🤖 Custom Scaffolder Actions.

Templates and the Scaffolder get heavily used by our customers to democratise common tasks like adjusting cloud account budgets or making changes to some Terraform repos.

One of the historic limitations with the Roadie Scaffolder has been that customers were unable to create and use their own custom actions. This added some friction for more advanced Scaffolder users where they were limited by the Scaffolder Actions that we supported by us when they came to write a Template.

No more though! Roadie customers can now create their own self-hosted Custom Scaffolder Actions.

That means:

1. You can now write your own Scaffolder Actions to complete a task or use some custom CLI that Roadie isn't aware of
2. Then register those Actions in Roadie - as many as your heart desires.
3. Context can then be passed back and forth between Roadie and these Actions within any template you write.

Detailed docs can be found here to get started.

⽥ Custom Field Extensions

In the same vein, we have also opened up support for Custom Field Extensions for the Scaffolder.

You can write your own React Components and validator functions to handle the use cases not currently covered by the existing Templates. This allows you to customise a lot of the Scaffolder forms to your hearts content.

🔌 Plugin roundup

• The Dynatrace plugin is now supported on Roadie. You can use it to surface recent problems, error traces, and synthetics results for your services.

• The PagerDuty plugin has had a significant upgrade thanks to the fine work Tiago Barbosa is doing as part of PagerDuty taking maintainership of the plugin earlier this year. We've adopted the new plugin, so you'll see a slick new UI and some additional features as they rollout.

🤖 [Beta] Repositories have come to the Catalog.

We think a lot about catalog completeness at Roadie.

One of the most successful strategies we've come across to aid in getting components into the catalog is to surface what is in the catalog against a list of repositories. The gap between the two help to identify what is not in the catalog. Simple.

To help customers do this as easily as possible we've brought Repositories in from the cold and added them as a core part of the Catalog.

That means:

1. There is a new Repository tab in the Catalog
2. Repositories are auto-discovered for GitHub users. For other SCMs the Roadie API is available to push your repositories in.
3. Quick editing of Repositories inside the Catalog table itself.

📝 Set owners and other properties in the Catalog table UI (no yaml required)

We’ve expanded Decorators again to allow editing of Title, Owner, Type and Lifecycle for Catalog entities from the Catalog table itself.

You can now edit the title, owner, type and lifecycle of entities right in the Catalog table UI. All without yaml. Just click the pencil icon in the Actions section of whatever row you'd like to edit.

⛏️ [Beta] Auto-discover AWS Resources with our new provider

Our customers often want to represent AWS resources in the Catalog and have been using the Roadie API to do just that. There's a simpler way though, so we decided to build it. Behold: the Roadie <> AWS Provider.

It can currently be configured to pull in:

• Lambda functions
• EKS clusters
• S3 buckets
• DynamoDB tables
• EC2 instances
• and RDS DBs

Coming soon: AWS Accounts.

⏫ Upgrade to Backstage 1.23

We’ve upgraded Backstage to 1.23 for all customers:

• A fix to a vulnerability identified by us as part of our annual third-party penetration test. It related to the Scaffolder and didn't actually affect us, but we worked on fixing it with the core Spotify team to keep the rest of the community safe. More info here.
• A tweak to Nunchucks trimblocks that allows for creating control over templating in the Scaffolder, worked on by our own Miklos, one of the core Roadie team.

Full release notes for Backstage 1.23.

🔌 Plugin roundup

• The newEnd of Life plugin is now supported on Roadie. We've bought in both the frontend and the backend for this plugin, so it is able to read from repository files via the "source-location" annotation. It’s nice. We like it.

🤖 The Roadie API is now live for all users on our Growth Plan.

It includes:

1. The Backstage catalog API exposed, via token authentication for Roadie customers.
2. A scaffolder API for testing templates in continuous integration (via dry-run), triggering templates, and listing historical scaffolder runs.
3. A **Tech Insights API** that allows you to create, read, update and delete scorecards, checks and data sources.

At the moment API token generation is limited to Admins. If you are an Admin and need a token, simply navigate to Administration (bottom of the sidebar) and Account (in the tabs across the top). Give your token a name and click Generate Token.

🎨 More Decorators: you can now set owners and other properties in the Roadie UI (no yaml required)

We’ve expanded Decorators to allow setting many more fields on the Entities in your catalog.

• You can now override the owner, lifecycle and tags of Components right in the Roadie UI.
• Groups and all other Entity Kinds have also been expanded so that more properties can be set.

All without yaml. Just use the Decorate Entity feature in the top left corner of each Component page. Simple.

💯 Scorecards in the Catalog

How to surface scorecard information to teams is something we think a lot about at Roadie. A few months ago we added Rollups to help. This month we launched Scorecards in the Catalog to increase visibility and discoverability for teams. This is something with a long history (the original discussion in the Backstage community was way back in September 2020) and it's something we're hyped about.

🙅‍♂️ Tech Insights gets exclusions (in beta) and a new Facts list

We’re currently beta testing the ability to exclude entities from a Tech Insights scorecard and a check. This will give fine-grain control over the checks and scorecards you can create and pinpoint areas of your catalog.

We’ve also added a Facts list under the Data tab in Tech Insights to improve discovery of what you can and can’t do with Tech Insights data sources.

⏫ Upgrade to Backstage 1.21

We’ve upgraded Backstage to 1.21 for all customers. The biggest change since the last update at the end of 2023 is the new scaffolder UI with horizontal paging.

The upgrade to 1.21 also fixes a small but annoying bug that was pointed out by some customers: the scroll position of TechDocs pages now returns to the top when you navigate between different docs.

Our next version bump will be to 1.23 when that lands (hopefully later this month).

🔌 Plugin roundup

• The newPagerDuty plugin is now supported. PagerDuty took over support for the plugin in January, deprecated the old plugin and launched their own version. It’s nice. We like it.
• The Pulumi plugin is now supported. With it, you can bring infrastructure data associated with your Pulumi stack into Backstage.
• The Cost Insights plugin now has beta support. If you're interested reach out to one of the Roadie team on Slack, Discord or Teams.

Tech Insights

Rollups

Rollups aggregate Scorecard and Check data by team and department, up and down your organisational hierarchy, and let you add scorecard information to teams in the catalog. Learn more below in the Tech Insights section.

Here’s an example for a team called “engineering”.

From this, we can see that the engineering team is doing a great job of using PagerDuty correctly, but could do better at Dependabot configuration. If there are other teams reporting to this one in the org chart then their data will be rolled up into this view also.

Add the ScorecardResultForGroup and ScorecardResultsTableForGroup Cards to Group layouts to see results like this.

You can also see this data presented in report format on a single Scorecard, and dive into the data at different levels in the org.

Bug fixes and improvements

This month has been packed with improvements.

• We’ve got a built-in Data Source that scans for errors in CODEOWNERS files.
• We’ve got a built-in Data Source that ensures your branch protection is correct.
• The built-in Snyk Data Source has been updated to use the github.com/project-slug where possible.
• We fixed some rounding errors in our Check calculations.
• We fixed a labelling issue where there were two inputs called Type on the New Check form.
• We fixed a bug where regex comparison results were exporting incorrectly.
• We fixed a bug where selected annotations or labels in the filters of Scorecards couldn’t be deselected.
• Improved the performance of Data Sources which iterate over repos containing hundreds of thousands of files.
• The “is not blank” operator used to incorrectly ask for a value. Now it doesn’t.
• We had mislabeled the “Number” type as “Integer”. This is fixed.
• Markdown is now supported in Check descriptions so you can link to supporting documentation.
• The Proxy input is now a typeahead so it’s easier to find your favorite proxy.
• Scorecard rings now calculate in a more accurate way. A Component used to have to pass all checks on a scorecard to be counted in the ring. Now all checks that are passed will contribute to the score.
• We brought consistency and sanity to the positioning of the Re-run, Recalculate and Refresh buttons on Scorecards, Checks and Data Sources.
• Fixed some bugs which would prevent scorecards from showing up in the catalog in some cases.
• GitHub based Data Sources now filter out archived repos.
• Improved a bunch of help text sections on the New Data Source page.

Catalog

Decorators

Decorators allow you to easily add metadata to the stuff you track in your Roadie Backstage catalog. Check out the blog post for full details and to learn how to use them. One simple use case is to use decorators to add a Team Charter and some links to groups in the catalog.

Bug fixes and improvements

• API specs are now searchable. Start your endpoint searches with a forward slash.
• Renamed “Create…” in the sidebar to Templates. “Create…” was ambiguous.
• We removed Tools from the sidebar and moved its pages into Administration.
• The card used for displaying Links now hides itself from the interface when there are no links.
• Catalog table column visibility is now independently set for each Kind of Entity.
• Catalog tables can now display a links column.
• Entity Titles are now displayed in the catalog table instead of name when possible.
• Admins can now change the sidebar color in the Theme settings.
• We improved the Locations Log and renamed it to Administration → Entity Locations. You can also find it in the tabs of the Import page.

An Internal Developer Portal is as good as it tackles your teams’ unique challenges. While Roadie comes with dozens of integrations—such as PagerDuty, ArgoCD, and Sentry— your teams most likely rely on custom workflows, private systems, or in-house tools as part of their software development life cycle. Bringing those specific requirements into your Developer Portal can streamline your developer experience significantly.

For example, Lunar Bank built a dead-letter management plugin, while American Airlines centralized their permissions requests through a custom section of their Backstage instance.

Roadie offers tools to simplify the development and deployment of your custom plugins.

Getting Started scaffolder template

Register Roadie’s New Custom Plugin scaffolder template to jump-start your plugin development. The template will ask you a few details about your plugin and then create a new repository with a basic plugin structure and sample code.

Dev previews within your instance

Once you have your custom plugin running on your machine, you can get a live preview right within your Roadie instance. Your instance will automatically be updated with any code changes which will be applied when you refresh the page.

When writing a custom plugin for Roadie, you can use APIs provided as React hooks so you don’t have to deal with async requests or authentication at the plugin level.

You can preview all your plugin’s views within Roadie: pages, widgets, and cards. Furthermore, you can rely on preview entities to help you develop faster.

Deploying custom plugins to Roadie

Using the Roadie CLI, you can build and deploy your Backstage plugins and see them in your instance within a few seconds after you push them upstream. The simplest option for deployment is to let Roadie host your plugin, but you can also deploy your plugin to other services like Netlify or GitHub Pages.

How to use Decorators

Using Decorators is simple:

1. Visit an Entity in your Roadie Backstage catalog (e.g. a team, service or system).
2. Click the three dots in the top right corner and click “Decorate entity”.
3. Add links or annotations to the Entity and press Save.

Decorators you create are stored inside Roadie and not written back to the YAML file that backs the Entity.

This means that Entity metadata can come from multiple places for the same Entity. One annotation could come from YAML, and another from Decorators.

You can see where a specific piece of metadata is backed off to by clicking the three dots again and clicking “Inspect entity”. In this case below, the backstage.io/source-location is internal to Backstage and the other items are applied by Roadie Decorators.

Why we’re doing this

The introduction of Decorators is a slight deviation from the Backstage way of doing things, so it’s important that we explain why we’re doing this.

Auto-ingested sources need decoration

Backstage implementations frequently source the hierarchy of Users and Groups from a tool like GitHub Teams, Okta, or a Human Resources application like BambooHR. To support this, Backstage has a number of integrations into these tools.

These integrations will typically stream the hierarchy of Users and Groups into the Backstage catalog.

The problem with automatically ingesting Users and Groups is that Backstage users don’t get a chance to enrich their Group with information like links to Slack channels or a team charter. This leads to dead looking Group pages in Backstage.

Decorators give Backstage users a way to enrich their Group with the information that they want to show-off.

What this is not

We’re not introducing anything brand new in the Backstage ecosystem and we’re not introducing vendor lock-in.

There’s precedent

Backstage itself adds internal annotations to each Entity. These annotations are not written back to the YAML files. They are instead stored inside the Backstage database.

You can see some examples of this internal metadata here:

Roadie is simply piggybacking on this mechanism, to add the ability to store links and annotations.

We’re Backstage API compatible

We’re not introducing any Roadie-specific changes to the Backstage API or the spec for Backstage YAML files. We’re just making it easier to add values to the existing spec.

Entity Decorations are available via the standard Backstage HTTP API that we expose, so you can always write them back to YAML if you wish.

In the future, we will look to support “exporting” Decorators into any YAML file that backs the entity.

Catalog

New catalog page preview

You will shortly see a new catalog page roll out on Roadie. This update affects the main software catalog table, and the filters around it.

This new catalog table brings a number of enhancements:

1. More horizontal space for reading the table. We’ve moved the filters to the top so the table is wider.
2. Per user configurable columns. You can customize the table to show the info that’s important to you. We’ll soon be persisting column choice in your browser so you can pick up where you left off (this is coming imminently).
3. Kind specific columns. Groups used to have an owner column and Users were missing Display Name. We’ve tidied these up and introduced more sensible defaults.
4. New table features. Configurable densities and full screen mode make for slicker presentation. Filter highlights make it easier to find what you’re looking for.
5. Persisted filter choices. If you mostly work with Templates, we’ll keep you on the template page when you navigate away and back.
6. Sharable filter choices. Filters will be in the URL so you can share a link to a specific subset of data.

All this is building up to the ability to bring Tech Insights data front and centre in the catalog. We want to show scorecards in a column so you can drive more action around important migrations and software quality issues. More on this in the coming weeks and months.

Fixed: Disappearing Azure repos entities

We spent 3 weeks tracking down and fixing a tricky bug that would cause Entities discovered from Azure Repos to periodically and temporarily disappear from the catalog.

This is demonstrated by the wigglyness of the entities count before the fix, compared to how flat it is after.

It turns out the Azure APIs don’t return consistent results unless a sort is specified on the queries. Here’s the upstream fix we made to Backstage.

This is a really good example of the value Roadie adds. Are bugs like this how you want your Developer Experience team spending their time?

Tech Insights

Group check data by owner

Check results are now grouped by owner as well as by Component. This makes it easier to track down the team who own the most Components which are failing the check.

We’re currently working to expand this to scorecards, and to aggregate the data up and down the hierarchy of teams, so you can view it at any level.

New tutorials

We added 4 Tech Insights tutorials this month. Learn how to…

1. Find software that doesn’t have a valid CODEOWNERS file.
2. Find software that doesn’t have branch protection enabled.
3. Connect Tech Insights to SonarCloud to collect security hotspot data.
4. Connect Tech Insights to an on-prem SonarQube instance.

Bug fixes and improvements

• We fixed a bug where some Data Sources would fail with an Out of Memory error.
• We now support the YAML content type response when sending HTTP requests in Data Sources.
• Data Sources can now send POST requests for GraphQL APIs and other use cases.
• We rolled out a new version of our broker to patch a security vulnerability.

Scaffolder

Certified label for scaffolder templates

You can now add the Certified label to scaffolder templates to designate them as Platform Team approved and ready for use.

Just add the certified annotation to make this work.

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: my-template
  annotations:
    roadie.io/certified: "true"

Bug fixes and improvements

• The scaffolder now supports a task to open a pull request against Azure repos.
• We updated our scaffolder docs page to include more examples and APIs.