Golden Paths: The Supported Way to Build and Ship
A golden path is a curated, supported route through the platform that makes the secure and observable option the easiest option for product teams.
Definition
A golden path is an opinionated, documented workflow, template, and toolchain that platform teams maintain so application teams can build, test, deploy, and operate a service without assembling their own stack.
Context and scope
Internal platforms fail when they offer capabilities without guidance; golden paths turn a catalogue of tools into a route that a new engineer can follow on their first day.
Common misconceptions
- A golden path is mandatory — it is the paved road, not a cage, and escape hatches stay available
- Golden paths are templates — a template is one artifact; a path includes CI, observability, and support
- One path fits every workload — APIs, batch jobs, and data pipelines usually need separate paths
Anti-patterns
- Publishing a path nobody maintains, so it drifts away from the platform
- Measuring adoption by counting template clones instead of running services
- Blocking all alternatives, so teams route around the platform entirely
Related concepts
Authoritative source
A paved road, not a cage
A golden path is the route a platform team recommends and supports: a repository template, a pipeline, default observability, and a documented way to reach production. It is opinionated on purpose. Teams can leave the path, but leaving costs them the automatic upgrades and the support contract, which is a fair trade rather than a punishment.
What a path includes
A path is more than scaffolding. It includes a working build, tests wired into CI, deployment manifests, dashboards, alerts, and an owner. It also includes documentation written for the person who joins next quarter, and a way to upgrade existing services when the path changes. Without an upgrade mechanism, every path becomes a museum of old versions.
Adoption is the metric
Platform teams often launch a path and declare success when the template is downloaded. The useful measure is the share of production services built and shipped through the path, plus the time from first commit to first deploy. If adoption stalls, the path is usually slower than the workaround, which is a product problem rather than a communication problem.
Keeping it alive
A path needs a maintainer, a changelog, and a deprecation policy. For example, a path that upgrades its base image monthly will accumulate services on old images unless there is an automated pull request to each consumer repository. Compared to a wiki page of recommendations, a golden path is executable: it runs, it fails loudly, and it can be tested in CI.
When to build one
Build a path when several teams repeat the same setup work or when audits keep finding the same missing controls. Start with the most common workload, measure the time it saves, and add paths for other shapes only when the demand is real.