The 5 Best Tools for Building an Internal Developer Platform in 2026

Every platform team knows the failure mode: developers file tickets for namespaces, databases, environments, and access, and the platform team becomes a human queue in front of the infrastructure. An internal developer platform (IDP) exists to break that queue — to give developers a paved road to what they need, with the organization's standards and guardrails built in.

The hard part is choosing what to build it with. "IDP tooling" spans at least three different product categories — developer portals, infrastructure control planes, and workflow automation — and most comparison lists blur them together. This guide covers the five best tools for building an internal developer platform in 2026, what layer of the platform each one actually solves, and how to combine them. (Disclosure: we build Kestrel, one of the tools covered — we've kept the comparisons factual and noted where alternatives are the better fit.)

What is an internal developer platform?

An internal developer platform is the layer between your developers and your infrastructure: a curated set of golden paths that let engineers provision, deploy, scale, and debug without needing to understand — or have direct access to — every underlying system. A good IDP replaces tickets with self-service, and replaces tribal knowledge with codified standards: every namespace gets the right quotas and RBAC, every S3 bucket gets encryption and cost tags, every production change gets an approval.

Crucially, an IDP is a product, not a project — it's never "done", and it only earns adoption if the paved road is genuinely faster than going around it. We've written about this product mindset in our platform engineering best practices guide, and about how AI is changing what the platform interface looks like in Platform Engineering in the Age of AI: increasingly, the "portal" is a plain-English request in Slack, not a web form.

How to choose an IDP tool

The tools below come from three distinct categories, and the right starting point depends on which problem is costing you the most today:

• Workflow automation— fulfills developer requests end to end: provisioning, scaling, deployments, investigations. This is the layer that actually removes tickets from the platform team's queue.
• Developer portals — give developers a catalog of services, ownership metadata, scorecards, and a UI for self-service actions. Strong on discoverability; the actions still need automation behind them.
• Control planes— standardize how infrastructure is provisioned declaratively. Strong as a provisioning primitive; they don't provide a developer-facing interface or handle day-2 operations.

Whichever category you start with, evaluate tools on the same four criteria: time to first golden path (days or quarters?), integration breadth across your real stack, governance (scoped permissions, approval gates, audit trails), and the developer interface (do engineers get answers where they already work, or do they learn another portal?).

The 5 best tools for building an internal developer platform

1. Kestrel

Kestrel approaches the IDP from the self-service layer: instead of building a portal and wiring automation behind it, you build the automation first and let developers request what they need in plain English — from Slack, the CLI, or the in-platform agent. Each request is matched to a governed workflow the platform team has defined, parameters are extracted from the phrasing, and the workflow runs deterministically inside that team's permission fence — with approval gates wherever blast radius demands one.

Building the golden paths themselves is where Kestrel compresses the timeline from quarters to days. A platform engineer describes each request workflow in plain English and the Workflow Agent assembles it — trigger, actions, conditions, approval gates — against 30+ integrationsspanning Kubernetes, AWS, databases (PlanetScale, Supabase, Neon), deployments (Vercel, Railway, Fly.io), CI/CD (GitHub, ArgoCD, Helm), observability (Datadog, PostHog), and AI compute (Nebius, Daytona). The result is an explicit, versioned workflow you review on a canvas before it goes live — not a black-box agent improvising against production. Here's what a golden path looks like on Kubernetes, where most "can you just" requests land:

Click to expand

The same pattern extends across the rest of the stack. A cloud infrastructure request on AWS, with cost and blast radius fenced behind an approval:

And a GPU compute request on Nebius, where self-service matters most because the cost does:

Click to expand

Governance is the part that makes self-service safe to offer at all: every workflow is fenced to specific clusters, namespaces, cloud accounts, and repositories; approval gates can sit anywhere in the graph and be answered from Slack, the dashboard, or a pull request; and every run is logged step by step. Requests that don't match an existing workflow land on a queue with an AI-drafted workflow proposal — so the platform's coverage compounds instead of plateauing.

The same layer also covers what portals and control planes leave out: day-2 operations. Because the platform's golden paths are workflows, they can be triggered by signals as well as requests — a failed deployment triggers an investigation and a gated rollback, a crash-looping workload triggers a root cause analysis posted to the owning team, a cost anomaly triggers a scale-down proposal. The platform doesn't just provision resources; it operates them. We've documented what this looks like per platform in the automation guides for Kubernetes and AWS.

For the full walkthrough — golden paths across Kubernetes, AWS, Cloudflare, PlanetScale, Vercel, GitHub, Datadog, and more, with copy-paste prompts for each — see Build an Internal Developer Platform with Kestrel Workflows.

Best for: teams that want a working, governed self-service platform in days — without dedicating headcount to building and maintaining a portal.

2. Backstage

Backstage, the open-source developer portal framework Spotify donated to the CNCF, is the most widely adopted answer to the discoverability problem: a software catalog that maps every service to its owner, docs, and dependencies, plus software templates for scaffolding new projects on the golden path. Its plugin ecosystem is unmatched — there is a community plugin for nearly everything — and because it's a framework, you can shape it into exactly the portal your organization needs.

That flexibility is also the well-known tradeoff: Backstage is a framework, not a product. Teams typically dedicate one or more engineers to building and operating it, time-to-value is measured in quarters, and automation beyond scaffolding means writing custom plugins. The catalog tells developers where things are; fulfilling their requests still needs an automation layer behind it.

Best for: organizations with hundreds of services that need a catalog and are willing to staff a portal team to get a fully customized developer experience.

3. Port

Port is a managed internal developer portal: a flexible software catalog built on customizable blueprints, scorecards for tracking standards adoption, and self-service actions developers trigger from the portal UI. Compared to Backstage, Port trades the unlimited customization of a framework for a much faster setup — no plugin development, no portal team — which has made it the default choice for teams that want a portal without building one.

The consideration is that Port's self-service actions are frontends: each button needs a backend — a CI job, a webhook handler, or a workflow engine — that actually performs the work, and that backend is yours to build and govern. Port organizes and exposes your platform; it doesn't automate it.

Best for: teams that want catalog, scorecards, and a self-service UI quickly, and already have (or plan to build) the automation behind each action.

4. Crossplane

Crossplane, a CNCF project, turns a Kubernetes cluster into a universal control plane: cloud resources — an RDS instance, a GKE cluster, a VPC — become Kubernetes custom resources, provisioned and continuously reconciled by providers. Platform teams compose low-level resources into higher-level abstractions ("a PostgresInstance") that encode the organization's standards, so developers consume a simple API while the platform controls what it actually creates.

As a provisioning primitive it's excellent — declarative, drift-correcting, and GitOps-native. But it's deliberately only that layer: there's no developer-facing request interface, no approval gates, and no day-2 operations story (incidents, rollbacks, investigations). Authoring and maintaining compositions is real engineering work that lands on the platform team.

Best for: Kubernetes-centric organizations that want infrastructure provisioning as declarative, reconciled APIs and have the platform engineering capacity to build the abstractions.

5. Kratix

Kratix is an open-source framework for building platforms as a product: platform teams define Promises— versioned, self-contained definitions of a capability like "a Postgres database" or "a Jenkins instance" — and Kratix handles scheduling the workloads that fulfill each request across fleets of clusters. It's an opinionated take on platform-as-product thinking, and it composes well with Backstage (as the frontend) and Terraform or Crossplane (as the provisioning engine).

Kratix is the youngest tool on this list, and it shares the framework tradeoff: Promises are code you write and maintain, the ecosystem of off-the-shelf Promises is still small, and — like Crossplane — it covers provisioning rather than the full request lifecycle.

Best for: platform teams that think in platform-as-a-product terms and want an open-source, multi-cluster framework for packaging capabilities as versioned Promises.

Portals, control planes, and automation: how the pieces fit

These five tools compete less than the listicle format suggests, because they solve different layers of the same problem. A portal (Backstage, Port) gives developers a map of the platform; a control plane (Crossplane, Kratix) standardizes how infrastructure is created; workflow automation (Kestrel) is the layer that receives a request, applies the guardrails, performs the work across every system involved, and reports back. Mature platforms often run more than one: Port as the catalog, Crossplane for declarative provisioning, Kestrel fulfilling requests and handling day-2 operations.

The practical advice: start with the layer that removes the most toil. If your platform team's queue is full of provisioning and "can you just" requests, start with the automation layer — it delivers self-service on day one and doesn't require a portal to be useful. Add a catalog when discoverability, not fulfillment, becomes the bottleneck. For a broader comparison of the automation layer specifically, see the 10 best platform engineering workflow automation tools.

Common mistakes when building an IDP

Three failure patterns show up repeatedly in platform initiatives, regardless of tooling. First, building the portal before the paths: a beautiful catalog over a platform where every action still opens a ticket changes nothing about developer experience. Second, self-service without governance: handing out cloud permissions is not a platform — the value is in the guardrails, and a golden path that can't enforce quotas, tags, and approvals will be bypassed the first time it's inconvenient. Third, treating launch as done: adoption compounds only if the platform keeps absorbing new request types. Instrument what developers ask for, and let the unmatched requests drive the roadmap.

FAQ

What is the best tool for building an internal developer platform?

It depends on the layer. For the self-service and automation layer — the part developers actually feel — Kestrel is the leading choice: plain-English requests fulfilled end to end by governed, approval-gated workflows. Backstage and Port lead the portal layer, and Crossplane leads the open-source control-plane layer. Many teams combine them.

How do you build an internal developer platform?

Start from the requests developers actually make, not from a portal UI. Codify each request as a governed golden path with your standards baked in, scoped to what the requesting team may touch, with approvals on anything production-facing. Ship one golden path, measure how many requests it resolves without a human, then expand coverage.

What are the best open source tools for building an IDP?

Backstage (developer portal, CNCF), Crossplane (control plane, CNCF), and Kratix (platform framework) are the strongest open-source options. All three are frameworks rather than products — budget engineering time to assemble and operate them.

Do you need Backstage to build an IDP?

No. A portal is one possible interface, not a prerequisite. Many teams run effective platforms where the interface is a plain-English request in Slack or a CLI, routed to governed workflows. Add a portal when catalog and discoverability become the bottleneck.

How long does it take to build an internal developer platform?

Portal frameworks typically take a dedicated team one to two quarters; control planes require ongoing composition authoring. A workflow-automation approach compresses this to days: with Kestrel, each golden path is described in plain English and built by the Workflow Agent in minutes. The workflows quickstart walks through the first one.

Getting started

If the automation layer is where your platform effort should start, Kestrel is the fastest way to prove it: connect your integrations, describe your first request workflow in plain English, and put a governed golden path in front of developers the same day. The full IDP walkthrough with copy-paste prompts is in Build an Internal Developer Platform with Kestrel Workflows.