Golden paths: standards that don't slow anyone down

Every company wants standards. Same pipeline structure, same security checks, same logging format, same way to deploy. And every developer has been on the receiving end of standards that felt like paperwork: a forty-page wiki, a checklist, a review board that meets on Thursdays.

The idea is that standards should feel like a shortcut, not a barrier.

Roads, guardrails and gates

I find it useful to think about three ways to guide people:

• Gates stop you until someone approves. "Submit a ticket and wait for the architecture review."
• Guardrails let you move freely but stop you before you fall off a cliff. "You can deploy anything, but not a container running as root."
• Paved roads (golden paths) make one way so convenient that most people take it voluntarily.

Good platforms use a lot of paved roads, a few guardrails, and as few gates as possible.

If people need to be forced onto your golden path, it isn't golden. It's just a path.

A new service in ten minutes

From a developer's perspective, a good golden path looks like this:

1. Open the template (a GitHub template, a Backstage form, or a CLI command).
2. Enter a service name and owning team.
3. Get a repository with working code, tests, a Dockerfile and a pipeline.
4. Push. The pipeline builds, scans and deploys to a test environment.
5. Logs, metrics, dashboards and basic alerts are already there.

The developer didn't read a wiki page about logging standards. The template simply does logging the right way. They didn't configure security scanning. The pipeline includes it. The standard is baked in.

What goes into a path

The best candidates are things every service needs, that are easy to get wrong:

• Build and deployment pipelines
• Container base images
• Health checks, resource requests and limits
• Logging format, metrics and tracing setup
• Security scanning and secret handling
• Ownership and documentation (a catalog entry, a README skeleton)

Don't try to standardise everything. Leave the actual product code alone. Developers should choose their own libraries and architecture inside the service.

When people need to leave the path

Teams will always have unusual needs — different languages, GPU workloads, or odd databases. If your golden path is the only option, those teams will either be stuck or quietly find workarounds you don't know about.

So build escape hatches on purpose:

• Allow teams to override parts of the template, not just all or nothing.
• Document what they lose when they leave the path (for example, "you'll need to set up your own alerts").
• Watch where people leave. If many teams leave at the same point, that's a signal to extend the path.

Keeping templates up to date

The hidden issue with templates is that once a service is created, it's a copy. If you improve the template later, older services don't automatically get those improvements.

A few ways to handle that:

• Keep shared logic out of each repo: reusable pipeline workflows, shared Helm charts, base images. Services reference a version instead of copying the content.
• Use Renovate or Dependabot to open pull requests when a new version of the shared pieces is released.
• Version your templates and keep a short changelog so teams know what they're missing.

So, are golden paths worth it?

Very much. They're how a small platform team can raise the quality of dozens of services without reviewing every one. Developers get speed, the organisation gets consistency, and nobody has to read the forty-page wiki.

My take: make the right way the easiest way, keep a door open for the exceptions, and listen when people use it.

— Desly