What is an internal developer platform, and how does a portal differ?
An internal developer platform (IDP) is the set of self-service capabilities that a platform team builds and operates so application developers can create, deploy and run software without filing tickets: environments, deployment pipelines, databases, secrets, observability and access control. A developer portal, such as one built with Backstage, is a web interface to that platform with a service catalog, templates and documentation. A platform can exist without a portal, but a portal without a platform behind it only links to tickets and wikis.
What a platform includes
The CNCF platforms white paper defines a platform as “an integrated collection of capabilities defined and presented according to the needs of the platform’s users” (CNCF TAG App Delivery). It lists 13 capability domains, which group into four areas:
| Area | Capabilities from the CNCF white paper |
|---|---|
| Interfaces | Web portals; APIs and CLIs for automated provisioning; golden path templates and docs |
| Delivery | Build and test automation; delivery and verification automation; development environments; artifact storage |
| Runtime services | Infrastructure services; data services; messaging and events; observability |
| Security | Identity and secret management; security services |
No team builds all of these at once. A platform usually starts with the two or three capabilities that block developers most often, such as creating a new service with a working pipeline, or getting a database without a ticket.
Platform vs portal
| Internal developer platform | Developer portal | |
|---|---|---|
| What it is | Capabilities, APIs and automation | A user interface |
| Examples | Kubernetes clusters, CI/CD pipelines, GitOps, infrastructure as code, secret managers | Backstage, commercial portal products |
| Who uses it | Developers, through any interface, and other systems through APIs | Developers browsing services, docs and templates |
| Without the other | Usable through Git, CLI and APIs | A catalog with links, but no self-service |
Backstage describes itself as “an open source framework for building developer portals” (Backstage docs). It came from Spotify, is a CNCF incubating project and provides a software catalog, software templates and TechDocs. Backstage is a framework, so teams write and maintain plugins to connect it to their own systems.
The white paper says platforms should meet users where they are: GUIs, APIs, command-line tools, IDEs and portals. Many developers interact with a platform only through a Git repository and a pull request, and never open a portal.
Golden paths
A golden path is a supported, documented way to do a common task, such as “create a new HTTP service”. In practice, it is a template that creates a repository, a CI pipeline, Kubernetes manifests, dashboards and alerts that already follow the organization’s standards. Developers who take the golden path get security and operations defaults for free. Developers who need something different can still leave it. The white paper lists “optional and composable” as an attribute of good platforms, alongside self-service, reduced cognitive load and secure by default.
Kubernetes as the substrate
Many platforms are built on Kubernetes because its API already provides self-service primitives: namespaces, RBAC, declarative manifests and custom resources that extend the API with new kinds of objects. GitOps tools apply those resources from Git, as described in what GitOps is.
The cluster layer is also where platform teams lose the most time to work that developers never see: control plane operation, version upgrades every few months, node provisioning and patching, networking and certificates. Using managed Kubernetes moves control plane operations off the platform team’s backlog, which leaves more time for the capabilities developers actually request.
Platform engineering and DevOps
Platform engineering is the discipline of building and running an internal developer platform as a product, with developers as its customers. It does not replace DevOps practices; it packages them so each team does not rebuild the same pipelines and infrastructure. The blog post on platform engineering vs DevOps compares the two in more depth.
How to measure a platform
A platform that nobody uses has failed, however good its technology is. The CNCF white paper groups platform metrics into three categories:
- User satisfaction and productivity: active users and retention, survey scores such as Net Promoter Score, and developer productivity measures.
- Organizational efficiency: time from request to fulfillment, time to build and deploy a new service, and time until a new developer submits their first change.
- Delivery performance: the DORA metrics. DORA currently tracks five: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate.
Track adoption of each golden path separately. A path that few teams take shows where the platform does not yet fit how developers work.
The cluster layer with Cloudfleet
Cloudfleet Kubernetes Engine (CFKE) is a fully managed Kubernetes service whose single control plane spans multiple clouds and on-premises nodes. Node auto-provisioning creates and deletes nodes based on Pod requirements, so the platform team does not size node pools. CI pipelines in GitHub Actions or GitLab CI reach clusters with OIDC tokens instead of stored credentials.