Delivery
Golden paths
A golden path is an opinionated, maintained way to create, ship and observe a service. It should be the easy default, not a prison, and the test is whether a new hire can reach production in a day.
A golden path, sometimes called a paved road, is a supported way to do a common job. Creating a service, shipping it, observing it and meeting the security baseline are typical examples. It is golden because the platform team maintains it, with docs, upgrades and examples. It is not golden because it is mandatory for every outlier.
The big idea
Think of a city with a paved road between the main places. Most people take it, because it is fast and safe. Some people build their own track through the woods, and that is allowed, but they maintain it themselves. The paved road is only useful if it is the easiest way to go.
Walking through it
A service golden path usually bundles these pieces:
| Piece | What good looks like |
|---|---|
| Service template | A repository scaffold with the language runtime, a Dockerfile, a Makefile or Taskfile, and a README |
| CI/CD | A reusable workflow that tests, scans, signs and deploys to dev, staging and prod, with canary defaults |
| Runtime defaults | Resource requests, probes, PodDisruptionBudgets and HPA snippets |
| Observability | JSON logs to stdout, OpenTelemetry instrumentation, and dashboard and alert stubs |
| Security baseline | A non-root container, OIDC to the cloud, a secret-injection pattern, and a starter NetworkPolicy |
| Ownership metadata | A catalog entry with the team, the on-call schedule, the SLO link and the repository URL |
The test of a golden path is simple. A new hire should be able to take the template to a live URL on the company domain in less than a day, without opening tickets to three different teams. If they still need a week of tribal knowledge, the path is documentation theater.
Here is what that changes in practice. Before, a new service meant six tickets: repository, CI, IAM role, DNS, dashboard and deploy credentials. The median wait was about ten business days. After, a software template creates the repository, registers the catalog entry, and opens a pull request that provisions IAM through a Terraform module. The first merge deploys to a team namespace. Measured time to first deploy dropped to about two to four hours. That difference is the platform's product value.
Escape hatches matter too. Document how to run a non-standard runtime, such as a GPU job or a stateful cluster, and what support you give when someone leaves the path. Unsupported snowflakes are allowed. They own their own pages.
Common mistakes
- A path that exists only on paper. If the template is out of date, nobody uses it.
- Forcing everyone onto the path. Keep escape hatches with clear support boundaries.
- Forking the template quietly. If a team needs a change, file it as product feedback. If it must fork, plan to rejoin.
Check yourself
- A new hire needs a week of tribal knowledge to deploy. What does that tell you? The path is not complete. It is documentation theater until a newcomer can deploy without help.
- Why keep an escape hatch? Some workloads really are different. The path stays the default, and the exception is supported on purpose.
Key takeaways
- A golden path bundles templates, CI, runtime defaults, observability, security and ownership.
- The test is time to a live URL, measured in hours, not weeks.
- Keep the path the easiest default, with documented escape hatches.
Further learning
The platform as a whole is covered in platform engineering. The catalog side that makes ownership visible is in catalogs and portals.
Backstage documentation, what is BackstageWhat is Backstage? | Backstage Software Catalog and Developer Platformbackstage.ioRelated
Platform engineering
Internal developer platforms, golden paths and treating infrastructure as a product. Cut cognitive load without building a second Kubernetes.
Cognitive load and team types
Why product teams slow down when they must master cloud, CI and security themselves, and the Team Topologies vocabulary for splitting that work across team types.
Continuous integration and the software supply chain
Fast, trustworthy pipelines - build, test, artifact, scan and sign - plus DORA metrics and supply-chain controls that keep trunk green.