By 2026, platform engineering has graduated from buzzword to default practice. Gartner expects 80% of software engineering orgs to have a platform team this year. The reason is simple: the dev experience around Kubernetes + cloud is bad enough that fixing it once for everyone pays for itself in months.

This post is the working definition. What an Internal Developer Platform (IDP) actually is, what good ones look like in 2026, the components that matter, and — crucially — how to introduce one without spending two years building a new monolith for your “platform.”

What a platform engineer actually does

A platform engineer’s product is other engineers’ productivity. Their customers are inside the building. Their KPIs look like:

  • Time from git init to first deploy in production: hours, not days.
  • Time to add a new service: minutes, not a JIRA epic.
  • Number of moving parts a feature engineer has to understand: small, not “the entire CNCF landscape.”
  • Cognitive load on application teams: down, not up.

The platform team builds the paved roads so application teams can stay in their lane.

Internal Developer Platform — the actual definition

Strip the buzzwords. An IDP is:

A set of self-service interfaces (UI, CLI, API, Git) that let developers provision the things they need to ship — services, databases, message queues, environments — without writing Kubernetes YAML or filing tickets.

Three properties that distinguish good from bad:

  1. Self-service. No human approval in the hot path.
  2. Opinionated. There’s a way to do things. Variations are allowed but not required.
  3. Composed of standard pieces. Kubernetes, Terraform/Crossplane, OPA, Backstage. Not a custom DSL written by your platform lead in 2022.

The shape of an IDP in 2026

              ┌─────────────────────────────────────────┐
              │      Developer Portal (Backstage)       │  Self-service UI
              └───────────────┬─────────────────────────┘
                              │
              ┌───────────────▼─────────────────────────┐
              │  Templates / Golden Paths               │  "Create service"
              │  (Backstage scaffolder, Crossplane)     │  "Create database"
              └───────────────┬─────────────────────────┘
                              │
              ┌───────────────▼─────────────────────────┐
              │  Control plane                          │
              │  • Argo CD / Flux  (deploys)            │
              │  • Crossplane / Terraform  (infra)      │
              │  • OPA / Kyverno  (policy)              │
              │  • OpenTelemetry  (observability)       │
              └───────────────┬─────────────────────────┘
                              │
              ┌───────────────▼─────────────────────────┐
              │  Runtime: Kubernetes, cloud, edge       │
              └─────────────────────────────────────────┘

The portal is the front door. The templates encode the golden path. The control plane converges desired state into reality. The runtime is whatever you already have.

Pillar 1 — Backstage (the developer portal)

Backstage is Spotify’s open-source dev portal, and in 2026 it’s the de facto standard. What it gives you:

  • Service catalog — every service, owner, on-call, dependencies, in one searchable place.
  • Scaffolder — “create new service” templates that generate a repo, CI, a Kubernetes manifest, and an entry in the catalog, all from a form.
  • Tech docs — Markdown in your repo becomes searchable docs in the portal.
  • Plugins — for Argo CD, Grafana, PagerDuty, Sentry, your CI, your cloud. The plugin ecosystem is massive.

Minimal catalog-info.yaml in every service repo:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: orders-api
  description: Order management service
  annotations:
    backstage.io/techdocs-ref: dir:.
    pagerduty.com/integration-key: ${PD_KEY_ORDERS}
spec:
  type: service
  lifecycle: production
  owner: team-orders
  system: commerce
  providesApis: [orders-api]

That tiny file gives you ownership, on-call routing, docs, dependency graph, and a portal entry. Multiply by every service.

Pillar 2 — Golden paths

A golden path is the way the platform team has decided is the way. It’s not the only way; it’s the way that comes pre-wired with everything you’d want.

A typical golden path for a new HTTP service:

  1. Open the portal, click “New service.”
  2. Pick template: python-fastapi-service or rust-axum-service or go-grpc-service.
  3. Fill in: name, owner, system, environment.
  4. Submit.

What happens automatically:

  • A repo is created with a vetted template (CI, Dockerfile, k8s manifests, observability).
  • A Backstage entry is registered.
  • A staging Kubernetes namespace, ingress, and DNS record are provisioned.
  • Argo CD picks up the repo and deploys.
  • A PagerDuty service and Grafana dashboard are created.

Five minutes. No tickets.

The cost is opinion: every golden-path service uses the same logging format, the same auth library, the same metric labels. Application teams can deviate, but the path of least resistance is the paved road. Standardization is the product.

Pillar 3 — Crossplane (or Terraform, with discipline)

How do you let developers create a Postgres without giving them cloud admin? Crossplane.

Crossplane defines Composite Resource Definitions (XRDs) — Kubernetes-native abstractions over cloud resources. Developers create:

apiVersion: db.example.com/v1
kind: PostgresInstance
metadata:
  name: orders-db
spec:
  size: small
  region: ap-south-1

