Golden path

A golden path is the supported, well-lit route for a common task. The usual example is creating a new service: the developer picks a template, and the platform gives them a repository, a pipeline, a deployed service and dashboards. No ticket, no copying an old project and hoping it still works.

Spotify popularised the term in an engineering post about using golden paths to reduce fragmentation across their software ecosystem: How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem.

What a path looks like

1. Pick a template. A service, a cron job or an API.
2. Repository and pipeline. Created for you and already working: build, test, scan and push.
3. Deployed with dashboards. Running in an environment with metrics, logs and alerts wired up.

The developer's first commit already goes through the real pipeline and shows up on real dashboards.

Principles that keep a path useful

• Optional, not mandatory. A good path wins because it is the easiest option. If it is forced, people work around it and you lose the feedback.
• Opinionated defaults. One language version, one pipeline shape, one way to deploy. Choice is what the path removes.
• A way out. Teams with unusual needs can step off the path, and they know what they give up.
• Owned and versioned. Someone owns the templates, and updating a template has a way to reach the services built from it.

How to tell it is working

Measure how many new services start from the path, how long it takes from the first commit to production, and what developers say. If developers still need a ticket for the common case, the path is not finished.

Where it fits

A golden path is the most visible part of an internal developer platform. Tools such as Backstage are a common way to offer the templates, but the idea does not depend on the tool.

Next

• Back to the learning path
• Platform engineering vs DevOps vs SRE

Sources

• How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem (Spotify Engineering)
• Backstage documentation