Backstage Build vs Buy: The Real Cost of Running Your Own IDP

Service sprawl is the problem leaders reach for Backstage to solve: dozens or hundreds of services, and nobody can say what runs where or who owns it. The trap is that the tool demos as a quick install, so the budget gets written against the install and misses what keeps it alive. Backstage is a framework you staff, not a product you buy, and the real recurring line item is a standing platform team. The decision that follows is whether to run Backstage yourself or adopt a hosted internal developer platform; without a funded platform team already in place, hosted is the default.

If you are still weighing whether you need an internal developer platform at all, the broader category is covered in the internal developer platform guide. With the IDP decision already made, the narrower, sharper question is Backstage specifically: build or buy.

What Backstage Actually Is

Backstage is an open source framework for building developer portals. It originated at Spotify and was donated to the Cloud Native Computing Foundation, where it is a CNCF project. The word that matters in that sentence is “framework.” There is no finished portal to log into; Backstage hands you a scaffold, and the assembly work is yours.

Out of the box it ships four capabilities.

The Software Catalog is the centerpiece: a centralized system that tracks ownership and metadata for all the software in your ecosystem, from microservices and libraries to data pipelines and machine learning models. Software Templates, driven by the Scaffolder, let teams spin up new projects with your organization’s best practices baked in; this is the golden-paths mechanism. TechDocs is a docs-like-code solution where engineers write Markdown that lives next to the code it describes. The plugin ecosystem is a growing set of open source extensions that connect Backstage to the rest of your tooling. Each of the four is a capability your team operates and maintains.

Why Teams Pull It In

The appeal is real, and it maps directly onto the sprawl problem. When every service, API, and pipeline is registered in one catalog with a named owner, the question “who owns this and where does it run” has an answer. Templates turn the right way to start a new service into the default way, so standards spread because the easy path is the sanctioned one. And docs, ownership, and pipelines stop being scattered across wikis and dashboards; a new engineer gets pointed at one place on day one.

These are genuine wins, and they are why Backstage became the reference point for the whole category.

The Part Nobody Budgets For

The install genuinely is fast. The getting-started docs walk you through a single command that scaffolds a running application in minutes. That speed is exactly what sets the trap, because the same getting-started page also lists the footprint: a Unix-based operating system, an active Node LTS, and a baseline of at least 20 GB of disk and 6 GB of memory for the standalone app with demo data, increasing as you add plugins. The bootstrap is the cheap part. Everything underneath it is the standing surface a team owns for as long as the portal exists.

A useful way to hold this is a rough 10/90 frame: the install is maybe 10 percent of the work, and the ownership surface is the other 90 percent. That split is a rhetorical frame; nobody has measured it as a statistic. What it points at is concrete.

Each branch on the right is a recurring obligation that outlives the setup.

Surface	One-time install (~10%)	Ongoing ownership (~90%)
Bootstrap	The create-app command scaffolds a running app in minutes.	Done once.
Hosting and infra	Nothing extra to buy on day one.	Self-hosted by default: you run a frontend, a backend, and a database on a baseline that grows as plugins are added.
Auth, SSO and RBAC	Not wired by the scaffold.	Auth providers and the permission framework are configured and maintained by your team.
Catalog hygiene	Empty catalog at start.	Keeping ownership entries accurate is organizational discipline; no feature maintains it for you.
Plugin upkeep	Default plugins installed.	Backstage ships a new main release every month. It does not follow semantic versioning, and each new minor version can contain breaking changes, so upgrades are a standing chore.
TechDocs pipeline	One demo doc renders.	A documentation build pipeline that someone owns and operates.
Portal on-call	Runs on your laptop.	In production the portal is itself a service with uptime, upgrades, and on-call.

The plugin row deserves emphasis because it is the one most often underestimated. The release cadence is monthly, and the project is explicit that minor versions can carry breaking changes. Upgrades become a steady upkeep tax on a team that has to keep pace or fall behind; there is no once-a-year migration window to plan around.

The Knowledge Layer

Two of the four capabilities deserve a closer look, because together they turn the portal into a knowledge system.

The Software Catalog is a single source of truth for who owns what: a centralized system that tracks ownership and metadata for all the software in your ecosystem. Each entity is described by a small descriptor file that lives next to the code, so ownership travels with the service instead of decaying in a separate registry. The value to a leader is that the catalog answers ownership questions during an incident without a Slack archaeology session, provided the entries are kept honest.

