RU
Writing · Developer experience · 2026

Backstage: the internal developer portal

When you have dozens of services, knowledge about them scatters across heads and chats. Backstage gathers the catalogue, docs and tools in one place.

As the number of services grows, an invisible but expensive problem appears: no one knows the whole system any more. Where are the docs for a service? Who owns it? How do you run it locally? What are its dependencies? The answers live in heads, personal notes and chat threads — and evaporate when someone goes on holiday or leaves the company.

Spotify’s Backstage solves this as a single developer portal — one entry point into the company’s entire engineering reality. It rests on a few ideas, each closing a specific pain.

The Software Catalog lists every service, library and pipeline with explicit owners. Open a service and you immediately see the owning team, links, dependencies and status. “Whose is this and who do I ask” stops being a quest.

TechDocs is documentation as code: it lives in the repository next to the service, is reviewed together with it and is published to the portal automatically. So docs stop going stale in a separate wiki everyone has forgotten.

Software Templates (the scaffolder) are blueprints for new components. A new service is created in a couple of clicks, already wired with CI/CD, linters, structure and documentation. This is what people call a “golden path”: the right way becomes the easiest way.

On top sit plugins: monitoring, CI/CD, cloud resources, feature flags and whatever matters to the team, gathered into one interface instead of a dozen tabs. The portal extends to fit a specific company’s infrastructure.

After adopting Backstage we centralised documentation, the catalogue and tooling — onboarding of new developers sped up noticeably, and “tribal knowledge” became a browsable, living catalogue. In one line: a developer portal is about finding, not asking.