"We already have a template" is where this usually starts
Most platform teams at this stage have something: a starter repo with a Dockerfile, maybe a sample GitHub Actions workflow, a Helm chart someone copied from the last Application and cleaned up. New Applications clone it and go.
What the template doesn't answer: how does this Application authenticate to Google Cloud? What gets scanned, and when? What are the resource limits? Who decided the rollout strategy? Each team answers those questions themselves, usually differently, usually under deadline pressure — and the template stops being the source of consistency it was supposed to be.
A template and a Golden Path solve different problems
Repository template
Starter code. A Dockerfile, a folder layout, maybe a sample pipeline. Gets a team started faster on day one — and leaves identity, security checks, deployment defaults, and operational expectations for each team to figure out on their own.
Golden Path
The full supported lifecycle: repository structure, CI/CD baseline, runtime identity, security scanning, deployment defaults, and who's responsible for keeping it current — maintained as a product, not cloned and forgotten.
A template answers "what does the code look like." A Golden Path answers "how does this Application get built, secured, and deployed, the same way, regardless of who's building it." Those are different questions, and most teams have only actually answered the first one.
What a real Golden Path has to include
A Golden Path worth the name defines the runtime contract — a health endpoint, expected readiness and liveness behavior, graceful shutdown — so every Application of that Workload Type behaves predictably under the platform's own tooling. It carries a standard CI/CD scaffold: validate, test, scan, build, publish, and update desired state, in that order, every time. It bakes in the security checks a team would otherwise have to remember to add themselves — secret scanning, dependency checks, container image scanning — as defaults, not opt-ins. And it ships with Kubernetes deployment defaults already set: resource limits, non-root execution, rolling updates, and autoscaling where it applies.
None of this replaces the application code your team writes. It replaces everything that currently gets rebuilt, slightly differently, around that code every single time.
How Vertro builds and maintains Golden Paths
Vertro selects a Golden Path from Application intent rather than asking a developer to browse repositories and guess — a Go backend, a Python worker, and a Node frontend are different Workload Types with different supported paths, chosen automatically from what's being requested. Templates are versioned, so an Application onboarded today is traceable to exactly which Golden Path version it started from, and upgrading to a newer version later is a deliberate step, not a silent one.
The request-to-deployment mechanics behind this — how a request turns into a generated, reviewable change — are the same ones covered on How Vertro Works. This page is specifically about what has to be true of the path itself for "self-service" to actually mean something once the template stops being enough.
What changes once the Golden Path is real
Every Application of the same Workload Type looks structurally identical. Not because every team agreed to follow the same conventions carefully — because the platform generated it that way by default.
Security stops depending on who remembered to add it. Scanning and identity controls ship with the path itself, not as a checklist item a team can quietly skip under deadline pressure.
Powered by Golden Path templates, GitHub Actions, Helm, and the same security pipeline used across every supported Workload Type.
Frequently asked questions
What's the difference between a repository template and a Golden Path?
A repository template is starter code — a Dockerfile, a folder structure, maybe a sample pipeline. A Golden Path is the full supported lifecycle around it: how the Application authenticates, how it's scanned before deploy, how it's promoted between Environments, and who owns keeping all of that current. The template is one input to a Golden Path, not the whole thing.
Do we need a Golden Path for every runtime we use?
Not immediately. Start with the one or two Workload Types covering the most Application onboarding volume, and mark others as experimental or unsupported until there's a defined path for them. An undefined path is safer than a silently unsupported one.
Who owns a Golden Path after it's built?
The platform team. Application teams consume and extend Golden Paths within supported boundaries, but structure, required controls, and upgrades stay platform-owned — otherwise every team's fork drifts the same way the original templates did.
What happens when a Golden Path needs to change?
Golden Paths should be versioned, so an Application can be traced to which version it was onboarded against. Upgrading existing Applications to a newer version is a deliberate, controlled step — not an automatic, silent change to something already in production.
Can teams customize a Golden Path for their specific Application?
Yes, within boundaries the platform team sets. Golden Paths provide the supported default; controlled extensions and genuine exceptions go through Git review rather than an unsupervised fork of the template.
Which Workload Type should we build a Golden Path for first?
Whichever Workload Type covers the most Application onboarding volume today. Building the highest-volume path first validates the model fastest and removes the most repeated work.