The closing episode of the series: Backstage 2026 features such as the default New Frontend System and MCP integration for AI agents, comparing Backstage with Port, Cortex, Humanitec, OpsLevel, Kratix, and commercial IDPs, a recap of the journey from episodes 0-21, plus a production-grade checklist and the future of platform engineering.

Episode 21 brought Backstage to production and set up adoption. Episode 22 is the final episode of the Learn Backstage series — and at the same time a window into the future. You'll see Backstage's modern features in 2026, compare them with alternatives in the IDP market, recap the whole journey from episodes 0 to 21, and close with a production-grade checklist plus a look at the future of platform engineering.
In episode 17 you met the New Frontend System. Since 2026, this system has become the default in Backstage: frontend plugins are built with createFrontendPlugin, extension points, and dependency injection as the standard patterns. The experience for plugin developers is now uniform and easier to learn.
The Backstage frontend keeps being modernized. The migration to React 19 brings a more efficient rendering model, while the TypeScript codebase is updated to use the latest language features. For you, this means the plugin code you write today aligns with the direction of future development.
One of the most interesting features in 2026 is MCP (Model Context Protocol) integration. Backstage now provides an MCP server that lets AI agents talk to the platform over the Streamable HTTP protocol. Through MCP, an AI agent can:
The MCP server exposes actions registered in the backend, so agents can use the platform's capabilities without opening a manual interface. On the client side, server registration is done through ordinary MCP configuration:
{
"mcpServers": {
"backstage-actions": {
"url": "http://backstage.example.com/api/mcp-actions/v1",
"headers": {
"Authorization": "Bearer ${MCP_TOKEN}"
}
}
}
}@backstage/backend-plugin-api remains the basis for development, and MCP opens the door to new workflows — developers can create services through natural language commands, and agents can navigate the catalog without a manual interface.
Backstage's catalog model isn't rigid. You can define custom kinds, add processors to ingest new data sources, and build relations between entities that fit your organization's domain. This extensibility keeps the catalog relevant even as the organization grows and changes.
Inspired by DORA metrics, Four Keys measures software delivery performance through four numbers. By combining analytics events (episode 20) with CI/CD data, Backstage helps teams see whether process improvements are actually working.
| DORA Metric | Question It Answers |
|---|---|
| Deployment frequency | How often changes are shipped to production |
| Lead time for changes | How long from commit to production |
| Change failure rate | How many deployments fail |
| Time to restore | How quickly recovery happens after a failure |
Backstage isn't the only player. Understanding the comparison helps you make the right decision:
| Product | Model | Main Strength |
|---|---|---|
| Backstage | Open-source, self-hosted, CNCF | Flexible, plugin ecosystem, no lock-in |
| Port | SaaS IDP | Fast onboarding, no-code, built-in scorecards |
| Cortex | SaaS | Scorecards, SLOs, service quality |
| Humanitec | Platform orchestration | Golden paths and resource management |
| OpsLevel | SaaS | Software maturity and scorecards |
| Kratix | Platform orchestration, Kubernetes-native | Promise-based, GitOps, highly customizable |
| Commercial IDP | SaaS, turnkey | Fast time-to-value, vendor-managed |
Backstage wins when an organization wants control and flexibility: a large plugin ecosystem, deep customization possibilities, and no vendor lock-in. It's best suited to organizations that have a platform team capable of maintaining and adapting the platform themselves.
A SaaS IDP becomes more attractive when speed is everything — a small team wants a portal running fast, without the burden of maintaining the catalog and upgrades. This decision isn't about right or wrong, but about team capacity and long-term needs.
Tip
If your platform team is small and your needs are standard, start with SaaS. If you have a team that can invest and you need deep customization, Backstage gives you the most control. The decision can change as the organization grows.
Let's pause and look back. Across 22 episodes you built a complete understanding of Backstage:
From the first catalog to a platform serving thousands of engineers — all the pieces connect into one system.
As a technical close, here's a checklist that brings together the entire series:
backstage-cli versions:bump run regularly, and staging tests before production.A platform that meets this checklist is ready to be relied on by the organization.
Platform engineering is becoming a core practice in many organizations: the platform is no longer a collection of tools, but a product with users and a roadmap. The direction is clear — increasingly automated golden paths, an increasingly living catalog, and the presence of AI agents using the platform through MCP. Backstage, with its open-source ecosystem, sits at the center of this shift.
Episode 22 closes the Learn Backstage series. You've completed a full journey from episodes 0 to 21: foundations and architecture, the software catalog, scaffolder, TechDocs, authentication and RBAC, secrets, search, frontend and backend plugin development, scaling, observability, production deployment, and adoption strategies. In this final episode, you also got to know Backstage's modern 2026 ecosystem and how to position it among IDP alternatives.
The key takeaways:
Thank you for following the entire series. The skills you've built — understanding, customizing, and operating a developer portal — are a solid foundation for continuing in devops and other platform engineering topics. Your journey in the platform world doesn't stop here; I hope this material serves as a stepping stone to explore the next practices. Happy building your own platform!