Golden paths are the single most impactful capability a platform engineering team can deliver. We have built over 30 golden paths across organisations ranging from 40-person startups to 800-engineer enterprises, and the pattern is consistent: teams that invest in well-designed golden paths see voluntary platform adoption rates above 80%, while those that skip them struggle to reach 20%.
Yet golden paths remain one of the most misunderstood concepts in platform engineering. They are often confused with rigid templates, conflated with guardrails, or reduced to a scaffolding wizard that runs once and is never updated. This guide explains what golden paths actually are, how to build them effectively, and provides concrete examples you can adapt for your organisation.
What is a golden path?
The term was popularised by Spotify Engineering, who defined golden paths as “the opinionated and supported path to build something.” Spotify emphasised that golden paths are not mandated routes but recommended ones — they represent the way the platform team thinks a task should be done, with full backing and maintenance.
Red Hat’s platform engineering documentation frames golden paths as “pre-configured, standardised templates or workflows that guide developers through the process of building, deploying, and managing applications.” The CNCF Platform Working Group similarly positions golden paths as a core capability of any internal developer platform.
In practical terms, when a developer follows a golden path, they should go from “I need a new microservice” to “it is running in staging with CI/CD, monitoring, logging, and security policies applied” — without opening a single ticket.
Why golden paths matter now
Gartner predicted that by 2026, 80% of large software engineering organisations would establish platform engineering teams. Yet research consistently shows that roughly 70% of platform initiatives fail to achieve meaningful adoption. The gap between having a platform and having developers actually use it is almost always a golden path problem.
When we assess platform maturity for clients, the first metric we look at is voluntary adoption rate. If fewer than 50% of teams are choosing the platform path over doing it themselves, the golden paths are either missing, poorly designed, or solving the wrong problems.
Golden paths vs paved roads vs guardrails vs railroads
The terminology in this space is inconsistent and often confusing. Google Cloud’s platform engineering guidance and articles from The New Stack have helped standardise the taxonomy, but you will still hear these terms used interchangeably. Here is how we distinguish them in practice.
| Concept | Definition | Developer freedom | Enforcement |
|---|---|---|---|
| Golden path | A recommended, opinionated, end-to-end workflow for a common task | High — developers choose to follow it | Optional |
| Paved road | A well-maintained, standardised route for delivery (often used synonymously with golden path) | High — similar to golden path | Optional |
| Guardrails | Policies and constraints that prevent unsafe or non-compliant actions | Medium — developers choose their route but within boundaries | Enforced |
| Railroads | Rigid, mandated workflows with no deviation allowed | Low — developers must follow the prescribed path | Strictly enforced |
Golden paths and paved roads are functionally the same concept. Some organisations, particularly those influenced by Netflix’s engineering culture, prefer “paved road.” Others, following Spotify’s lead, use “golden path.” The distinction is semantic, not substantive.
Guardrails are complementary to golden paths. A golden path might say “use this Terraform module to provision your database.” A guardrail says “all databases must be encrypted at rest, regardless of how you provision them.” Golden paths make the right thing easy; guardrails make the wrong thing hard.
Railroads are what golden paths become when platform teams forget the “optional” part. We have seen this anti-pattern repeatedly: a well-intentioned platform team mandates that all services must use their template, and within months developers find workarounds or simply ignore the platform altogether.
The relationship between DevOps, SRE, and platform engineering shapes how these concepts are applied. DevOps teams tend to focus on automation and CI/CD. SRE teams prioritise reliability and guardrails. Platform engineering teams own the golden paths that tie everything together.
The four qualities of an effective golden path
Through building golden paths across dozens of organisations, we have identified four non-negotiable qualities. These align closely with what Humanitec’s Score specification and PlatformEngineering.org advocate.
1. Optional, not mandated
A golden path must be something developers choose because it is better than the alternative, not because they have no other option. The moment you mandate a golden path, you create resentment and shadow IT. Developers will find workarounds, and you will lose the feedback loop that makes golden paths improve over time.
The target is greater than 80% voluntary adoption. If your golden path is genuinely better than the alternative, this is achievable. If it is not reaching that threshold, the path itself needs improvement — not a policy forcing people onto it.
2. Transparent, not opaque
Developers need to understand what the golden path does under the surface. If your service template provisions an EKS namespace, sets up an Argo CD Application, creates a Grafana dashboard, and configures PagerDuty alerts, all of that should be visible and inspectable.
Opaque golden paths breed distrust. Engineers want to know what resources are being created, what policies are being applied, and what happens when something goes wrong. Treat your golden path like open-source software: the code and configuration should be readable.
3. Extensible, not rigid
A golden path covers the common case. It should not try to cover every case. Developers need escape hatches — ways to extend, override, or customise specific parts of the path without abandoning the whole thing.
For example, a backend service golden path might default to PostgreSQL for the database. A team building a search service should be able to swap in Elasticsearch without having to rebuild everything from scratch.
4. Customisable, not one-size-fits-all
Different teams have different needs. A data engineering team’s golden path looks nothing like a frontend team’s golden path. Spotify recognised this early and built separate golden paths for backend services, client apps, data engineering, ML, web, and audio.
The mistake we see most often is trying to build one golden path that covers everything. Start with the most common use case (usually backend microservices) and expand from there.
What a golden path bundles together
A golden path is not a single tool or template. It is the integration of multiple concerns into a coherent, end-to-end experience. Here is what a well-designed golden path typically bundles.
Software templates and scaffolding
The starting point. A template generates the initial project structure, including application code scaffolding, Dockerfile, CI/CD pipeline configuration, Kubernetes manifests or Helm charts, and documentation stubs.
Tools like Backstage Software Templates, Cookiecutter, and Yeoman handle the scaffolding. The key is that the template produces a working, deployable service from the start — not a skeleton that requires hours of additional configuration.
Infrastructure as Code modules
The golden path should provision all required infrastructure automatically. This typically means Terraform modules or Pulumi components that create the database, message queue, storage bucket, DNS record, or whatever the service needs.
We have seen strong results with the pattern of wrapping organisation-specific defaults around community modules. For example, a golden path for provisioning an EKS cluster with Terraform might use the official terraform-aws-modules/eks module but with company-standard networking, logging, and security configurations baked in.
CI/CD pipeline configuration
Every golden path should include a working CI/CD pipeline. When a developer creates a new service from the template, the pipeline should be ready to build, test, scan, and deploy the service without any additional configuration.
For teams using GitOps with Helm and ArgoCD, the golden path generates the ArgoCD Application manifest alongside the service code, ensuring the deployment pipeline is wired up from day one.
Observability stack
A service without monitoring is a service waiting to fail silently. The golden path should include:
- Metrics: Pre-configured Prometheus scrape targets and standard dashboards
- Logging: Structured logging configuration with log aggregation
- Tracing: Distributed tracing instrumentation (OpenTelemetry is the current standard)
- Alerting: Default alert rules for latency, error rate, and saturation
Security and compliance
Security policies, network policies, RBAC configurations, secrets management, and vulnerability scanning should all be embedded in the golden path. Developers should not need to think about security separately — it should be a natural consequence of following the path.
Documentation
The golden path should generate initial documentation automatically: a README, API documentation stubs, runbook templates, and architecture decision records (ADRs). This ensures every service starts with baseline documentation rather than the typical “we will write docs later” approach (which means never).
Concrete golden path examples
Here are five golden paths we have built or helped clients build, with enough detail to be directly useful.
Example 1: Backend microservice (the most common golden path)
Trigger: Developer selects “Create Backend Service” in the internal developer portal.
What it does:
- Scaffolds a Go or Node.js service with health checks, graceful shutdown, and structured logging
- Creates a Git repository with branch protection rules
- Generates a Dockerfile following security best practices (non-root user, multi-stage build, minimal base image)
- Produces Helm charts with sane defaults for resource limits, HPA, PDBs, and network policies
- Configures a CI pipeline (GitHub Actions or Jenkins) that runs linting, unit tests, container scanning, and image push
- Creates an ArgoCD Application for automated deployment to staging
- Provisions a PostgreSQL database via Terraform with encryption, backups, and connection pooling
- Sets up Prometheus ServiceMonitor, Grafana dashboard, and PagerDuty integration
- Generates a README, API spec stub, and runbook template
Time to “hello world” in staging: Under 15 minutes.
Example 2: Kubernetes namespace provisioning
Trigger: Team lead requests a new namespace for their team via self-service form.
What it does:
- Creates a Kubernetes namespace with standardised labels and annotations
- Applies ResourceQuotas and LimitRanges based on team tier
- Configures RBAC roles and bindings tied to the organisation’s identity provider
- Applies NetworkPolicies (default deny ingress, allow egress to internal DNS and specific external endpoints)
- Sets up namespace-level monitoring with Prometheus rules
- Creates a corresponding ArgoCD project scoped to the namespace
Why this matters: Without this golden path, namespace creation typically requires a ticket to the platform team, a 1-3 day wait, and inconsistent configuration. With it, teams self-serve in minutes with guaranteed compliance.
Example 3: Data pipeline
Trigger: Data engineer selects “Create Data Pipeline” in the developer portal.
What it does:
- Scaffolds an Apache Airflow DAG or dbt project with organisation standards
- Configures connections to data warehouses and object storage
- Sets up data quality checks and alerting
- Creates CI pipeline for testing DAGs/models before deployment
- Provisions required infrastructure (S3 buckets, IAM roles, database schemas)
- Configures cost tagging for FinOps tracking
Example 4: Infrastructure provisioning (self-service)
Trigger: Developer requests a specific cloud resource (RDS instance, S3 bucket, ElastiCache cluster) via the developer portal.
What it does:
- Generates a Terraform configuration using approved modules with organisation defaults
- Opens a pull request to the infrastructure repository for review
- Runs Terraform plan and posts the output to the PR
- After approval, applies the configuration via CI/CD
- Registers the resource in the service catalogue with ownership metadata
This pattern integrates well with the broader DevOps automation strategy by eliminating manual infrastructure provisioning while maintaining governance through code review.
Example 5: Frontend application
Trigger: Developer selects “Create Frontend App” in the developer portal.
What it does:
- Scaffolds a React or Next.js application with the organisation’s design system pre-installed
- Configures CDN deployment (CloudFront or Cloudflare)
- Sets up preview environments for pull requests
- Configures performance monitoring (Core Web Vitals tracking)
- Applies Content Security Policy headers and security best practices
Tools for building golden paths
The tooling landscape for golden paths has matured significantly. Here are the categories and leading options.
Internal developer portals
- Backstage (Spotify, open source): The most widely adopted portal. Software Templates are the primary mechanism for golden paths. Strong plugin ecosystem and community.
- Port: SaaS-based portal with self-service actions and a flexible data model. Lower operational overhead than Backstage.
- Cortex: Focused on service maturity and scorecards alongside golden paths.
Platform orchestration
- Humanitec: Platform Orchestrator that uses Score workload specifications. Strong on dynamic configuration management.
- Kratix: Kubernetes-native framework for building platforms as a product. Uses Promises (custom resource definitions) to define golden paths.
Infrastructure as Code
- Terraform: Still the most widely used IaC tool. Module registries work well as golden path building blocks.
- Pulumi: IaC using general-purpose programming languages. Component resources are excellent for encapsulating golden path infrastructure.
- Crossplane: Kubernetes-native IaC. Compositions function similarly to golden path templates for infrastructure.
GitOps and deployment
- ArgoCD: Pull-based GitOps controller. ApplicationSets can auto-generate deployments from golden path templates.
- Helm: Package manager for Kubernetes. Starter charts serve as golden path templates for Kubernetes workloads.
Template engines
- Backstage Software Templates: YAML-based templates with built-in actions for Git, CI/CD, and infrastructure provisioning.
- Cookiecutter: Python-based project templating. Simple and effective for teams not using Backstage.
- AWS Proton: AWS-native service for defining and deploying golden path templates (called “environment templates” and “service templates” in AWS terminology). The AWS Prescriptive Guidance documentation provides detailed examples of golden path implementation patterns.
How to build your first golden path: a step-by-step approach
Step 1: Identify the highest-value use case
Do not start with a grand vision. Start with the single task that causes the most friction for developers. In our experience, this is almost always “create a new backend service and get it running in a non-production environment.”
Interview five to ten developers. Ask them: “What did you do the last time you needed to create a new service? How long did it take? What was painful?” The answers will tell you exactly where to start.
Step 2: Map the current workflow
Document every step of the current process, including the manual ones. Who do developers need to talk to? What tickets do they file? What do they copy-paste from existing services? Where do they get stuck?
This map becomes your golden path blueprint. Every manual step is a candidate for automation.
Step 3: Build an MVP (not a masterpiece)
Your first golden path should be embarrassingly simple. A Cookiecutter template that generates a service scaffold with a working Dockerfile and a basic CI pipeline is infinitely more valuable than a grand Backstage portal that is still “coming soon.”
Target: a developer can go from zero to a deployed service in under one hour. That is your MVP benchmark.
Step 4: Treat it as a product
Golden paths need product management. That means:
- User research: Regular interviews with developers who use (and do not use) the golden path
- Metrics: Track adoption rate, time-to-production, support ticket volume, and developer satisfaction (via surveys)
- Roadmap: Prioritise improvements based on usage data and feedback
- Documentation: Maintain clear, up-to-date guides and examples
- Support: Dedicated Slack channel or similar for questions and feedback
Step 5: Prioritise Day 2-50 over Day 1
This is the most important lesson we have learned across 30+ golden path implementations. Day 1 (initial service creation) gets all the attention, but Day 2-50 (adding a database, changing a deployment strategy, onboarding a new team member, debugging a production issue) is where developers spend 90% of their time.
A golden path that makes Day 1 fast but leaves Day 2 to the developer is incomplete. Your golden path should evolve to cover:
- Adding dependencies (databases, caches, message queues)
- Changing deployment configuration
- Scaling and performance tuning
- Incident response and debugging
- Decommissioning services
Step 6: Expand deliberately
Once your first golden path has strong adoption (aim for 80%+), expand to the next use case. For most organisations, the progression looks like:
- Backend microservice
- Frontend application
- Data pipeline
- Infrastructure self-service
- ML model deployment
Do not try to build all five simultaneously. Each golden path is a product with its own user base, and stretching across too many at once is a reliable way to deliver mediocre results for everyone.
Anti-patterns to avoid
We have seen these mistakes repeatedly. Each one can undermine an otherwise sound platform engineering effort.
Over-abstraction
Hiding too much complexity from developers creates a “black box” problem. When something goes wrong (and it will), developers cannot debug it because they do not understand what the golden path created. Keep the abstraction layer thin and transparent.
Over-prioritising Day 1
Pouring all your effort into a beautiful “create new service” wizard while neglecting the ongoing operational experience. The scaffolding wizard runs once; the deployment pipeline, monitoring, and debugging tools are used daily.
Treating golden paths as a project
A project has a start date, end date, and final delivery. Golden paths are products that require continuous investment. The moment you “finish” a golden path project and move the team to something else, the golden path begins to rot.
Stretching too thin
Trying to build golden paths for every possible use case simultaneously. You end up with five half-finished paths instead of one excellent one. Start narrow, prove value, then expand.
Mandating instead of attracting
Making the golden path mandatory rather than making it so good that developers choose it voluntarily. This is the fastest way to create resentment and shadow IT. If developers are going around your golden path, that is feedback about the quality of the path, not the behaviour of the developers.
Ignoring the feedback loop
Building a golden path based on assumptions about what developers need, then not measuring adoption or collecting feedback. Golden paths are only valuable if developers use them, and developers will only use them if the paths solve real problems.
Measuring golden path success
Track these metrics to understand whether your golden paths are delivering value.
| Metric | Target | What it tells you |
|---|---|---|
| Voluntary adoption rate | >80% | Whether the golden path is genuinely better than alternatives |
| Time to “hello world” | <1 hour | Whether Day 1 friction has been eliminated |
| Support ticket volume | Decreasing trend | Whether the golden path reduces operational burden |
| Developer satisfaction (NPS/survey) | >40 NPS | Whether developers find the path useful |
| Compliance rate | >95% | Whether services created via golden path meet security/compliance standards |
| Time to production (new service) | <1 day | End-to-end lead time from idea to running in production |
The most telling metric is voluntary adoption rate. If your golden path is optional and 80%+ of teams choose to use it, you have succeeded. If adoption is below 50%, something is wrong with the path itself — not with the developers who are avoiding it.
Where golden paths fit in the platform engineering maturity model
Golden paths are not a starting point. They sit at the intersection of multiple capabilities that need to exist first:
- Infrastructure automation: You cannot build a golden path for service creation if your infrastructure is not automated. IaC (Terraform, Pulumi, Crossplane) is a prerequisite.
- CI/CD pipelines: Golden paths generate pipeline configuration, so you need a pipeline platform in place.
- Observability: Golden paths wire services into monitoring, so your observability stack must exist.
- Security policies: Golden paths apply security controls, so those controls need to be defined.
If you are still building these foundations, focus there first. Golden paths amplify existing capabilities — they do not replace the need for them.
Build Golden Paths That Developers Actually Use
Golden paths are the difference between an internal developer platform that transforms engineering productivity and one that collects dust. But building effective golden paths requires deep expertise in infrastructure automation, CI/CD, Kubernetes, observability, and developer experience design.
Our team provides comprehensive platform engineering services to help you:
- Design and build golden paths tailored to your organisation’s technology stack and developer workflows
- Implement internal developer portals using Backstage, Port, or custom solutions with self-service capabilities
- Establish platform-as-a-product practices with metrics, feedback loops, and continuous improvement
We have helped organisations reduce time-to-production from weeks to under an hour, achieve 80%+ voluntary platform adoption, and eliminate thousands of manual infrastructure tickets per year.