How does platform engineering relate to DevOps?

Platform engineering builds on DevOps by providing a well-designed platform that makes it easier for teams to build and run software collaboratively. It doesn't replace DevOps but enhances its implementation.

What is a golden path in platform engineering?

A golden path is a supported, documented way to complete common engineering tasks, like creating a service or releasing a change. It combines reusable workflows, templates, and documentation to streamline processes.

Does self-service remove production approvals in platform engineering?

No, self-service allows engineers to complete supported work without manual intervention but retains necessary authorization steps for risky changes. It doesn't grant developers unrestricted production access.

Can you build an IDP using CNCF projects?

Yes, CNCF projects like Backstage, Crossplane, Argo CD, and Kubernetes can be used as building blocks for a custom internal developer platform (IDP). They offer components to create a tailored platform experience.

Platform Engineering: A Practical Introduction

Q: What is platform engineering?

Platform engineering is about providing shared capabilities as internal products to help teams deliver and operate software efficiently. It includes people, processes, policies, and technology to reduce the technical burden on application teams.

Q: Who owns the service and path in platform engineering?

The application team owns the service, while the platform team owns the supported capability used to deliver it. Shared ownership involves clear responsibilities at the boundary, not universal accountability.

For many software teams, development and operations used to be separate worlds. Developers wrote the application, then handed it over to an operations team to deploy and maintain. Changes had to cross that boundary, often through tickets, queues and repeated explanations.

DevOps emerged to improve that relationship. The first DevOpsDays, organised by Patrick Debois in 2009, became an important milestone in a movement towards closer collaboration, automation and shared responsibility for software in production.

Meanwhile, cloud computing gave teams more control over the infrastructure their applications needed. But that freedom also brought more decisions: how to build and deploy software, manage access, collect logs, monitor services and recover when something went wrong. In organisations with many development teams, the same supporting work could be repeated across projects.

Platform engineering addresses that duplication and complexity. Instead of every team assembling and maintaining its own delivery setup, a platform team provides shared, supported capabilities that developers can use themselves. Application teams retain responsibility for their software, but do not have to build every underlying capability from scratch.

This approach developed across organisations rather than being invented by one person. Evan Bottcher’s 2018 description of platforms as compelling internal products, followed by Matthew Skelton and Manuel Pais’s Team Topologies in 2019, helped articulate the idea: reduce the technical burden on application teams so they can focus on the software their users need.

Platform engineering therefore builds on DevOps rather than replacing it. DevOps encourages teams to build and run software together; a well-designed platform makes that easier to do in practice.

Consider a fictional online store. A customer submits an order through its website; an orders API accepts the request and records the order in an existing database. Payment processing is outside this example. The application team wants to change that API safely, not rediscover deployment, identity and diagnostic conventions for every release.

We will use this service to explain how a shared platform can help, then look at concrete tools and company examples at the end. This is an introduction to the ideas and responsibilities, not a guide to building an internal developer platform. Detailed implementation belongs in a separate article.

Fictional customer request path through the website and orders API to the existing database

Figure 1 — The fictional customer request path through the website and orders API to the existing database.

What is platform engineering?

Platform engineering is the discipline of providing shared capabilities as an internal product that helps teams deliver and operate software. It includes people, processes and policies as well as technology. CNCF explicitly frames it around the needs of internal users and the business outcomes those capabilities support.[1][2]

An internal developer platform, or IDP, is the usable combination of those capabilities: supported workflows, interfaces, documentation and operational support. Its purpose is not to conceal all infrastructure knowledge. It is to make common work consistent while keeping necessary controls and failure information accessible.

A developer portal is one possible interface to that platform. A portal might help engineers discover services, identify owners or start a workflow. It is not the deployment capability, identity policy or support agreement behind the screen. CNCF describes platforms with web, API, CLI and template interfaces; it does not require a particular front end.[1]

The distinction matters when comparing products: a portal can be the front door, but the platform also includes the delivery, identity and operational capabilities behind it. Installing a portal does not automatically provide a complete internal developer platform.

How do developers actually use those capabilities day to day? Usually through a small number of supported routes for common tasks, often called golden paths.

What is a golden path?

A golden path is a supported, documented way to complete a common engineering task, such as creating a service or releasing a change. CNCF describes it as a reusable workflow combined with a project template and documentation.[1] Teams can follow it instead of assembling those steps themselves.

