A golden path is the opinionated, supported route a platform team builds so a developer can go from "I need a new service" to a running, guarded, observable workload without filing a ticket or reinventing infrastructure decisions. It sits at the intersection of platform engineering (the org that builds the platform), the internal developer platform (the thing that exposes it), and workflow orchestration (the machinery that actually executes each step). The catch every platform team eventually learns the hard way: a golden path that is mandatory, opaque, or missing an off-ramp stops being a paved road and becomes a golden cage — and developers quietly route around a cage long before anyone admits the platform failed. Designing a golden path well means treating it as a versioned, measured product with an escape hatch, not a one-time migration project.
What This Cheat Sheet Covers
This topic spans 10 focused tables and 67 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
Table 1: Golden Path & Platform Fundamentals
Before designing anything, it helps to pin down the vocabulary platform teams actually use — the difference between a golden path and the platform that hosts it, and the failure mode every golden path risks becoming.
| Concept | Example | Description |
|---|---|---|
A pre-configured Python FastAPI template that already wires up Docker, CI/CD, and observability | An opinionated, well-documented, supported way to build and deploy software within an org; also called a paved road. | |
Portal + APIs + golden path templates + provisioning + observability, bundled behind one self-service front door | The standardized set of self-service tools and capabilities developers use to build and ship code; the golden path is what an IDP offers. | |
A platform that mandates a "Deploy" button but hides the underlying Kubernetes error when it fails | • An IDP designed for control over consumption • Mandatory, opaque abstractions with no way to see or fix what broke underneath. | |
Platform team runs a roadmap, gathers NPS, and treats app teams as customers rather than captive users | A platform exists to serve its users' requirements and should be designed and evolved like any other product, prioritized by real usage. |