Cloud Sandbox
All notes

How golden paths become platforms

A golden path begins as a recommended route through software delivery. It becomes a platform when that route is discoverable, self-service, supported, observable and continuously improved through feedback from the teams using it.

about 16 minutes min read

A team creates a service template.

The template includes:

  • a Go module
  • a Dockerfile
  • a health endpoint
  • a GitHub Actions workflow
  • Kubernetes manifests
  • an OpenTelemetry configuration
  • a short README

An engineer runs it and receives a repository.

template
   │
   ▼
new repository

This is useful.

It is not yet a platform.

The repository still needs build infrastructure, credentials, deployment authority, DNS, observability, ownership, support and a way to receive future improvements.

The template created files. It did not necessarily create a working relationship between the application team and the systems that will carry the service into production.

A generated repository is also normally a snapshot. Updating the template does not automatically update repositories created last month.

A golden path becomes a platform when the path extends beyond generation.

discover
   │
   ▼
create
   │
   ▼
build
   │
   ▼
deploy
   │
   ▼
observe
   │
   ▼
operate
   │
   ▼
improve

A golden path becomes a platform when it is no longer merely advice about how work should happen. It becomes a supported product through which the work can actually be completed.

That requires more than a template.

It requires a control loop.

From template to supported capability

The template creates the starting state

Backstage Software Templates can load a code skeleton, collect parameters, execute actions, publish the result to source control and register the resulting component in the software catalog. Each execution is represented as a task with its own result and logs.

A simple service template might produce:

catalog-service/
├── cmd/
├── internal/
├── api/
├── deploy/
├── Dockerfile
├── Makefile
├── go.mod
├── catalog-info.yaml
└── .github/
    └── workflows/
        └── ci.yml

This removes blank-page decisions about structure, naming, builds, tests, documentation, catalog registration and CI.

The standards arrive in the first commit.

But the template mostly answers:

What should exist
when the journey begins?

A platform must also answer:

What happens after that?

The golden path spans the lifecycle

For a bfstore Go service, the path might include:

CREATE

repository
service metadata
documentation skeleton


VERIFY

formatting
unit tests
dependency checks
static analysis
contract checks


PACKAGE

container image
software bill of materials
signed artefact


PROVISION

database
runtime identity
secrets path
DNS
telemetry destination


DEPLOY

development
staging
production


OPERATE

logs
metrics
traces
alerts
runbook
ownership

AWS describes golden paths as end-to-end automated patterns spanning repositories, testing, security, deployment and observability.

The difference is scope.

TEMPLATE

creates a starting artefact


GOLDEN PATH

creates a supported route
through the delivery lifecycle

A template may be one implementation detail inside the path.

It should not be mistaken for the destination.

Self-service turns intent into execution

A document can describe a golden path.

A platform lets an engineer consume it without opening a ticket for every step.

The interface may be:

  • a developer portal
  • a CLI
  • an API
  • a Git workflow
  • a combination of all four

For bfstore, a developer might supply:

service:
  name: returns
  language: go
  owner: application-team
  communication:
    synchronous: grpc
    asynchronous: kafka
  database:
    required: true
  exposure:
    type: internal

The platform can derive the repository, module path, catalog entity, CI workflow, container repository, dashboards, runtime identity, namespace, network policy, documentation and deployment configuration.

The developer supplies intent.

The platform supplies the repeated machinery.

DEVELOPER

what am I building?


PLATFORM

which approved components
turn that intent into a service?

Self-service does not mean every request is automatically approved.

It means supported requests, policy decisions, required approvals, execution status and failure feedback are available through a defined workflow rather than private coordination.

REQUEST
   │
   ▼
POLICY EVALUATION
   │
   ├── automatically approved
   ├── requires recorded approval
   └── rejected with explanation
   │
   ▼
EXECUTION AND FEEDBACK

Durable systems carry the work afterwards

Backstage may provide the visible entrance.

