Backstage vs Off-the-Shelf IDP: Infrastructure Complexity, Cost, and Time-to-Value
What Backstage actually is, what it costs to run in production, and where off-the-shelf IDPs make more engineering sense
Backstage gets evaluated as a cost-saving decision. No licensing fees, open source, backed by Spotify and the CNCF. On paper, it looks like the responsible choice.
The problem shows up later. Usually around month six, when the team that was supposed to be building developer tooling is instead maintaining a TypeScript application, chasing plugin compatibility, and managing Kubernetes upgrades for the portal itself.
This post breaks down what Backstage actually is, what it takes to run it in production, and where off-the-shelf IDPs make more engineering sense. No vendor bias. Just the trade-offs as they actually play out.
TL;DR
Backstage is a developer portal framework, not a complete internal developer platform. It catalogs your infrastructure. It does not provision it.
Running Backstage in production requires 3-5 dedicated engineers, frontend skills most platform teams don’t have, and ongoing plugin maintenance that compounds over time.
The “free” label applies to licensing only. Engineering time, upgrade cycles, and opportunity cost are where the real spend accumulates.
Off-the-shelf IDPs handle the infrastructure layer Backstage assumes is already solved: environment provisioning, CI/CD, observability, secrets, and networking.
The right choice depends on your team size, existing platform maturity, and whether you have the engineering capacity to treat a portal as an internal product.
Understanding Backstage
Spotify built Backstage in 2020 to solve a specific problem: 2,000 engineers, hundreds of microservices, no single place to find who owned what or how to spin up a new service consistently. They open sourced it, donated it to the CNCF, and called it an open source internal developer platform framework.
That last word matters. Framework.
Out of the box, Backstage gives you:
A service catalog for tracking ownership and metadata across services
Software templates for scaffolding new services consistently
TechDocs for internal documentation
A plugin architecture for connecting external tools like GitHub, PagerDuty, and Kubernetes dashboards
What it does not do:
Provision infrastructure or cloud environments
Manage CI/CD pipelines
Handle secrets rotation or environment isolation
Set up observability or networking
Those systems need to exist independently before Backstage has anything useful to catalog.
Most teams miss this. They come in looking for an internal developer platform that reduces DevOps bottlenecks and speeds up environment provisioning. Backstage solves neither. It solves discoverability and standardization at the service layer, which is a real problem, but only after the platform layer is already working.
Evaluating Backstage without understanding that scope is how teams end up 12 months in, having built a catalog nobody uses, still waiting on DevOps for environments.
Baseline Infrastructure Needed to Operate Backstage
Backstage is a Node.js backend with a React frontend backed by PostgreSQL. Before it can serve a single request in production, your team needs to provision and maintain the following:
Hosting and compute:
A Kubernetes deployment for the Backstage app and its backend services
PostgreSQL instance for the catalog — SQLite is dev-only and not supported in production
Ingress controller with TLS termination for internal network access
Container registry and a CI pipeline to build, tag, and ship Backstage image updates on every release
Authentication:
SSO integration with your identity provider — Okta, Google Workspace, or GitHub OAuth
RBAC configuration per team and service boundary
Per-plugin auth wiring, since most plugins manage their own token or OAuth flow independently
Ongoing operational surface:
Backstage ships monthly releases, several with breaking changes to the plugin API
Each plugin has its own version compatibility matrix that breaks independently of core
The New Backend System migration in 2024 required significant refactoring across all self-hosted deployments
Security patches have no vendor SLA — internal triage owns the timeline
This is the baseline. Custom plugins, catalog ingestion pipelines, and scaffolding templates sit on top of all of this.
The Real Cost of Running Backstage
Backstage has no licensing fee. That is the only part of the cost equation that is actually zero.
Everything else shows up in engineering time, not a software invoice. That is the core trade-off with any open source internal developer platform: the software is free, the operational ownership is not.
Engineering headcount:
Community-reported data from vendors like Roadie and platform teams suggests that successful self-hosted Backstage deployments typically require a dedicated platform team. In many cases, that means 2–4 engineers maintaining and evolving the portal, with larger organizations investing significantly more.
At a median US senior engineer cost of around $150K–$180K per year, even a small team represents a $300K–$700K annual investment, before infrastructure or opportunity cost.
Skill requirements:
Backstage requires TypeScript and React expertise for meaningful customization
Many platform teams are backend or infrastructure-focused
Teams either hire for it, reassign product engineers, or accept limited extensibility
Ongoing maintenance:
Frequent releases, including breaking changes, require active upgrade work
Plugin compatibility issues are common in larger deployments
No vendor SLA means incidents and bugs are handled internally
The adoption problem:
Adoption is not guaranteed. Many teams report low internal usage when Backstage is introduced without strong platform workflows behind it. A well-designed catalog does not create value on its own. If developers still depend on manual processes for provisioning and deployment, the portal becomes an additional layer rather than a productivity gain.
What an Off-the-Shelf IDP Actually Handles
Internal developer platform architecture is built around one core responsibility: provisioning and managing the infrastructure your engineers deploy into, not cataloging what already exists.
A production-grade IDP typically handles:
Infrastructure provisioning:
VPC, subnets, and network isolation per environment
Managed Kubernetes cluster provisioning and configuration
Cloud resource provisioning — RDS, S3, ElastiCache, SQS — without manual Terraform
Developer workflows:
Push-to-deploy from a connected Git repository
Per-branch or per-environment CI/CD pipeline automation
Preview environments on pull requests
Observability:
Pre-configured Prometheus, Grafana, and Loki per environment
Logs and metrics available without manual instrumentation
Alerting to Slack or equivalent out of the box
Security defaults:
Encrypted volumes and secrets storage
Role-based access control across environments
Auto-renewing TLS certificates
The key difference from Backstage: none of this requires the engineering team to write Dockerfiles, Helm charts, or Terraform modules.
Here’s how LocalOps provisions each environment
Backstage vs IDP: Architecture and Approach
The architectural difference between Backstage and a modern IDP is which layer of the stack each one owns.
Backstage operates at the portal layer. It consumes APIs, aggregates metadata, and presents a unified UI over infrastructure that already exists. A modern IDP operates at the platform layer. It provisions and manages that infrastructure directly.
The two are not direct competitors. Organizations running Backstage at scale typically pair it with a separate platform layer — Humanitec, Crossplane, or custom Terraform modules — to handle infrastructure provisioning. That works, but it means owning and maintaining two separate systems. A IDP consolidates this by providing and standardizing the platform layer as part of the product.
See how LocalOps structures a production environment
Backstage vs IDP: Total Cost of Ownership
The licensing comparison is straightforward. Backstage has no licensing cost. Most commercial IDPs charge a subscription, often based on users or usage. That is where the simplicity ends.
According to Roadie’s 2025 State of Backstage Report, 70% of companies that are “very happy” with Backstage dedicate at least three full-time engineers to maintaining it. At $180,000 median US senior engineer compensation, that is $540,000 per year in headcount alone, before infrastructure, upgrade cycles, and opportunity cost.
A commercial IDP subscription for a 30-person engineering team typically runs well under $20,000 per year. The gap between those two numbers is where the real TCO conversation starts.
Time-to-Value: Deployment and Adoption
Time-to-value is where the gap between self-hosted and off-the-shelf solutions becomes most visible.
Getting Backstage to the point where a new engineer can push code and see it deployed typically takes months. Most off-the-shelf IDPs reduce this to hours or days, depending on environment complexity.
The faster a platform delivers value, the more likely it is to be adopted. Slow setup cycles increase the risk that internal platforms stall before developers rely on them.
When Backstage Can Actually Work
Backstage is not the wrong tool. It is the wrong tool for certain team sizes and maturity levels.
It works well when:
Your engineering org has 100+ engineers with a dedicated platform team of at least 3 people
You already have working infrastructure automation — Terraform modules, CI/CD pipelines, environment provisioning — and need a catalog layer on top
You have TypeScript proficiency on your platform team and can treat Backstage as an internal product with a dedicated roadmap
Your primary problem is service discoverability, ownership tracking, and documentation consistency across a large, distributed engineering organization
If all four of those conditions are true, Backstage is a reasonable choice. If two or more are missing, the operational overhead will outpace the value delivered.
When to Choose a Modern IDP
A modern off-the-shelf IDP makes more sense when:
Your team is under 100 engineers and does not have a dedicated platform function
Environment provisioning, CI/CD, and observability are not yet standardized across your stack
You need developers deploying to production within days, not months
You are running on AWS and want production-grade environments without writing Terraform, Helm charts, or Dockerfiles
Your platform engineers should be working on developer experience, not maintaining portal infrastructure
You have evaluated Backstage and concluded the operational overhead exceeds your current capacity to absorb it
The core question is not which tool has more features. It is which tool your team can actually operate without it becoming a maintenance liability.
FAQs
1. Internal Developer Portal vs Platform: What’s the Difference?
A developer portal is a UI layer. It surfaces information about services, ownership, and documentation. A developer platform is the operational layer underneath. It provisions environments, manages deployments, handles secrets, and runs CI/CD pipelines. Backstage is a portal. A modern internal developer platform handles the infrastructure layer the portal sits on top of.
2. How Long Does It Take to Build an Internal Developer Platform Through Backstage?
Getting a production-ready Backstage internal developer platform typically takes months, not weeks. Most teams report 6 to 12 months before the catalog is populated, plugins are stable, and developers are actively using it. Off-the-shelf IDPs reduce that to days or weeks.
3. How Does Platform Engineering Relate to an Internal Developer Platform?
Platform engineering and internal developer platforms go hand in hand. Platform engineering is the discipline of building and maintaining the infrastructure and tooling that developers deploy into. The best internal developer platforms are what platform engineering teams build or adopt to deliver that capability consistently across the organization.
4. Can Backstage Provision Cloud Infrastructure Like AWS?
No. Backstage does not provision cloud infrastructure. It has no native capability to create VPCs, spin up EKS clusters, configure RDS instances, or manage any AWS resources directly. An AWS internal developer platform handles that layer. Backstage catalogs what already exists.
5. Is Backstage Suitable for Small Engineering Teams?
Generally not. Backstage requires a minimum of 2 to 4 full-time engineers to maintain in production, TypeScript proficiency on the platform team, and existing infrastructure automation before it delivers meaningful value. For teams under 50 engineers without a dedicated platform function, the operational overhead typically outweighs the benefit.
Conclusion
Backstage is a well-engineered tool. The CNCF backing, the plugin ecosystem, and the community are real assets. For large engineering organizations with a dedicated platform team and existing infrastructure automation, it is a reasonable choice.
For everyone else, the math rarely works out. Three engineers maintaining a portal is three engineers not building the platform capabilities your developers are actually waiting for.
The decision is not really about Backstage vs everything else. It is about what your team can absorb operationally right now. An IDP that provisions infrastructure on day one and gets out of the way delivers more value than a portal your team spends a year building.
If your team is at that decision point, a 20-minute technical walkthrough with one of our engineers is worth the time before you commit engineering resources in either direction.
Get started for free -- Connect an AWS account and stand up an environment to see how it fits into your existing workflow.
Explore the Docs -- A detailed breakdown of how LocalOps works end-to-end, including architecture, environment setup, security defaults, and where engineering decisions still sit.