TechDocs is documentation-as-code. Engineers write Markdown that ships in the same pull request as the code, and the docs surface on a service’s catalog page with full-text search. Documentation stops rotting in a wiki disconnected from the code it describes, because it now moves at the same speed as the code.

The Zalando Benchmark

Zalando runs one of the most cited Backstage deployments: Sunrise, a developer platform built on top of Backstage since 2021 with extensions developed internally. It is operated by a dedicated team named Builder Portal that has, in their words, “been operating and evolving the platform since its inception.”

The scale numbers double as evidence for the catalog-hygiene point. Zalando reports “over 40k registered entities (between applications, teams, and users) which we sync daily with the respective source of truth services.” The catalog stays true because a daily synchronization pipeline reconciles it against systems of record. On top of the base framework, the team integrated 27 other tools and services through 30 front-end plugins, and contributed some work back to open source, including their Zally API Linter plugin.

Here is the part a leader has to read carefully. Sunrise is heavily customized at Zalando’s scale, and most of what makes it impressive is exactly what a normal organization cannot copy cheaply.

The patterns on the left are portable to a team of any size. The investments on the right are a function of headcount and scale.

Build vs Buy

The buy side is a genuine market, and the most telling fact about it is that Spotify, the origin of Backstage, sells the managed answer. Spotify Portal for Backstage markets itself as the fastest way to get started, with “No coding required” and an onboarding wizard for no-code setup, under a tagline that concedes the whole cost argument: “Spend time using your portal instead of maintaining it.” Alongside it sit hosted internal developer platforms such as Port, Cortex, and OpsLevel that compete on the same promise: you do not run the platform yourself.

The hosted category as a whole trades the same way. You give up deep customization and accept a subscription and some vendor lock-in; in return the vendor absorbs hosting, upgrades, and the upkeep treadmill, and you start in days rather than staffing a team. DIY Backstage gives you full control and the entire open plugin ecosystem; the price is the standing platform team and the monthly non-semver upgrade cadence the table above describes.

DIY wins in exactly one shape, and it is the Zalando shape.

The branch to DIY Backstage only resolves when all four conditions hold: an existing funded platform team, budget for a standing team in the Builder Portal mold, customization needs a hosted vendor cannot meet, and scale measured in many teams and thousands of entities. Any single “no” routes back to a hosted IDP. If a funded platform org is already in place, owning the framework buys control that org will actually use; the free license is the smallest line in that budget.

Where DIY Adoptions Stall

The quiet killer is a stale catalog. It destroys trust faster than no catalog at all, because people stop believing the ownership data and go back to asking in Slack; Zalando syncs 40k entities daily precisely to keep that from happening.

The louder failures are copying and scheduling. Copying Zalando’s 30-plugin customization depth without Zalando’s headcount produces a portal nobody can maintain. Budgeting upgrades as an annual event collides with a monthly cadence in which minor versions can carry breaking changes; deferring the work only grows the eventual jump.

Cost the Team Before the Tool

For most small-to-medium organizations this decision lands on hosted, because the standing team is exactly the cost a vendor takes on. The override case is narrow; the decision tree above spells out its gates, and Zalando shows what living on that branch costs.

One question measures readiness: who owns the portal’s on-call rotation a year from now? If no name comes to mind, you are not ready to run Backstage yourself.

References

• What is Backstage? - Official overview defining Backstage as a framework for building developer portals and its four out-of-the-box capabilities.
• Backstage Software Catalog - The ownership and metadata source of truth, including the descriptor model for entities.
• Backstage TechDocs - Docs-like-code: Markdown alongside the code, catalog-integrated discovery, and full-text search.
• Backstage Software Templates - The Scaffolder and golden-paths mechanism for standardizing new projects.
• Backstage Release and Versioning Policy - The monthly cadence and the statement that minor versions can contain breaking changes.
• Backstage Getting Started - The create-app command and the baseline disk and memory footprint that grows with plugins.
• CNCF: Backstage project - Project status and maturity as a CNCF project donated by Spotify.
• Sunrise: Zalando’s Developer Platform Based on Backstage - The worked case study: 40k entities synced daily, the Builder Portal team, and 27 tools across 30 plugins.
• Sunrise: Zalando’s Internal Developer Platform (talk) - Companion conference talk and recording on the same platform.
• Spotify Portal for Backstage - The commercial managed Backstage offering, source of the “spend time using your portal instead of maintaining it” tagline.
• Port - A hosted, commercial internal developer platform on the buy side of the decision.
• Cortex - A commercial internal developer platform competing on managed, no-maintenance operation.
• OpsLevel - A commercial internal developer platform in the hosted IDP category.