The platform behind that entrance still includes source control, CI, Terrakube, OpenTofu, Crossplane, Kubernetes, artefact registries, secrets systems and observability.

The portal can ask:

Which type of service
would you like to create?

The platform must then make good on the answer.

BACKSTAGE TASK
        │
        ▼
DESIRED STATE
repository, pull request
or control-plane resource
        │
        ▼
DURABLE RECONCILER
GitOps, Terrakube,
Crossplane or equivalent
        │
        ▼
RUNNING CAPABILITY

The portal initiates the request.

It should not become the only record of desired state.

A Backstage task can succeed, fail, be cancelled or be started again. Long-lived infrastructure and workload configuration should therefore be handed to a control plane that can retry, detect drift and report readiness after the portal task has ended.

The hand-off needs idempotent actions, stable resource identifiers, safe retries, partial-failure cleanup, downstream status links and a clear recovery owner.

A portal with buttons whose downstream integrations are unreliable is not a platform.

It is a beautifully organised collection of future support tickets.

The scaffolder is a privileged control surface

Once templates create repositories, identities, DNS records, cloud resources and production deployment paths, the scaffolder is no longer merely a form renderer.

It is part of the platform security boundary.

The platform must control who may start each template, which parameters are allowed, which production actions require approval, which integration identity performs the work, who may view task logs and how executions are audited.

Backstage provides permission controls around template execution, parameters, steps, task visibility and cancellation. Templates can also use secret values rather than ordinary parameters.

The secure path must include the machinery creating the secure path.

Custom actions should be narrowly authorised, tested, retry-safe, explicit about side effects and observable when they fail.

A task log should help diagnose a failure without becoming a place where credentials and private values quietly accumulate.

The path must be operated as a product

Ownership continues after creation

A template can be published once and forgotten.

A platform capability cannot.

Someone must own compatibility, documentation, upgrades, security fixes, deprecations, support, feedback and roadmap decisions.

Suppose the golden path generates Go services using:

Go 1.25

Eventually the Go version changes, GitHub Actions evolve, scanners are replaced, Kubernetes APIs are deprecated and new security controls become mandatory.

A generated repository does not inherit those improvements automatically.

The platform needs an upgrade strategy.

SHARED DEPENDENCY

versioned library or base image


MANAGED CONFIGURATION

centrally reconciled policy or resource


GENERATED FILE

upgrade pull request or codemod


APPLICATION-OWNED FILE

documented migration

The platform team must decide how the path changes, which services are affected, whether automated pull requests are issued, how long the old path remains supported and how adoption is evidenced.

TEMPLATE OWNER

maintains some files


PLATFORM PRODUCT TEAM

maintains a user journey
and its operational outcome

Catalog ownership is not the whole operating model

A Backstage catalog owner helps people discover which group an entity belongs to.

That is valuable metadata, but it does not prove that the group accepts on-call responsibility, can change the system, maintains a runbook or owns product outcomes.

bfstore should distinguish:

CATALOG OWNER

discoverable responsible group


OPERATIONAL OWNER

on-call and incident responsibility


TECHNICAL OWNER

authority to change the system


PRODUCT OWNER

prioritises service outcomes

The platform can make these relationships visible and testable.

A stronger scorecard asks for:

services_with_valid_catalog_owner
services_with_on_call_route
services_with_tested_escalation
services_with_current_runbook

The surrounding operating model must make that catalog ownership real.

Feedback must travel in both directions

A one-way golden path looks like:

platform team
     │
     ▼
template
     │
     ▼
application team

A platform requires a return route.

platform capability
       │
       ▼
developer use
       │
       ▼
delivery outcome
       │
       ▼
friction and evidence
       │
       ▼
platform improvement

Useful feedback includes abandonment, confusing parameters, task failures, time to first deployment, files immediately rewritten, recurring bypasses, repeated support questions and workloads that do not fit.

The platform team should not interpret every deviation as developer disobedience.

Repeated deviations may indicate that the path has become narrower than the road developers actually need.

