What Is a Golden Path?
The easiest way to do something correctly.
A golden path is a pre-built, opinionated template for common development tasks that the platform team maintains and developers adopt voluntarily — because it is faster than the alternative, not because it is required.
Definition and origin
Where golden paths came from and what they mean
The term was popularized by Spotify's internal platform team. Spotify was building Backstage — an internal developer portal — and needed a concept to describe the curated routes through platform capabilities that the platform team was maintaining. They called these "golden paths": the routes that the platform team had invested in, tested, and would support ongoing.
The concept predates the name. At Google, these were called "boring solutions" — the standard, well-understood approaches that Google's infrastructure team had validated and recommended. At Netflix, they were called "paved roads." The naming varies; the concept is the same: a deliberately curated, maintained path that reduces the decisions developers need to make to go from idea to production.
The key word in every definition of a golden path is "voluntary." A golden path is not a mandate enforced by the platform team. It is a path developers choose because choosing it is easier than not choosing it. When a golden path requires force to adopt, it has failed as a design: the path is not actually better than the alternatives developers are using. The platform team must fix the path, not enforce compliance.
What a golden path covers
Six components of a complete golden path
A golden path that only covers the scaffold and leaves the deployment to the developer is not a golden path — it is a starting template. A complete path covers the full journey from new service to observable production deployment.
Repository scaffold
The starting structure for a new service: directory layout, language runtime version, dependency management config, linting and formatting config, .gitignore. The developer names the service; everything else is pre-decided.
CI/CD pipeline template
A parameterized pipeline that runs tests, builds the container image, runs security scanning, and deploys to the target environment. The developer provides the service name and target environment; the pipeline handles the rest.
Container configuration
A Dockerfile or build pack configuration that produces a minimal, production-ready container image. Base image selection, layer caching strategy, and runtime configuration are pre-decided and maintained by the platform team.
Deployment manifests
Kubernetes manifests or infrastructure-as-code templates for deploying the service. Resource limits, health checks, horizontal pod autoscaler configuration, and network policies are pre-set with sensible defaults that can be overridden for exceptions.
Observability baseline
Default logging format, metrics instrumentation, and distributed tracing setup. A service deployed through the golden path is observable from day one without additional configuration from the application team.
Secrets management
A consistent pattern for accessing secrets at runtime — Vault agent injection, External Secrets Operator, or equivalent. No hardcoded credentials. No team-specific patterns. One approach the platform team maintains and secures.
Related concept
Paved road vs. golden path
"Paved road" and "golden path" are often used interchangeably, but they have a slight distinction in origin. A paved road is any well-maintained, well-documented path — the term emphasizes maintenance quality. A golden path is a specific path that the platform team has curated and actively promotes as the recommended default. Every golden path should be a paved road; not every paved road is explicitly a golden path.
In the Clouditive Foundations Framework, paved road compliance under pressure is a measurement signal for platform quality — specifically, whether developers follow the established paths when deadlines arrive or bypass them. The question that signal answers: does the golden path hold up when the stakes are high?
A golden path that developers bypass under deadline pressure is a path that was designed for normal conditions, not production conditions. Compliance under pressure is the real test. If it drops significantly when teams are under stress, the path has too much friction or too little reliability for high-stakes situations.
How Clouditive builds golden paths
Foundations Framework approach to golden path design
The Foundations Framework starts with the application team's perspective, not the platform team's. In the Horizon phase, the team maps where developers are spending their time and where the friction is. The golden paths designed in Blueprint address the specific friction points the application teams reported — not the platform team's hypothesis about what developers should want.
Every golden path in the Forge phase is validated against one question before it is considered complete: is this faster than the alternative? The validation is empirical — a developer who knows the manual process is timed going through it both ways. If the path does not win, it is revised before launch.
Post-launch, paved road compliance under pressure is tracked as part of the Cognitive Absorption measurement. If compliance drops during high-pressure periods (board demos, launch weeks, incident response), the path has a design problem the platform team is responsible for fixing.
Foundations Framework
The Foundations Framework covers golden path design as part of the Blueprint phase and tracks paved road compliance as a platform quality signal.
Read the Foundations FrameworkCommon questions
Golden path: direct answers
How do you build a golden path?
Start with the most common task your application teams perform — usually deploying a new service or a standard backend service scaffold. Interview the teams doing that task currently to understand where the friction is. Build the path to eliminate that friction specifically. Then measure whether the path is faster than the alternative. If the path is not faster, it will not be adopted voluntarily. Ship it to one team, gather feedback, improve, then expand.
What's the difference between a golden path and a template?
A template is a starting point — a repository scaffold with placeholders. A golden path is a maintained, opinionated end-to-end path through a capability: scaffold, CI/CD pipeline, deployment manifests, observability baseline, and secrets configuration. A template requires the developer to make decisions after cloning it. A golden path has already made the decisions — the developer fills in the service-specific values and gets a working, production-ready service.
How do you get developers to use golden paths?
The only reliable answer is making the path faster than the alternative. Mandating adoption produces compliance theater — teams use the path for the audit and do the real work outside it. Measure the time from zero to deployed service for each approach. If the path wins, adoption follows naturally. If it does not, fix the path before marketing it.
Build golden paths developers actually choose
The Foundations Framework starts with your developers' friction, not the platform team's roadmap.
Foundations Assessment diagnoses where your paths are broken. Platform Foundation builds the replacements.