Internal Developer Platforms & Golden Paths

Internal Developer Platforms and Golden Paths

As organizations grow, every team ends up solving the same problems: setting up repositories, CI pipelines, deployments, databases, secrets, dashboards, alerts, and security scans. Left alone, each team solves them differently, and the organization pays for dozens of slightly broken variations. An internal developer platform (IDP) offers these capabilities as self-service — and a golden path is the opinionated, fully supported way to build and run a common kind of workload, from "create a new service" to "it's in production with monitoring."

The hard part is not building the technology. It is building something developers choose to use: solving their real problems, staying out of their way, keeping existing services up to date, and being clear about what the platform team supports.

TL;DR

A golden path is the recommended, supported way to do a common task end to end — not a mandate.
Start with the thinnest viable platform: often templates, shared pipelines, and documentation before a portal.
Run the platform as a product: research users, prioritize by pain, publish a roadmap, and measure adoption.
Offer self-service through the interfaces developers already use — Git, CLIs, APIs — with a portal as a front door.
Solve day-two problems: templates must keep existing services current, not just scaffold new ones.
Measure time to first deploy, adoption, delivery metrics, and developer satisfaction; be explicit about ownership and support boundaries.

Quick Example

A golden-path template in a developer portal (Backstage scaffolder) that creates a production-ready service:

What "on the golden path" means, written down so teams know what they get:

Core Concepts

Golden Paths

A golden path bundles decisions — language runtime, build, deployment, observability, security — into a coherent default that works out of the box. It is optional but attractive: teams can leave it, but they then own the pieces they replace. Typical paths include HTTP services, scheduled jobs, event consumers, frontends, data pipelines, and ML models.

Thinnest Viable Platform

The smallest set of shared capabilities that makes teams faster may be a wiki page, a few templates, and a shared CI configuration. Grow the platform from there based on evidence of demand. Building a large portal first, before solving any concrete problem, is a common way platform initiatives stall. See Team Topologies.

Platform as a Product

Interfaces

Developers interact with platforms through several layers: Git (templates, configuration, GitOps repositories), CLIs and APIs for automation, CI building blocks (reusable workflows), and a portal with a software catalog, documentation, scaffolding, and scorecards. Backstage is the most common open-source portal framework; commercial portals offer similar capabilities. The portal should orchestrate existing tools, not hide them.

Day-Two: Keeping Services on the Path

Scaffolding is easy; keeping fifty existing services current is hard. Templates diverge the moment they are copied. Strategies:

Shared, versioned building blocks — reusable CI workflows, base images, Helm charts, libraries — rather than copied code.
Template update tooling that re-applies template changes to generated repositories.
Automated pull requests for upgrades, with deprecation timelines.
Scorecards showing which services meet current standards.

Measuring Success

Use several measures; any single metric can be gamed or misleading.

Ownership and Support

Be explicit about the contract: which components the platform team builds and operates, what service levels apply, how incidents in shared components are handled, how changes are communicated, and when old versions stop being supported. Teams that leave the path should know which responsibilities they take on.

Best Practices

Pave the Paths People Already Walk

Standardize the workflows most teams already use and struggle with, rather than inventing new ones.

Make the Right Thing the Easy Thing

Bake security scanning, observability, and reliability defaults into the path, so compliance comes for free. See CI Pipeline Design and Quality Gates.

Prefer Composable Building Blocks

Offer versioned modules, workflows, and charts that teams can combine, rather than one monolithic template that is hard to update.

Invest in Documentation and Support

Clear getting-started guides, examples, and responsive support channels matter as much as the tooling.

Common Mistakes

Building the Portal First

Mandates Without Value

Scaffold-and-Forget Templates

FAQ

What is an internal developer platform?

A set of self-service tools, workflows, and services — built and maintained by a platform team — that lets application teams create, deploy, and operate software without filing tickets or reinventing infrastructure.

What is a golden path?

An opinionated, well-supported, end-to-end way to accomplish a common task, such as creating and running an HTTP service, that bundles recommended tools and defaults so teams can move quickly and safely.

Do we need Backstage to build a platform?

No. A portal is one interface. Many valuable platforms start with templates, reusable CI workflows, GitOps repositories, and documentation, adding a portal later as a front door.

How do we measure platform success?

Track time to first deploy, adoption of golden paths, delivery metrics such as DORA, developer satisfaction, support load, and the share of services meeting current standards.

Should golden paths be mandatory?

Generally not. They should be the easiest, best-supported option. Teams that leave the path take on responsibility for the pieces they replace, and some baseline controls may still be required for everyone.