The platform improves through evidence rather than by repeatedly painting the same path a brighter shade of gold.

Platform capabilities need their own SLOs

A supported path should have service-level objectives of its own.

For example:

platform_capability: create-go-service

availability:
  successful_request_rate: 99.5%

latency:
  p95_repository_creation: 3m
  p95_development_readiness: 15m

reliability:
  partial_provisioning_rate: 0.5%
  manual_recovery_rate: 0.2%

feedback:
  failures_with_actionable_message: 98%
  workflows_linking_to_downstream_status: 100%

The platform should measure not only whether a task completed, but whether the developer could understand its state, recover from failure and complete the intended outcome.

Guardrails should be built into the journey

A golden path should make the secure route the easy route.

It can include repository protection, dependency and secret scanning, signed artefacts, approved base images, workload identity, encrypted storage, standard telemetry and deployment approval rules.

The path should not merely say:

Remember to configure
workload identity.

It should create:

  • the trust policy
  • the workload role
  • the Kubernetes service account
  • the approved association
  • the relevant tests

The generated service starts inside the organisation’s intended security model.

SECURITY DOCUMENT

explains the rule


GOLDEN PATH

implements the ordinary case


GUARDRAIL

prevents prohibited variation

These layers should reinforce one another.

The platform removes repeated security construction.

It should not remove engineers’ understanding of what the controls do.

A platform still needs escape routes

A golden path should be attractive, supported and well maintained.

It should not claim that every workload has the same shape.

bfstore may contain stateless services, Kafka consumers, scheduled jobs, gateways, operators, telemetry collectors, public websites and infrastructure controllers.

One template cannot represent all of them honestly. A useful platform may offer several supported paths for common workload shapes.

A team with a legitimate exception should be able to leave the path through a documented process.

exception:
  owner: payments-team
  reason: requires specialised PCI runtime

  mandatory_controls:
    - signed images
    - workload identity
    - central telemetry

  review_date: 2026-12-01
  migration_candidate: true

The exception should record why the path does not fit, which guarantees still apply, who supports the alternative, when it will be reviewed and whether repeated demand should create a new supported path.

GOLDEN PATH

supported default


GUARDRAIL

non-negotiable safety boundary


ESCAPE ROUTE

approved alternative
with explicit ownership

A path without exits becomes a cage.

A path nobody chooses becomes scenery.

Documentation is part of the interface

A platform is not self-service when every successful use requires someone from the platform team to sit beside the developer.

The documentation should explain what the path creates, which workload fits it, how identity and deployment work, where telemetry appears, how failures are diagnosed, how upgrades happen and how exceptions are requested.

Backstage TechDocs supports a docs-like-code model in which documentation lives alongside source and can be surfaced through the portal. Software templates can create that documentation path from the beginning.

For bfstore, the generated structure could include:

docs/
├── index.md
├── architecture.md
├── development.md
├── deployment.md
├── observability.md
└── runbook.md

The template provides the structure.

The owning team provides the service-specific truth.

The platform provides the place where that truth can be found.

Documentation is not an appendix to self-service.

It is one of the mechanisms through which self-service becomes possible.

Success is measured after adoption

A platform should not measure success only by counting:

templates created

portal plugins installed

repositories generated

Those are activity measures.

The intended outcomes are shorter time to first deployment, lower lead time, fewer failed deployments, faster recovery, fewer support requests, higher control adoption, clearer ownership and better developer experience.

A bfstore scorecard might contain:

golden_path: go-grpc-service

adoption:
  active_services: 12
  teams_using_path: 3

delivery:
  median_time_to_first_deployment: 18m
  median_lead_time: 42m
  change_failure_rate: 4.2%

experience:
  task_failure_rate: 1.1%
  workflow_abandonment_rate: 2.0%
  manual_platform_tickets_per_service: 0.4
  documentation_helpfulness: 4.3/5

operations:
  services_with_standard_telemetry: 100%
  services_with_valid_catalog_owner: 100%
  services_with_on_call_route: 92%
  services_with_tested_runbook: 83%

