What is a golden path?
Engineering culture and software practice
A golden path is a supported, opinionated default route through building and running software: the stack, tooling and steps a team is expected to take unless it has a reason not to, made easy enough that taking it is the path of least resistance. Netflix engineering popularised the paved-road version in the mid-2010s and Spotify engineering named the golden path around 2020. The point is that it is a default, not a mandate; the alternative route stays open but unsupported.
What this means
Left to themselves, every team solves the same setup problems differently: how to build, test, deploy, monitor and secure a service. Ten teams end up with ten ways of deploying, none of them documented. A golden path is the deliberate fix: one recommended way to do a common job, packaged so that following it is easier than not.
The name captures the idea nicely. A golden path is well lit and paved; you can still leave it and strike out on your own, but then you carry the map and the consequences yourself. Spotify borrowed the phrase from a science-fiction novel, and Netflix used the plainer image of a paved road, but the concept is the same.
It has a name because it describes an organisational device, not just a document. A golden path is the combination of sensible defaults, a working example, clear instructions and someone who keeps it current, arranged so that the right way to build something is also the easy way.
Why it matters
The cost of not having a golden path is quiet but large. Every new service reinvents decisions that have been made many times before. Onboarding is slow because the only way to learn how things are done is to ask a colleague. Security and reliability are inconsistent because each team applies its own standard, or none. The waste does not show up as a single line in a budget, which is exactly why it persists.
A golden path attacks that waste by reducing the mental load a delivery team carries. The book Team Topologies frames this directly: a platform exists to reduce the cognitive load on the teams building products, so they can spend their attention on the problem that is actually theirs. When the routine choices are made once, well, and offered as a default, people get back the time they were spending on undifferentiated setup.
The idea has become sharper with AI. The AI version of a golden path is the approved model, the approved route for getting data to it, and the approved review step before anything ships. Without that supported route, people do not stop using AI; they quietly use whatever tool they like, which is how shadow AI takes hold. A golden path is the constructive answer to that problem: make the safe, sanctioned way the easy way, so the unsupported way is the one that takes more effort.
How it works
Where the term came from
Two company origins are worth stating once as fact. Netflix engineering popularised the paved-road framing in the mid-2010s, describing a set of tools and practices formally supported by central teams that developers were encouraged, but not forced, to adopt; teams could leave the paved road but then owned the consequences. Spotify engineering named the golden path in a 2020 engineering blog post, describing it as the opinionated and supported way to build something, with a step-by-step tutorial to walk a new engineer through it. Spotify traced the concept back to an internal hack-week project some years earlier and borrowed the name from Frank Herbert's Dune novels.
The idea was then generalised by the platform-engineering movement and by the book Team Topologies (Skelton and Pais, IT Revolution Press, 2019), which frames a supported platform as a way to reduce the cognitive load a stream-aligned team carries. The industry's main foundation body, the Cloud Native Computing Foundation, uses the term directly in its platforms white paper, describing a golden path as a bundle of an initial project template and documentation, and elsewhere as guardrails, not gates. A 2026 peer-reviewed literature review in Frontiers in Computer Science reaches the same conclusion, advising that golden paths be designed as enablers instead of mandates.
What a golden path contains
A golden path is more than a wiki page. In a mature form it includes sensible defaults for the stack and tooling; a template or scaffold that creates a new project already wired for building, testing, deploying and monitoring; documentation that explains the steps; at least one worked example that actually runs; and, crucially, a named owner who keeps all of that current. The CNCF describes exactly this bundle of template plus documentation. Remove the owner and the whole thing decays into folklore.
Why it must stay a default, not a mandate
The defining feature of a golden path is that it is optional. Teams are steered towards it by making it the easiest route, not compelled onto it by rule. This matters for two reasons. First, mandates breed resentment and workarounds; the DevOps research summarised in that Frontiers review found that platforms imposed top-down produced lower satisfaction than those adopted because they were genuinely useful. Second, a mandate freezes the path: if nobody is allowed off it, nobody discovers the better way that should replace it. A golden path that becomes a mandate stops being a golden path and becomes a cage, and people either comply grudgingly or route around it in the dark.
Maintenance and decay
An unmaintained golden path is worse than none, because it looks authoritative while quietly leading people to outdated tools and broken steps. The Spotify account is candid about this: the tutorial has to reflect the actual path, and when a tool is swapped the documentation must change at the same time. That requires ownership and continuous feedback, which is why Spotify aimed its paths at new hires, whose fresh confusion is the best test of whether the path still works. Treat a golden path as a living product with an owner, or expect it to rot.
The AI version and shadow AI
The same pattern maps directly onto AI-assisted work. A golden path for AI names the approved model or service, the sanctioned way to connect it to data, and the review step required before output is trusted or shipped. When that route exists and is easy, people use it. When it does not, they reach for whatever consumer tool is to hand, and the organisation loses sight of what data is going where. The absence of a supported route is the cause of shadow AI, not the appetite for the tools; a good golden path removes the excuse.
Examples
A software team of eight at a scale-up is tired of every new service being set up differently. They agree a single default: one language, one deployment method, one monitoring tool. They capture it as a template that generates a new service ready to build and deploy, plus a short written guide and one example service that genuinely runs. New joiners ship their first change in days instead of weeks. There is no platform team; the golden path is simply a written default and a worked example, owned by one senior engineer.
A council department with no dedicated platform team wants consistency across the small tools it commissions. Rather than mandate anything, it writes down a recommended approach and points suppliers at a public-sector reference, using the GOV.UK Service Manual's guidance on reusing assured common platforms so that teams need not re-test what has already been assured. The recommendation is a default, not a rule, but because it is the easy option most suppliers follow it.
A charity introduces AI assistants for casework summaries. Worried about staff pasting sensitive data into random tools, it sets up a golden path: one approved assistant, a sanctioned way to feed it case data, and a required human check before anything is used with a client. It makes that route the simplest one available. Usage of unapproved tools falls, not because it is banned, but because the supported way is now the least effort.
Common misunderstandings
The first misconception is that a golden path is a mandate. It is a default. Teams keep the freedom to go off it; they simply forgo the support and take on the consequences, which is the whole design.
The second is that you need a platform team to have one. In a small organisation a golden path is usually just a written default plus one worked example and a named owner. The device scales down.
The third is that a golden path is the same as simply choosing boring technology. This is not the same as choose boring technology, which is a decision rule about spending novelty sparingly. A golden path institutionalises such choices into a supported, ready-to-use route, but the two ideas operate at different levels: one is a principle, the other is the packaged default that embodies it.
The fourth is that once written it is finished. An unmaintained golden path decays into misleading folklore and becomes worse than having none, because it still looks authoritative while steering people wrong.
The fifth is that it exists to control developers. Its purpose is to reduce their cognitive load, freeing attention for the work that is genuinely theirs, not to police them.
Risks and boundaries
The clearest failure mode is the golden path that hardens into a mandate. Once it is compulsory, it stops attracting the feedback that keeps it good, and it invites either grudging compliance or hidden workarounds. The research consensus, echoed in the CNCF material and the Frontiers review, is that these paths work as enablers and fail as gates.
The second failure mode is neglect. A path without an owner and a feedback loop drifts out of date, and because it carries an air of authority it can do real harm by sending people down broken or outdated routes. It should be resourced as a product, however small.
The term is misapplied when any standard or policy document is relabelled a golden path. The distinguishing features are that it is genuinely supported, genuinely easier than the alternative, and genuinely optional. A policy that is mandatory, unsupported or harder to follow than going it alone is something else. There is also a live debate about how opinionated a path should be and how many exceptions to allow; that balance is a judgement each organisation makes, not a settled rule.
What to do next
Pick one common, repeated task, such as standing up a new service or running an AI-assisted process, and define a single supported default for it. Start narrow; one good path beats ten aspirations.
Package that default as more than a document: a template or scaffold, short instructions, and one worked example that actually runs. Name an owner who is responsible for keeping it current, even if that is a part of one person's role.
Make the path the easy option rather than a rule. Steer people onto it by reducing friction, and leave the alternative open but unsupported, so adoption is a signal that the path is genuinely useful.
Build in a feedback loop. Point new joiners at the path first, because their confusion is the fastest way to find where it is out of date, and fix it promptly when they stumble.
For AI specifically, treat the golden path as your main defence against shadow use: define the approved model, the approved data route and the required review step, and make that route the least effort available.
FAQs
Where does the term golden path come from?
Spotify engineering named it in a 2020 blog post, borrowing the phrase from Frank Herbert's Dune novels. Netflix had earlier popularised the equivalent paved road.
Is a golden path the same as a paved road?
Effectively yes. Netflix uses paved road and Spotify uses golden path for the same idea: a supported, opinionated default that teams are encouraged but not forced to take.
Does a golden path force teams to comply?
No. It is a default, not a mandate. Teams can leave it, but they give up the support and take on the maintenance and risk themselves.
Do we need a platform team to build one?
No. In a small organisation a golden path can be a written default, one worked example and a named owner. It scales down to very modest setups.
What makes a golden path fail?
Turning it into a mandate, which kills feedback, or failing to maintain it, which lets it decay into misleading and outdated guidance.
How does this relate to shadow AI?
Shadow AI usually arises because there is no supported route. A golden path that names the approved model, data route and review step, and makes them easy, removes the reason to go elsewhere.
How is it different from choosing boring technology?
Choosing boring technology is a principle about spending novelty sparingly. A golden path is the packaged, supported default that puts such a principle into practice.
How do we keep it current?
Give it an owner, aim it at new joiners whose confusion reveals gaps, and update the documentation whenever the underlying tools change.