Internal developer portal
Also known as: developer portal
An internal developer portal is a single website where a company's developers can find every service, its owner, documentation, health, and the self-service actions they need, such as creating a new project.
Spotify's open-source Backstage is the best-known example. While a portal looks like a nice catalogue, its real value is answering the questions that waste hours every week: who owns this, where are the docs, and how do I deploy it?
Internal developer portal, explained at three levels
At home
Think of a developer portal as a company intranet just for software. Instead of asking around to find out who built a system or where its instructions are, you search the portal and find everything in one place.
At work
A developer portal helps new hires get productive faster and saves experienced staff from answering the same questions repeatedly. It lists every service, who owns it, and how to work with it.
At home
Most portals have three core pieces: a catalogue of services and their owners, documentation that lives next to the code, and templates that create new projects with everything set up. Some also show whether each service meets standards, like having tests or alerts.
At work
Portals often add 'scorecards' that grade services on production readiness, security, and documentation, which turns standards into visible goals. Integrations with CI/CD, cloud accounts, on-call schedules, and cost tools make the portal the front door to the internal platform.
At home
Backstage models software as entities (components, APIs, systems, owners) described in YAML files stored with the code. In my view, keeping metadata in the repository is smart, because ownership information that lives in a separate spreadsheet goes stale within months.
At work
Build-versus-buy is the key decision. Self-hosting Backstage gives flexibility but needs a dedicated team for upgrades and plugins; commercial portals trade flexibility for faster setup. Either way, success depends on automated catalogue ingestion, clear ownership rules, and tying the portal to real workflows so engineers have a reason to visit.
Real-world examples
At home
Carlos was on call when an unfamiliar service started failing. He searched the developer portal, found its owner, runbook, and dashboard in seconds, and paged the right team instead of guessing in a group chat.
At work
Lena is an engineering manager at a Montreal fintech with 300 microservices. After launching a portal with ownership and scorecards, her team found 40 services with no owner and 25 missing alerts, and fixed them before an audit.
Common confusions
- A developer portal is the same as an internal developer platform. — The portal is the front end. The platform is the underlying tooling and infrastructure it exposes.
- Installing Backstage gives you a working portal. — Backstage is a framework. You still need to populate the catalogue, build integrations, and maintain it.
- A portal is just a documentation site. — Good portals also offer self-service actions and live data about service health, ownership, and standards.
For analysts
Judge a portal by how often engineers use it to answer a real question. I'd track searches and self-service actions, because a beautiful catalogue that nobody opens is just another wiki.
History & origin
Large tech companies built internal portals for years, but Spotify's Backstage, released as open source in March 2020 and accepted into the Cloud Native Computing Foundation that September, turned the idea into a category. Backstage introduced a software catalogue, templates for creating new services, and a plugin system. Commercial products such as Port, Cortex, and Roadie followed, and Spotify itself began selling Backstage plugins. Many organizations found that Backstage needed significant engineering effort to run, which fuelled demand for hosted options. In my opinion, a portal is only as good as its catalogue data, and most portal projects stall because nobody keeps that data accurate.