For our orders API, the path should cover creating the service repository, validating and building a change, promoting it, and finding the evidence needed to operate it—not just generating starter files.

For this fictional store, the supported path is for stateless HTTP services on an existing runtime. The API instances can be replaced; the orders stored in the database must be preserved.

The path would provide a maintained build workflow, reusable deployment configuration, runtime identity integration, telemetry conventions and a runbook starting point. It would also return useful status: which revision was built, which artifact is proposed for production, whether deployment converged, and where to investigate a failure.

This is self-service when engineers can complete supported work through the interface without a platform engineer manually fulfilling each request.[1] It does not mean every developer can approve their own production access. A workflow can be self-service while retaining an explicit authorization or approval step for a risky change. The distinction is between an intentional control and an accidental dependency on someone remembering a command.

Who owns the service, and who owns the path?

The application team owns the orders service; the platform team owns the supported capability used to deliver it. Shared ownership means named responsibilities at their boundary, not that everyone is accountable for everything. The following division is a proposed design for this example.

Concern	Application team	Platform team
Service behaviour	API code, business rules, tests and data correctness	Supported runtime interface and documented constraints
Delivery	Application tests, release intent and promotion decisions	Reusable workflow, deployment integration and actionable failure status
Identity	Describe required application access	Integrate scoped identities and access policy with the responsible security and infrastructure teams
Observability	Instrument meaningful outcomes; maintain service diagnostics	Supported collection/export path, shared conventions and access
Incidents	First response to customer-facing orders failures; application recovery decisions	Respond to failures of shared delivery, runtime integration or telemetry capabilities
Evolution	Adopt supported versions; raise missing use cases	Compatibility policy, migration guidance and support lifecycle

The platform team need not operate every underlying service. CNCF recommends keeping the platform a thin, consistent layer over capabilities that may be maintained by managed providers or other internal teams.[1] In this design, an infrastructure team can operate the cluster while the platform team remains responsible for the developer-facing deployment experience. The escalation route must reflect that arrangement.

What does a platform contract mean in practice?

A platform contract is the agreement about what a platform supports and what it expects from application teams. It explains the available capabilities, access restrictions, support responsibilities and how changes to the supported path are introduced.

For example, the orders team chooses a supported service template, identifies the owning team and selects an allowed environment. The platform provides maintained delivery defaults, deployment status and diagnostic links. The agreement need not start with a custom configuration format.

How does a repository become a production service?

For the fictional orders API, the supported path connects four activities: starting from maintained defaults, testing and building a change, deploying an approved release, and checking its behaviour. This is an illustrative delivery flow, not a prescribed tool stack.

Start from maintained defaults. A service template supplies an initial repository and documentation. Reusable pipelines keep common build logic shared rather than permanently copied into every project. GitHub Actions reusable workflows are one concrete mechanism for this.[5] The application team still writes the tests for order behaviour.
Test and build an identifiable release. The pipeline runs the relevant checks and records which source revision produced the release artifact. A failed application test goes to the orders team; a broken shared pipeline has a platform support route.
Deploy through a supported workflow. The team selects an allowed environment and follows its approval requirements. A GitOps approach is one option: versioned desired state is reconciled with the runtime.[10] Argo CD can support that approach by automatically synchronising changes from Git.[7] In this design, review and approval controls sit in the surrounding delivery workflow. A successful build is not the same as a successful deployment.
Keep access and status clear. The developer, build job, deployment system and running application are different actors with different permissions. A portal login must not become unrestricted production or database access. The path should show whether a release is waiting for approval, has failed to deploy, or has deployed but is behaving incorrectly.

How will the team know what happened after deployment?

The path should make operational evidence accessible, while the application team remains responsible for its meaning. OpenTelemetry distinguishes traces, metrics and logs: a request's path, runtime measurements and recorded events.[8] In our design, shared service, release and environment identifiers help connect those signals to a deployment.

For orders, useful questions include: are submissions succeeding, how long do they take, and is the database interaction failing? The application team instruments those outcomes and avoids putting sensitive order payloads into diagnostics. The platform supplies the supported collection and export path; instrumentation and business correctness do not appear automatically because that path exists.

The service runbook should identify the first responder, show the diagnostic starting points, explain a safe mitigation and name the escalation route. For example, customer-facing order errors first reach the orders team; a broken shared reconciler reaches the platform team. During an incident, those teams collaborate rather than forwarding the ticket indefinitely.

