Platform Engineering in 2026: The Complete Guide to Building Internal Developer Platforms
Platform engineering has gone from a niche Spotify blog post to the fastest-growing discipline in DevOps. Gartner predicted that by 2026, 80% of software engineering organisations would establish platform teams. We are there now — and the teams that got it right are shipping 4x faster than those still running ticket-based infrastructure requests. This guide covers everything: what an Internal Developer Platform (IDP) actually is, how to architect one, where Backstage fits, what golden paths look like in practice, and how to measure whether your platform is actually making developers more productive or just adding another layer of bureaucracy.
What Is Platform Engineering?
Platform engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organisations. The platform team builds the IDP. Development teams consume it.
The critical distinction: platform engineering is not “DevOps but fancier.” DevOps is a culture and set of practices. Platform engineering is a product discipline — the platform team treats developers as customers, the IDP as a product, and builds it with a roadmap, user research, and feedback loops.
What a platform team is NOT:
- Not a renamed Ops team that still processes tickets
- Not a team that builds tools nobody asked for
- Not a centralised bottleneck that controls all infrastructure
- Not a team that mandates tools without understanding developer needs
The Internal Developer Platform Architecture
An IDP sits between developers and the underlying infrastructure. It abstracts complexity while preserving the ability to drop down to lower-level controls when needed.
┌─────────────────────────────────────────────────────────────┐
│ DEVELOPER EXPERIENCE │
│ Portal (Backstage) │ CLI Tools │ CI/CD Templates │
├─────────────────────────────────────────────────────────────┤
│ PLATFORM APIS │
│ Service Catalog │ Scaffolding │ Self-Service Infra │
│ Golden Paths │ Secrets Mgmt │ Environment Mgmt │
├─────────────────────────────────────────────────────────────┤
│ ORCHESTRATION LAYER │
│ Kubernetes │ Terraform │ ArgoCD │ Vault │ CI/CD │
├─────────────────────────────────────────────────────────────┤
│ INFRASTRUCTURE │
│ AWS / Azure / GCP │ Networking │ Compute │ Storage │
└─────────────────────────────────────────────────────────────┘
The key insight: developers interact with the top layer. They should never need to touch the bottom two layers directly. The platform team owns the middle two layers and is responsible for making the developer experience seamless.
Why Platform Engineering Exists: The Problem It Solves
In a typical organisation with 50 microservices and 10 teams:
- Each team has its own deployment process, some using Helm, some using raw manifests, some using shell scripts
- Infrastructure requests go through tickets that take 3-5 days
- New engineers spend their first two weeks understanding the toolchain instead of shipping features
- The same boilerplate code is copy-pasted across repos, accumulating drift
- Security policies are enforced manually, leading to inconsistencies
Platform engineering fixes this by providing standardised, self-service workflows that encode best practices. Instead of every team reinventing the wheel, the platform team builds the wheel once and makes it available through golden paths.
Golden Paths: The Core Concept
A golden path is a pre-approved, standardised workflow for a common task. It is the recommended way to do something, but not the only way. Developers can follow the golden path and move fast, or go off-path when they have a good reason — but off-path requires extra review and support.
Examples of golden paths:
- Create a new service: Fill out a form in Backstage, and the platform scaffolds a repo with a Dockerfile, CI/CD pipeline, Terraform for infrastructure, Kubernetes manifests, and observability configuration. The developer writes code; everything else is pre-configured.
- Deploy to production: Push to main, the pipeline runs tests, builds the image, deploys to staging, runs smoke tests, and promotes to production with a canary rollout. No manual steps.
- Add a database: Select “PostgreSQL” from the service catalog, choose size and environment, and the platform provisions an RDS instance, creates credentials in Vault, injects them into the application’s Kubernetes deployment, and updates the service dependency graph.
# Example Backstage software template for a new microservice
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
name: spring-boot-service
title: Spring Boot Microservice
description: Create a new Spring Boot microservice with CI/CD and K8s deployment
spec:
owner: platform-team
type: service
parameters:
- title: Service Details
properties:
name:
title: Service Name
type: string
pattern: "^[a-z][a-z0-9-]*$"
description:
title: Description
type: string
owner:
title: Owner Team
type: string
ui:field: OwnerPicker
- title: Infrastructure
properties:
database:
title: Database
type: string
enum: [none, postgresql, mysql, mongodb]
cacheLayer:
title: Cache
type: string
enum: [none, redis, memcached]
steps:
- id: fetch-base
name: Fetch Base Template
action: fetch:template
input:
url: ./skeleton
values:
name: $
owner: $
- id: publish
name: Publish to GitHub
action: publish:github
input:
repoUrl: github.com?owner=acme&repo=$
- id: register
name: Register in Catalog
action: catalog:register
input:
repoContentsUrl: $
catalogInfoPath: /catalog-info.yaml
Building with Backstage
Backstage is the open-source IDP framework originally built by Spotify and now a CNCF incubating project. It provides three core features:
Software Catalog
A centralised registry of all services, libraries, APIs, documentation, and infrastructure in your organisation. Each entity has an owner, a lifecycle status (production, experimental, deprecated), and metadata. When an engineer wants to know who owns the payment service, what APIs it exposes, and where its runbook lives, they check the catalog — not Slack.
Software Templates (Scaffolder)
Golden path implementations. Templates define forms that developers fill out, and actions that create repositories, configure CI/CD, provision infrastructure, and register the new service in the catalog. The template encodes your organisation’s best practices — security headers, logging configuration, health check endpoints — so every new service starts correctly.
TechDocs
Documentation as code. TechDocs renders Markdown from each repository and surfaces it in Backstage. Engineers find documentation alongside the service it describes, not in a separate wiki that nobody updates.
Backstage Plugins
The plugin ecosystem is where Backstage gets powerful. Over 200 community plugins cover:
- Kubernetes: Show pod status, logs, and events for each service directly in Backstage
- CI/CD: GitHub Actions, Jenkins, CircleCI build status
- PagerDuty: On-call schedules and incident status
- Cost: Cloud cost per service
- Security: Vulnerability scan results from Snyk, Trivy
- API Docs: OpenAPI/Swagger docs rendered inline
Measuring Platform Success
A platform that cannot prove its value will lose funding. Measure these:
| Metric | What It Measures | Target |
|---|---|---|
| Time to first deploy | How fast a new engineer ships their first change | < 1 day |
| Service creation time | Time from “I need a new service” to “it is in production” | < 30 minutes |
| Deployment frequency | How often teams deploy | Multiple times per day |
| Developer satisfaction (survey) | Do developers find the platform useful? | > 4.0/5.0 |
| Golden path adoption | % of services using golden paths | > 80% |
| Self-service ratio | % of infra requests handled without tickets | > 90% |
| Onboarding time | Days until a new engineer is productive | < 5 days |
If your platform team builds tools but developers still file tickets for infrastructure, the platform is not working. If golden path adoption is below 50%, the paths are either too rigid or too hard to discover.
Common Mistakes Platform Teams Make
- Building for perfection instead of iteration. Ship a minimal platform in month 1 and iterate. Do not spend 6 months building a portal nobody asked for.
- Mandating without listening. Developers resist platforms imposed top-down. Run user research. Watch developers work. Build what they need, not what you think they need.
- Abstracting too much. Hiding all infrastructure details makes simple things easy but hard things impossible. Provide escape hatches — the ability to drop down to raw Terraform or Kubernetes when the abstraction does not fit.
- Ignoring existing tools. If teams already use ArgoCD and love it, do not replace it. Integrate it into the platform. The best platforms compose existing tools, not replace them.
- No product management. A platform without a product manager is a collection of tools. Assign a PM. Maintain a roadmap. Prioritise based on developer impact, not technical interest.
Platform Team Structure
A platform team typically needs:
- Platform engineer (2-4): Build and maintain the IDP. Strong in Kubernetes, Terraform, CI/CD, and at least one general-purpose language (Go, Python, TypeScript).
- Product manager (1): Defines the roadmap, prioritises features, runs developer surveys, and measures adoption.
- Developer advocate/DX engineer (0-1): Writes documentation, runs enablement sessions, and is the voice of the developer.
Start small. A team of 2 engineers can build a meaningful platform for an organisation of 50 developers. Scale the team as adoption grows.
The Technology Stack
There is no single “right” stack. Here is what works in 2026:
| Component | Options | Recommendation |
|---|---|---|
| Developer Portal | Backstage, Port, Cortex, OpsLevel | Backstage (open source, largest ecosystem) |
| Container Orchestration | Kubernetes, ECS, Nomad | Kubernetes (industry standard) |
| GitOps | ArgoCD, FluxCD | ArgoCD (more features, larger community) |
| IaC | Terraform, Pulumi, Crossplane | Terraform (ecosystem) or Crossplane (K8s-native) |
| Secrets | Vault, AWS Secrets Manager | Vault (multi-cloud, dynamic secrets) |
| CI/CD | GitHub Actions, GitLab CI, Tekton | GitHub Actions (simplicity) or Tekton (K8s-native) |
| Observability | Datadog, Grafana Stack, Dynatrace | Grafana Stack (open source) or Datadog (managed) |
Conclusion
Platform engineering is not about building the fanciest tools — it is about reducing the cognitive load on development teams so they can focus on shipping features instead of fighting infrastructure. Start with the biggest pain point (usually service creation or deployment), build a golden path for it, measure adoption, iterate. Treat your platform as a product: talk to your users, ship incrementally, and ruthlessly prioritise. The organisations that get this right do not just move faster — they attract better talent, because engineers want to work where the developer experience is excellent.
FAQs
Q: Do I need Backstage for platform engineering? No. Backstage is the most popular framework, but you can build an IDP with any combination of tools. Some teams start with a CLI and a set of Terraform modules before adding a portal. Backstage is worth adopting when you need a service catalog and templating system.
Q: How is platform engineering different from SRE? SRE focuses on reliability — SLOs, error budgets, incident response. Platform engineering focuses on developer productivity — self-service, golden paths, toolchain standardisation. They complement each other: the SRE team defines reliability standards, the platform team bakes those standards into the golden paths.
Q: When should a company invest in platform engineering? When the cost of every team solving the same infrastructure problems independently exceeds the cost of a dedicated platform team. Typically around 30-50 engineers, 10+ services.
Q: What is the difference between Crossplane and Terraform in a platform context?
Terraform is imperative (you run terraform apply). Crossplane is declarative and Kubernetes-native (you apply a YAML manifest and a controller reconciles it). Crossplane fits better in a GitOps workflow because it uses the Kubernetes reconciliation loop. Terraform fits better when your team already has deep Terraform expertise.
Related posts:
