Internal Developer Platform with Golden Paths

Overview

Product teams shouldn't need to become cloud experts just to ship a new service. I designed and run an Internal Developer Platform built on Backstage. Developers choose a golden-path template, answer a few questions, and the platform does the rest: it creates the repository, wires up passwordless CI/CD, provisions infrastructure, deploys to Kubernetes and registers the service in a searchable catalog.

There are templates for Node.js (Express + TypeScript), .NET and Python (FastAPI). Each one can start a brand-new service or onboard an existing codebase.

The Problem It Solves

• Slow starts: a new service meant a chain of tickets across platform, security and networking teams.
• Snowflake pipelines: every team wired builds, Helm values and secret access differently, which made support and audit painful.
• No single source of truth: service ownership and documentation were scattered across wikis and spreadsheets.

Architecture

The platform is split into independently versioned pieces, so each one can evolve without breaking the others:

Implementation

1. One skeleton, many languages

Templates merge the shared skeleton with a language layer when they render. Fixing a Terraform module or Helm value once fixes it for every language.

# Illustrative scaffolder template steps
steps:
  - id: fetch-shared
    action: fetch:template
    input:
      url: ../shared-skeleton
      values: { name: ${{ parameters.name }}, domain: ${{ parameters.domain }} }
  - id: fetch-language
    action: fetch:template
    input: { url: ./skeleton-nodejs }
  - id: publish
    action: publish:github
  - id: onboard-identity      # creates per-environment OIDC federated credentials
    action: github:actions:dispatch
  - id: register
    action: catalog:register

2. Identity without secrets

Creating a repository triggers an onboarding workflow that sets up Entra ID federated credentials for each deployment environment. No client secret is ever created or stored.

3. Infrastructure in dependency order

Infrastructure workflows run on merge in a fixed order: base → compute → database → integration → security → storage. A missing dependency can't cause a half-built environment.

4. Access by domain, not by person

Per-stage service connections and domain-group RBAC are applied through a governance pipeline, so access is reviewed as code rather than granted by hand.

5. Onboarding existing apps

For existing codebases, the template analyses the source and generates a Dockerfile and Helm values, so teams don't have to start from scratch.

6. Cost before commitment

A cost-estimate step shows the projected monthly cost of the requested infrastructure before anything is provisioned.

Key Outcomes

• Every new service starts with the same baseline: OIDC identity, domain RBAC, private networking, Key Vault secrets and APM.
• Platform standards are the default path, not a review checklist.
• Catalog quality is enforced by schema validation on every pull request.

Lessons Learned

• Templates are products. Version them, test them and give them a changelog, because a broken template breaks every new service.
• Plan for identity limits early. Federated credentials are capped per app registration, so design the layout for scale from day one.
• Enforce ordering in code. Documented ordering gets skipped. Enforced ordering doesn't.

Conclusion

A good developer platform makes the right way the easy way. Turning standards into templates freed product teams to focus on features, and freed the platform team from being a ticket queue.

Technologies Used