The platform team has defined PostgresInstance as a Composition that under the hood provisions an RDS instance, a security group, an IAM role, a secret, and registers them. The developer never sees AWS.

Why this matters:

  • One definition, multiple cloud backends — same PostgresInstance works on AWS, GCP, on-prem.
  • Same Git/Argo CD pipeline as application code. No state-file shuffles.
  • Drift detection, RBAC, policy — all just Kubernetes.

If Crossplane feels heavy, the alternative is Terraform with strict module discipline: the platform team owns modules, app teams instantiate them via PRs that get auto-applied. Less elegant but simpler to start.

Pillar 4 — Argo CD / Flux (GitOps for deploys)

Application teams push to Git. A controller in the cluster watches Git and reconciles to actual state. That’s GitOps. Argo CD has the better UI; Flux has the better CRD design. Pick one.

The IDP angle: developers don’t kubectl apply. They merge a PR. The platform decides what “merge” means — auto-deploy to staging, gated promotion to prod, automated rollbacks on SLO violation.

I covered the mechanics in GitOps with Argo CD .

Pillar 5 — Policy as code

OPA / Kyverno / Cedar — admission controllers that say “no” to violations of platform standards:

  • No container without resource limits.
  • No image without a signature.
  • No service without an owner annotation.
  • No public load balancer in prod-secure-* namespaces.

Encoded as Rego or YAML, version-controlled, applied in CI and in the cluster. The two layers catch each other’s misses.

Pillar 6 — Observability

OpenTelemetry has won the wire format war. Platform teams in 2026 ship a default OTel SDK setup in every service template:

  • Auto-instrumentation for HTTP frameworks
  • Trace context propagation
  • A standardized set of resource attributes (service, version, environment, owner)
  • A platform-provided collector that fans out to your tracing backend, metrics, logs

Application teams await call_db() and get distributed traces without writing observability code. That’s the dream.

How to start without burning the village

You don’t roll out an IDP. You evolve into one.

Phase 0 — Inventory

Find out what your engineers actually waste time on. Survey, walk the build process, time the PR-to-prod path. Most platforms get built around imagined pain. Build around real pain.

Phase 1 — One paved road

Pick the most painful path and pave it. Usually: “create a new HTTP service and deploy it.” Build one good template. CI, Dockerfile, observability, manifests, deploy. Don’t try to be Spotify on day one.

Phase 2 — Catalog

Stand up Backstage with the service catalog plugin. Even bare-bones, just having a list of services with owners and links is a productivity win.

Phase 3 — Self-service infra

Add Crossplane (or curated Terraform modules) for the second-most painful resource. Usually: databases, queues, S3 buckets.

Phase 4 — Golden paths in the portal

Wire scaffolder templates so the “create service” flow is one form. This is when you cross from “we have a platform team” to “we have a platform.”

Phase 5 — Policy and SLOs

Add admission controllers and SLO automation. By now you have the volume to justify them.

Each phase ships value on its own. Skipping ahead is a common failure mode — building Backstage before you have a golden path leaves you with an empty catalog.

Anti-patterns

“We built our own Kubernetes abstraction”

Custom YAML DSLs are a trap. They look like they reduce complexity. They actually move it — into a system only your team understands. Stick to standard Kubernetes APIs and Composite Resources.

Approval gates everywhere

Every approval gate is a confession that you don’t trust your guardrails. Build the guardrails (policies, signed images, immutable infra), and let the deploys flow.

Platform team as ticket queue

If app teams ask the platform team to do work, the platform isn’t a platform. It’s a managed service with extra steps. Self-service is the entire point.

No product mindset

Platforms are products. You need a roadmap, user research, NPS, error budgets. Treat your platform like an internal SaaS, not an infra project.

One platform to rule them all

A platform that supports every conceivable workload supports none of them well. Be opinionated. Have a clear answer to “what services should run on the platform?” — and the corollary “and which shouldn’t.”

What “good” looks like

You’ll know it’s working when:

  • A new engineer can ship a real change to production on day one or two.
  • “What’s the right way to…” has a single, known answer for 80% of cases.
  • Service ownership is unambiguous and machine-queryable.
  • Incidents have shorter MTTR because tooling is consistent.
  • Application teams stop writing Kubernetes YAML; the platform team writes it once.
  • The CNCF Platform Engineering whitepaper — short, current, useful.
  • The Backstage docs — go beyond “hello world” to scaffolder templates.
  • “Team Topologies” — the org book. Platform teams are exactly Stream-Aligned + Platform Teams in their model.
  • GitOps with ArgoCD — the deployment leg of an IDP.

If you want a starter Backstage + Argo CD + Crossplane stack with two golden-path templates, it’s on rajpoot.dev .

Building something AI-, backend-, or data-heavy and want a second pair of eyes? I do consulting and freelance work — see my projects and ways to reach me at rajpoot.dev .