Recovery also needs a supported procedure. Returning to an earlier application release may help, but the team must check compatibility with stored data and verify customer outcomes afterwards. Reverting application code cannot undo data changes.

Turing's introduction to SRE explores service readiness, incident response and engineering follow-up in more detail.[9] That is complementary reading, not a requirement to build a separate SRE organisation for this example.

How do you avoid turning the golden path into a cage?

Provide a supported default and an explicit escape hatch: a documented way to deviate when the common path does not fit. CNCF describes platforms as optional and composable, including the ability for product teams to operate capabilities outside the platform's offerings.[1]

Suppose orders needs a deployment strategy the supported service template does not cover. In our design, the teams record the reason, the application-owned implementation, the security and operational requirements that still apply, the support boundary, and a review date. An exception is not permission to disable mandatory controls or an unspoken promise that the platform team will support unknown configuration forever.

Repeated exceptions are product feedback. If several teams need the same capability, consider making it part of the supported path. If one unusual service needs it, an explicitly owned deviation may be cheaper and clearer than expanding every service's interface.

Where should a platform team start?

Start with one frequent journey and a willing application team. DORA recommends a minimum viable platform that makes the most common workflow demonstrably better, then evolves through feedback.[3] For this store, that journey is taking one orders API change from a repository to an observable, recoverable deployment.

Observe the work before replacing it: where does the team wait, repeat configuration or ask another person for help? Build the smallest supported path that removes those frictions. Have a second engineer use it without the platform author beside them. Their first confusing failure is useful evidence for the next improvement.

Measure the journey, not the number of tools installed. In this example, track time to the first supported deployment, waiting time, in-scope tasks completed without platform tickets, repeat adoption by eligible teams, and application delivery/reliability signals. Compare like-for-like workflows and combine those observations with interviews. These are proposed measures, not benchmark targets or claims of achieved savings.

CNCF recommends both quantitative and qualitative feedback; its maturity model also warns that reaching the highest level is not an objective in itself.[1][2] Shared capabilities require maintenance and can concentrate failures across teams. Expanding the platform is worthwhile only when the benefit justifies that added responsibility.

A practical IDP starts when an application team can use a supported capability, understand its result and know who owns the next action. The portal can wait. The dependable path cannot.

What are concrete examples of developer platforms and portals?

Backstage, Cortex and Red Hat Developer Hub illustrate different ways to provide a developer-facing entry point. Backstage is an open-source framework; Cortex is a commercial product; Red Hat Developer Hub packages a Backstage-based portal with enterprise support. They are not interchangeable with the whole platform behind them.

Backstage: an open-source portal framework, built at Spotify

Backstage provides a software catalog, Software Templates and TechDocs for technical documentation. Its catalog helps developers discover software and ownership; templates provide a consistent starting point for new projects. It is a framework that a platform team integrates with its own tools, rather than a ready-made deployment environment.[11]

Spotify's engineering account describes how its internal Backstage grew from a service catalog into a shared place to create, manage and monitor projects, and how it was open-sourced in March 2020.[18] Spotify also explains that its backend, frontend and data-pipeline templates are maintained by experts in those disciplines and form part of its supported golden paths.[12]

A concrete developer journey is choosing a supported backend-service template instead of assembling a project from scratch. Backstage's template feature can generate the initial code and publish it to a repository such as GitHub or GitLab.[4] The useful combination is a discoverable starting point, maintained defaults and a team responsible for keeping that path usable—not simply a catalog page.

Cortex: a commercial product, with Xero as a documented example

Cortex is a commercial, proprietary product, not an open-source alternative to Backstage.[13][19] It now describes itself as an Engineering Operations Platform, evolved from an internal developer portal. Its capabilities include a catalog of services and owners, scorecards for checking agreed standards, and self-service workflows.[14]

In Cortex's customer case study, Xero is described as moving from a homegrown portal to Cortex to centralise information about services, dependencies and ownership.[15] This illustrates a practical use case: helping an engineer find the responsible team and relevant service information instead of tracing it through spreadsheets and disconnected tools. The adoption account comes from the vendor; it is not an independent assessment of business results.

Red Hat Developer Hub: a supported Backstage-based option

Red Hat Developer Hub is an enterprise developer portal based on Backstage, with supported plugins and integrations, including with OpenShift.[16] Its project code is available under the Apache 2.0 licence.[17] That open-source code and Red Hat's supported product offering are distinct choices.[16] It is relevant when a team wants a Backstage-based portal with a vendor-supported package rather than assembling the upstream framework entirely itself.

