Every platform engineer eventually faces the same fundamental tension: how do you provide enough structure to maintain quality, security, and consistency across your engineering organisation, while still giving developers the freedom to move fast and make their own technical decisions? The answer, I’ve found, lies in what the industry has started calling “golden paths” — and getting them right is both an art and a science.
At the enterprise insurance company where I lead platform engineering, building golden paths has been central to our strategy for transforming developer experience. This post shares what we’ve built, what we’ve learned, and why I believe golden paths are one of the most impactful things a platform team can invest in.
What Is a Golden Path?
The term “golden path” (sometimes called “paved road” or “happy path”) refers to a recommended, well-supported route for accomplishing a common software delivery task. It’s the way the platform team has designed for you to do something — create a new service, deploy to production, manage secrets, configure monitoring — that comes with built-in best practices, sensible defaults, and automated guardrails.
Crucially, a golden path is not a mandate. Developers can deviate if they have a good reason. But the golden path should be so convenient, so well-maintained, and so obviously the right choice that deviating feels like unnecessary effort rather than an escape from bureaucracy.
I think of it like a well-maintained highway. You could drive through back roads to get to your destination, and sometimes there are legitimate reasons to do so. But the highway is faster, safer, better-lit, and has roadside assistance if something goes wrong. Most of the time, taking the highway is the obvious choice.
Why Golden Paths Matter
The case for golden paths becomes clear when you look at what happens without them.
In organisations without golden paths, every team makes their own decisions about how to structure repositories, build CI/CD pipelines, manage secrets, configure monitoring, and deploy to production. This leads to a combinatorial explosion of approaches. One team uses Terraform for infrastructure; another uses ARM templates; a third has a collection of shell scripts. One team deploys with Helm; another uses raw Kubernetes manifests; a third has a custom deployment script that only one person understands.
This diversity isn’t just an aesthetic problem — it creates real costs:
- Cognitive load: Engineers moving between teams have to learn entirely new toolchains and conventions
- Support burden: The platform team has to understand and support every variant
- Security gaps: Without standardised approaches, security practices are applied inconsistently
- Slow onboarding: New joiners spend weeks understanding team-specific tooling before they can be productive
- Incident response: Debugging is harder when every service is configured differently
Golden paths address all of these issues by channelling the majority of work through well-understood, well-supported patterns. They reduce cognitive load, make support tractable, enforce security practices by default, accelerate onboarding, and simplify incident response.
The Balance: Standardisation vs Flexibility
This is where many platform teams get it wrong, and I’ll admit we made this mistake early on too. The temptation is to make golden paths mandatory — to lock down everything and force all teams onto the same toolchain. This feels efficient from the platform team’s perspective, but it’s counterproductive.
Developers resist mandates, and for good reason. Every team has unique requirements, and there are always legitimate edge cases that don’t fit neatly into a standardised pattern. When you make golden paths mandatory, two things happen: first, developers spend energy fighting the platform instead of using it; second, the platform team becomes a bottleneck, fielding endless exception requests.
The approach that’s worked for us is what I call “strong defaults with escape hatches.” The golden path is the default, and it’s designed to cover 80–90% of use cases out of the box. For the remaining 10–20%, developers can deviate — but they take on the responsibility of maintaining their custom approach, and they don’t get the same level of platform team support.
This creates the right incentive structure. Teams stay on the golden path because it’s easier, not because they’re forced to. And when a team does deviate, it’s usually because they have a genuinely novel requirement — which often feeds back into improving the golden path for everyone.
Components of Our Golden Path
Let me walk through the concrete components of the golden path we’ve built.
Repository Templates
Every new service starts from a repository template. We maintain templates for our primary tech stacks — Java Spring Boot, Node.js, and Python — and each template includes:
- A standardised project structure with clear separation of concerns
- A pre-configured
Dockerfileoptimised for the tech stack (multi-stage builds, non-root users, layer caching) - A
Makefilewith standard targets (build,test,lint,docker-build,docker-push) - Health check endpoints (
/health/live,/health/ready) pre-wired - Prometheus metrics endpoint (
/metrics) with standard application metrics - Structured logging configuration (JSON format, correlation IDs)
- A starter
README.mdwith sections for architecture, local development, and deployment - A pre-configured CI/CD pipeline definition
These templates are maintained as Backstage software templates, so developers create new services through our Internal Developer Portal. The template collects minimal inputs — service name, team ownership, tech stack — and scaffolds everything automatically.
The templates encode years of hard-won knowledge. That Dockerfile isn’t just a FROM and a COPY — it’s the result of debugging countless image build issues, optimising for security scanners, and ensuring consistent behaviour across environments. By encoding this knowledge in templates, we ensure every team benefits from it without having to learn the lessons themselves.
CI/CD Pipelines
Our golden path CI/CD pipeline is implemented as a shared Azure DevOps pipeline template. Individual services reference the template and provide minimal configuration (primarily just the service name and deployment targets).
The pipeline includes the following stages:
Build & Test: Compile the application, run unit tests, and generate code coverage reports. We enforce a minimum coverage threshold — not because we believe coverage is a perfect quality metric, but because it prevents the common failure mode of services shipping with zero tests.
Security Scanning: This is where the golden path really pays for itself. Every build goes through:
- Static Application Security Testing (SAST) via SonarQube and Mend SAST — both tools are used in combination to provide comprehensive static analysis coverage, with SonarQube focusing on code quality and common vulnerability patterns, and Mend SAST providing deeper security-focused analysis including identification of vulnerable open-source components
- Dependency vulnerability scanning (checking for known CVEs in third-party libraries)
- Container image scanning via Trivy (checking the base image and installed packages)
- Secrets detection (scanning for accidentally committed credentials)
If we left security scanning to individual teams, some would do it thoroughly, others would skip it, and coverage would be inconsistent. By embedding it in the golden path pipeline, every service gets the same security baseline automatically.
Container Build & Push: The Docker image is built and pushed to our Azure Container Registry. Images are tagged with the Git commit SHA and the build number, ensuring traceability from deployment back to source code.
Deployment: We use Helm for deploying to AKS. The golden path includes a base Helm chart that encodes our deployment standards — resource requests and limits, pod disruption budgets, anti-affinity rules, network policies, and security contexts. Service-specific values are kept minimal.
Deployments follow a progressive model: automatic deployment to development, manual approval gate for staging, and manual approval with change management integration for production.
Deployment Guardrails
Golden paths aren’t just about making the right thing easy — they’re also about making the wrong thing hard. We’ve implemented several guardrails that prevent common failure modes:
Resource limits are mandatory. Every container must declare CPU and memory requests and limits. Our base Helm chart sets sensible defaults, and the admission controller rejects deployments without them. This prevents the classic “runaway pod consuming all cluster resources” scenario.
Pod disruption budgets are enforced. Production services must have a PDB that ensures at least one replica remains available during voluntary disruptions (node drains, cluster upgrades). This is set in the base chart and can’t be overridden to zero.
Network policies are default-deny. Each namespace has a default-deny ingress policy, and services must explicitly declare their network dependencies. This is more restrictive than many teams are used to, but it’s dramatically improved our security posture.
Image provenance is verified. Only images from our internal registry can be deployed to production clusters. This prevents teams from pulling arbitrary images from Docker Hub and ensures all images have passed our scanning pipeline.
Observability
The golden path includes built-in observability powered by Dynatrace that developers get for free:
- Metrics: The Dynatrace Operator automatically instruments all pods deployed via the golden path, collecting infrastructure and application metrics without requiring any code changes. Dynatrace dashboards are automatically provisioned for each service, providing real-time visibility into performance, throughput, and resource utilisation.
- Logging: Centralised log ingestion through Dynatrace captures logs from all golden path services, with full-text search, log analytics, and automatic correlation with distributed traces and metrics. The application templates configure structured JSON logging with correlation IDs that Dynatrace uses for end-to-end trace context.
- Distributed Tracing: Dynatrace’s automatic tracing captures end-to-end request flows across services, powered by its Davis AI engine for intelligent root cause analysis when issues occur.
- Alerting: Dynatrace’s anomaly detection automatically baselines service behaviour and alerts on deviations — covering high error rates, latency spikes, pod restarts, and resource exhaustion. Teams can add custom alerts through Dynatrace, but the intelligent baseline alerting is there from day one.
When a developer creates a new service through our golden path, they get full Dynatrace observability — dashboards, alerting, distributed tracing, and log analytics — before they write their first line of business logic. This is a huge shift from the old world where teams would launch a service and then spend weeks setting up monitoring after the first incident.
Self-Service and the Developer Portal
The golden path is delivered through our Internal Developer Portal (built on Backstage). This is important because a golden path that lives in a wiki document is effectively invisible. It needs to be embedded in the tools developers actually use.
When a developer wants to create a new service, they don’t read a document about the golden path — they go to the portal, select a template, fill in a few fields, and the golden path is applied automatically. The path isn’t a policy to follow; it’s a workflow to execute.
We’ve extended this self-service model beyond initial service creation:
- Sandbox environments: Developers can spin up isolated environments for testing through the portal, with all golden path standards applied automatically
- Feature toggles: Teams can create and manage feature flags through a portal template, integrated with our feature flag service
- Secret provisioning: New secrets are provisioned through the portal with automatic Key Vault integration and RBAC configuration
Every self-service capability reinforces the golden path. The more developers use the portal, the more consistently our standards are applied, and the less time the platform team spends on manual provisioning.
Measuring Success
How do you know your golden path is working? We track several metrics:
Adoption rate: What percentage of new services use the golden path? For us, this is currently around 90%. The remaining 10% are typically services with unusual requirements (data pipelines, ML workloads) where our templates don’t apply directly. We’re working on extending golden path coverage to these use cases.
Time to production: How long does it take from “I have an idea for a service” to “it’s running in production”? Before the golden path, this was typically 3–4 weeks. Now it’s 2–3 days for a simple service, with most of that time spent on code review and business logic rather than infrastructure and tooling.
Security compliance: What percentage of services pass our security scanning without intervention? This has improved from roughly 60% to over 95% since embedding security scanning in the golden path pipeline.
Developer satisfaction: We run quarterly developer surveys, and satisfaction with platform tooling has improved significantly since introducing golden paths. More importantly, the qualitative feedback has shifted from “I can’t do X” to “I wish the golden path also covered Y” — which is a healthy sign that developers see the golden path as a tool rather than a constraint.
Deviation rate: How often do teams deviate from the golden path? A small amount of deviation is healthy — it indicates the golden path is voluntary, not mandatory. A high deviation rate suggests the golden path doesn’t cover enough use cases or isn’t convenient enough.
The Cultural Shift
Building golden paths is ultimately a cultural exercise as much as a technical one. It requires the platform team to think like a product team — understanding your users (developers), their needs, and their pain points, and building solutions that they actually want to use.
This is a significant mindset shift for infrastructure teams that are accustomed to defining standards and enforcing compliance. Instead of saying “you must do it this way,” you’re saying “we’ve built the best way to do this — here it is, and it’s free.” Instead of gating deployments, you’re paving roads.
The hardest part of this cultural shift is accepting that some teams will deviate, and that’s okay. If your golden path only works when it’s mandatory, it’s not a golden path — it’s a chokepoint. The goal is to make the golden path so good that deviation is rare, not to make deviation impossible.
I’ve also found that involving developers in the design of golden paths dramatically improves both the quality and adoption. We run regular feedback sessions where development teams tell us what’s working, what’s not, and what they wish existed. Some of our best golden path improvements have come from developer suggestions.
Practical Advice for Getting Started
If you’re starting to build golden paths at your organisation, here’s what I’d recommend:
Start with the highest-friction activity. For us, it was creating new services. For your organisation, it might be deploying to production, or managing secrets, or configuring monitoring. Find the thing that developers complain about most and build a golden path for that first.
Make it work end-to-end before making it perfect. Your first golden path won’t be polished. That’s fine. Get something working that covers the complete workflow, then iterate based on feedback. A rough golden path that works is infinitely better than a perfect golden path that’s still in design.
Measure before and after. Quantify the current pain — how long does it take, how many steps, how many tickets, how much waiting? Then measure again after introducing the golden path. These numbers are essential for justifying continued investment.
Don’t build golden paths for edge cases. If only two teams need a specific workflow, it’s not a golden path candidate. Focus on the workflows that the majority of teams use. The edge cases can be handled with custom approaches.
Iterate continuously. A golden path that isn’t evolving is dying. Schedule regular reviews, collect feedback, and keep improving. The platform landscape changes, new tools emerge, and developer needs evolve. Your golden paths should evolve with them.
Golden paths are one of the most powerful concepts in platform engineering. They transform the platform team from a bottleneck into an accelerator, and they give developers a fast, safe, well-lit road to production. Building them takes effort, but the payoff — in velocity, quality, and developer satisfaction — is enormous.