Internal Developer Platform

An internal developer platform (IDP) is the self-service layer an organisation builds over its existing infrastructure and tooling so that developers can get what they need to build, deploy and run software, such as an environment, a pipeline, a database or a service identity, without raising a ticket. Developers request capabilities through templates, a web portal, a command-line tool or an API; the platform fulfils the request automatically and applies the organisation’s security, compliance and cost rules as it does so. The key constraint: it is run as an internal product and succeeds only if developers choose to use it.

Technical definition

The CNCF Platforms White Paper defines a platform as an integrated collection of capabilities defined and presented according to the needs of its users. The attributes it lists include:

• Self-service: users request and receive capabilities autonomously and automatically, for example a database together with its locator and credentials.
• Golden path templates: an initial project template plus documentation for a complete build, test, deploy and observe workflow.
• Abstraction: users do not operate the services underneath; they configure and observe them.
• Optional and composable: teams can use parts of the platform and run their own capabilities outside it when they must.
• Secure by default: organisational rules and validation are built into what the platform hands out.

Operational relevance

For operations and infrastructure teams, the platform is where standards are enforced once instead of being reviewed per request. Microsoft’s guidance routes each request to a fulfilment provider, such as a CI/CD system, a GitOps tool or a workflow automation tool for steps that are still manual, and expresses the result as code: infrastructure as code with Bicep, Terraform or Helm charts, and policy as code with Azure Policy or Open Policy Agent.

Architecture relationship

The platform sits between product teams and capability providers. The CNCF paper is explicit that a platform team is mainly responsible for the interfaces (GUI, CLI and API) and the experience, not necessarily the backing services, and recommends the thinnest viable platform layer over managed or internally provided services. A developer portal is one interface on top of that layer, not the platform itself.

Example

A team needs a new web service. In a portal built on Backstage, an open source framework for developer portals, the developer opens the Software Templates page at /create, chooses the organisation’s web service template and enters the repository details, checks them on the review page and selects Create. Behind the template, the platform can create the repository, configure the CI/CD pipeline, provision infrastructure from shared infrastructure as code modules and apply branch protection. If a step fails, its log is available from the run, and the task can be started over with the same parameters pre-filled once the cause is fixed.

Common misunderstanding

A frequent misunderstanding is treating the portal as the platform. A portal without automated fulfilment and governance behind it is a front door to the same ticket queue. Another is a big-bang, top-down build. Microsoft advises against it and recommends starting with a thinnest viable platform, a minimum viable product, and growing from there.

Related terms

• Platform engineering: the practice of building and running the internal developer platform as a product.
• Golden path or paved path: a supported, pre-integrated route from idea to production.
• Developer portal: the web interface to the platform’s catalogue, templates and documentation.
• Infrastructure as code and GitOps: the mechanisms that make fulfilment repeatable and auditable.

Further reading

• CNCF Platforms White Paper.
• Microsoft Learn: What is platform engineering?.
• Microsoft Learn: Self-service with guardrails.
• Backstage documentation.

Checking an internal developer platform is doing its job

Measure outcomes rather than features. The CNCF paper suggests tracking the time from request to fulfilment of a capability such as a database or test environment, the time to build and deploy a brand new service to production, and the time for a new user to submit their first code change, alongside the four DORA metrics: deployment frequency, lead time for changes, time to restore service and change failure rate. Keep the platform optional, so a team blocked by a missing capability can still provision it outside the platform.