The Developer Portal Problem Backstage Is Trying to Solve
Spotify has released the open source version of Backstage, its internal developer portal. The project is an attempt to address a problem that becomes more acute as engineering organizations scale: infrastructure sprawl. A team deploying to the cloud today is expected to be fluent in Terraform, GCP/AWS/Azure CLIs, GitLab CI, Prometheus, Kubernetes, Docker, and various monitoring and alerting tools — on top of the domain-specific tooling for their discipline, whether that's backend services, machine learning, mobile, or data engineering.
The complexity only grows as additional resources like databases and queueing systems enter the picture. Not every engineer has deep expertise in the cloud-provider tooling their company has standardized on, yet everyone is expected to operate within that ecosystem.
A Single Frontend for Infrastructure
Backstage unifies infrastructure tooling, services, and documentation behind one consistent UI. The goal is that GCP, Bigtable, CI pipelines, TensorFlow Extended, and whatever else lives in the stack all share the same easy-to-use interface. Developers get a uniform view of their resources regardless of where they run, an onboarding path to new tools, and the ability to spin up resources like Kubernetes-hosted backend services through a few clicks — without leaving the Backstage interface.
Use Cases at Spotify
Spotify's internal installation of Backstage has over 100 integrations ("plugins"). Because the open-source version has no end-to-end use cases yet, the team highlights four common patterns to make the value concrete:
- Creating a new microservice
- Following a pull request from review to production
- Centralizing technical documentation
- Reviewing mobile feature performance
Microservice Creation in a Few Clicks
Creating a new software component, such as a microservice, starts from a set of standard templates with best practices baked in. After entering metadata, Backstage creates a repository with a "hello world" service that automatically builds and deploys to Kubernetes on GKE. Ownership information is captured in the service catalog, and developers can see all the services they own.
Pull Requests Reviewed Through a CI/CD Lens
When a pull request hits Spotify's GitHub Enterprise, the CI system posts a link to the CI/CD view in Backstage. That view consolidates build progress, test coverage changes, and a re-trigger button, so engineers don't chase this information across separate systems. Spotify's homegrown CI runs on Jenkins under the hood, but engineers interact only with GitHub Enterprise and Backstage.
Docs in the Repo, Rendered Centrally
Spotify follows a docs-like-code approach: Markdown documentation lives with the code, and CI builds a documentation site with MkDocs. A Backstage plugin renders all these sites centrally, alongside metadata such as owner, open issues, and related Stack Overflow tags.
Mobile Feature Performance at a Glance
Spotify's mobile codebase is organized by feature, each owned by a different team. A Backstage plugin lets developers on one team see how their feature affects overall app performance:
Figures above for illustrative purposes only.
The same view supports investigating crashes, releases, and test coverage trends over time.
Why Open Source
Spotify's infrastructure fragmentation isn't unique — peer companies face the same challenge as they adopt more open-source tools and build more internal infrastructure. The ambition for the OSS release is to become a standard UX layer across the broader infrastructure landscape. Releasing early is a deliberate move to collaborate with companies that share the problem and want to improve developer experience for their own teams.
Roadmap
Backstage was built about four years ago internally, and the open-source version is still in its first iteration. The team has outlined three phases on its GitHub milestones:
- Phase 1 — Extensible frontend platform (now): A consistent UI layer for internal infrastructure and tools, built from reusable UX patterns and components.
- Phase 2 — Software inventory (next 2-3 months): A central inventory with ownership tracking, enabling creation and management of software at scale — from new libraries to Kubernetes deployment status to test coverage for a website, all in one developer portal.
- Phase 3 — Ecosystem (later): A community of contributors building open-source plugins and integrations so teams can match Backstage to their own stack.
The vision is for Backstage to become the standard toolbox for the open-source infrastructure landscape. For those interested in contributing or shaping the product, there's more guidance for adopters at backstage.spotify.com.