The numbers should lead to decisions.

Delivery metrics are influenced by more than the platform.

The platform can affect lead time, deployment frequency and recovery, but it does not own every variable affecting them.

Measure association carefully before claiming causation.

Use a pre-adoption baseline, segment results by path and workload type, compare similar adopters and non-adopters, and combine task data with stability, satisfaction and user research.

If first deployment is fast but service upgrades remain manual, the platform has optimised only the first ten minutes of a multi-year lifecycle.

If adoption is high because use is mandatory while satisfaction is poor, the adoption number is wearing borrowed clothes.

The bfstore path from template to platform

The first bfstore golden path could support one deliberately narrow workload:

Go gRPC microservice
with optional Kafka and MySQL
running on Kubernetes

First version

Generate:

  • Go service skeleton
  • Protobuf contract
  • unit-test layout
  • Dockerfile
  • Make targets
  • GitHub Actions
  • Helm chart
  • catalog-info.yaml
  • TechDocs skeleton

Second version

Integrate:

  • repository creation
  • branch protection
  • container registry
  • image scanning
  • signed artefacts
  • development deployment
  • workload identity
  • standard telemetry

Third version

Add:

  • staging promotion
  • policy checks
  • database provisioning
  • secret references
  • SLO template
  • runbook checks
  • deployment evidence
  • upgrade automation

Platform version

Operate the catalog, self-service workflows, reusable APIs, durable reconcilers, upgrades, support, platform SLOs, adoption and failure metrics, user research, roadmap and deprecation process.

SCAFFOLD
   │
   ▼
AUTOMATE
   │
   ▼
INTEGRATE
   │
   ▼
OPERATE
   │
   ▼
LEARN
   │
   ▼
PLATFORM

The platform is not finished at the bottom of that diagram.

The final arrow loops back to the top.

The mental model I am keeping

My earlier model was:

GOLDEN PATH

good repository template
+
developer portal button

The stronger model is:

                       DEVELOPER NEED
                              │
                              ▼
                        GOLDEN PATH
                              │
              ┌───────────────┼───────────────┐
              │               │               │
              ▼               ▼               ▼
          DISCOVERY       SELF-SERVICE     GUARDRAILS
              │               │               │
              └───────────────┼───────────────┘
                              ▼
                        DESIRED STATE
                              │
                              ▼
                     DURABLE RECONCILIATION
                              │
              ┌───────────────┼───────────────┐
              │               │               │
              ▼               ▼               ▼
            BUILD          DEPLOY          OPERATE
              │               │               │
              └───────────────┼───────────────┘
                              ▼
                         OBSERVATION
                              │
                              ▼
                           FEEDBACK
                              │
                              ▼
                     PRODUCT IMPROVEMENT
                              │
                              └──────────► GOLDEN PATH

The template defines how a component begins.

Self-service turns developer intent into an executable request.

Guardrails keep the ordinary route inside security and compliance boundaries.

Durable reconciliation keeps the desired outcome true after the portal task ends.

Documentation and support make the result operable.

Metrics and feedback show whether the platform improved delivery and what the path should become next.

The escape route handles the cases where the supported default is genuinely not enough.

A template becomes a golden path when it encodes a recommended journey.

A golden path becomes a platform when that journey is:

  • discoverable
  • self-service
  • integrated
  • secure
  • documented
  • supported
  • measurable
  • maintained
  • open to improvement

The platform is not the paved road. It is the organisation that keeps the road connected, signposted, repaired and worth choosing.

Backstage may provide the map and entrance.

Terrakube, Crossplane and OpenTofu may reconcile the ground beneath it.

GitHub Actions may carry changes along it.

Kubernetes may host the resulting workload.

Observability may show whether the journey succeeded.

The platform team owns the experience across those boundaries.

Without that ownership, the golden path is a template with ambitions.

With it, the path becomes a product teams can build upon without first becoming experts in every stone beneath their feet.

References and further reading