Open-source and commercial approaches

Open-source options extend beyond Backstage, but they solve different problems. Compare portals with portals, and orchestration or delivery components with the corresponding platform layer. Kratix, KubeVela and Crossplane are not drop-in replacements for Backstage's catalog and portal experience; they can complement a portal. The suggested fit and trade-offs below are editorial guidance, not benchmarks or claims of equal maturity.

Product / approach	Layer & licensing	Useful when and trade-off
Backstage	Portal framework; Apache 2.0.	Useful when: You want a custom catalog, templates and documentation experience, with a team to build it. Trade-off: You own integration, hosting and ongoing maintenance.
Red Hat Developer Hub	Backstage-based portal distribution; Apache-2.0 project with commercial support.	Useful when: You want a supported Backstage package, particularly alongside OpenShift. Trade-off: It is a Backstage distribution, not an independent alternative; you still own deployment and integrations.
Cortex	Commercial, proprietary engineering-operations product with portal capabilities.	Useful when: Service ownership, scorecards and self-service workflows are the main gaps. Trade-off: You still need to define standards and maintain the underlying integrations.
Kratix	Platform orchestration framework; Apache 2.0. Not a portal.	Useful when: You want reusable platform APIs (Promises) and workflows for provisioning and lifecycle operations. Trade-off: Your team defines and maintains the Promises, workflows and integrations.
KubeVela	Application-delivery platform; Apache 2.0.	Useful when: You want application abstractions and delivery workflows across clusters or cloud environments. Trade-off: You adopt its application model and maintain the delivery definitions and control plane.
Crossplane	Platform control-plane framework; Apache 2.0. Not a portal.	Useful when: You want declarative platform APIs to compose and manage infrastructure and applications. Trade-off: You own API design, compositions, providers and control-plane operations.
Custom Kubernetes-based IDP	Architecture approach using open-source components; not a single product or licence.	Useful when: You need tailored platform APIs and workflows, and can staff a platform team. Trade-off: Your team owns composition, integration, upgrades and operational support.

KubeVela is a CNCF Incubating project; Crossplane is Graduated. These are CNCF maturity levels, not a feature ranking or proof that a particular integration fits your organisation. Open-source licensing also does not mean that every vendor extension or support offering is free.

Project documentation, licences and release activity checked in October 2026. These are components and approaches, not substitutes for owning the developer experience.

Can you build an IDP from CNCF projects?

Yes. Backstage and Crossplane are CNCF projects. So are Argo and Kubernetes. They offer building blocks for a custom platform, rather than one packaged “CNCF IDP”.

For our fictional store, an illustrative combination is Backstage as the portal, Crossplane for platform APIs and resource provisioning, Argo CD for GitOps deployment, and Kubernetes to run the orders API. Kubernetes alone is not an IDP: the platform team still builds and supports the integrations, policies and golden paths that make those components usable together.

Illustrative CNCF IDP architecture: Backstage, Git, Argo CD, Kubernetes and Crossplane, with separate runtime API-to-database traffic

Figure 2 — One illustrative IDP: Backstage proposes a Git change for review, Argo CD syncs the merged application and platform resources, and Crossplane provisions a database. Runtime data flows directly from the orders API to the database. CI and supporting services are omitted. This variant illustrates provisioning a database; an existing database could instead be integrated.

These examples are starting points, not a product ranking. First identify what developers struggle to do: find a service owner, start a supported project, request an environment or understand a failed release. Then choose the capabilities and interface that address that problem.

Frequently asked questions

Does platform engineering require Kubernetes or a developer portal?

Not for the definition of a platform. CNCF describes capabilities offered through multiple interfaces and backed by different providers.[1] A useful platform can start with shared delivery workflows and documentation; its interface need not be a portal, and its runtime need not be Kubernetes.

Does self-service remove production approvals?

Not in this design. Self-service removes routine manual fulfilment while retaining the authorization required for the requested action. A developer can initiate and inspect a workflow without having permission to approve every production change or grant arbitrary access.

Does the platform team take over application operations?

Not here. The orders team owns application behaviour, data correctness and recovery decisions. The platform team supports the shared delivery capability and its integrations. Both teams need a clear escalation agreement so a cross-boundary incident does not become an ownership dispute.