What Is an Internal Developer Platform? (2026)
The self-service layer between developers and infrastructure, the problem it solves as an org grows, and the shapes it takes in practice
When Spotify open-sourced Backstage in 2020, it was releasing infrastructure it had built to survive its own growth. The company had grown past the point where a developer could reasonably know which of its hundreds of services existed, who owned them, how to spin up a new one the right way, or where to look when a request failed halfway across the system. The answer they built, a single place developers went to do all of that themselves, is what the industry now calls an internal developer platform, and thousands of companies adopted Backstage because they were hitting the same wall.
An internal developer platform, or IDP, is the self-service layer that sits between developers and the infrastructure their code runs on. Instead of filing a ticket for a database, waiting on an operations team for a new environment, or copying last quarter's CI config into a new repository and hoping it still works, a developer goes to the platform and gets what they need with the organization's standards already applied. The platform handles provisioning, deployment, and observability inside guardrails the company has agreed on, which keeps developers moving without letting every team reinvent how software gets shipped.
The problem an IDP solves
The need shows up at a predictable point in a company's growth. Early on, five engineers can hold the whole system in their heads and set things up by hand. As the org crosses into the dozens and then hundreds of developers, three costs start to compound.
The first is cognitive load. A developer trying to ship a feature ends up learning Terraform, the CI system, the cloud console, the observability stack, and the tribal knowledge of how this particular company wires them together, none of which is the feature they were hired to build. The second is inconsistency. Every team that sets up its own infrastructure does it slightly differently, so you accumulate a long tail of one-off configurations that are hard to secure, audit, or reason about. The third is the operations bottleneck. When provisioning and deploys route through a central platform or ops team by ticket, that team becomes the constraint on how fast everyone else can move, and it spends its days on repetitive requests instead of the harder infrastructure work only it can do.
An IDP attacks all three at once by turning the common cases into self-service. The platform team encodes the approved way to do a thing once, and every developer gets it on demand without a ticket and without deciding for themselves how it should be configured.
What an IDP includes
A working internal developer platform generally covers five capabilities, layered from the paved-path experience developers touch down to the infrastructure underneath.
The layers of an internal developer platform: a self-service developer interface on top, golden paths and environments in the middle, and infrastructure provisioning, observability, and access control underneath, all sitting on the org's own cloud account.
Self-service infrastructure. Databases, queues, caches, object storage, and networking provisioned on demand with the right security policies and sizing already baked in. The developer asks for a Postgres database; the platform gives them one that matches the org's standards without them touching a cloud console.
Environments. The ability to spin up preview, staging, and production environments with consistent infrastructure, ideally a full environment per pull request so changes can be tested in isolation before they merge. Getting this right is what lets teams review a change as a running system rather than as a diff.
Golden paths. Scaffolding for how a new service should be created and deployed, so every team starts from the same shape: the pipeline, the container build, the infrastructure declarations, the observability wiring. Golden paths are how the platform encodes "this is how we do it here" without mandating it through review.
Observability. Distributed tracing, metrics, and logging integrated across services, so when a request fails in production a developer can follow it through the system without having instrumented anything by hand.
Access control. Who is allowed to provision what, deploy where, and read which data. This is the governance layer that lets a platform be self-service without being a free-for-all, and it is what makes an IDP safe to hand to hundreds of developers.
Any one of these is a real project. Making all five behave as one coherent experience, where the catalog reflects what is running in production and the preview environment carries the same observability, is the hard part and the reason platform engineering exists as a discipline.
How it relates to platform engineering and PaaS
Platform engineering is the discipline that builds and runs the IDP. A platform team treats the platform as an internal product, with developers as its users, and measures itself on whether those developers can move faster and more safely because of it. The internal developer platform is the artifact; platform engineering is the practice of designing, shipping, and maintaining it as needs change. When people say a company "does platform engineering," what they usually mean is that a dedicated team owns the IDP rather than leaving each product team to assemble infrastructure on its own.
The comparison to PaaS is worth drawing because the two overlap in what a developer feels. A platform as a service like Heroku, Railway, or Render also lets a developer deploy without touching infrastructure, but it does so by running the app on the vendor's platform with the vendor's opinions, and you accept those defaults as the price of the simplicity. An IDP usually runs on your own cloud account and encodes your organization's standards, which is why it tends to appear once a company is large enough to have standards worth encoding. A PaaS is bought and used as-is; an IDP is built or adopted and then shaped to the company. The line between them blurs with the newer code-first platforms, which is covered below. The longer comparison works through where each fits.
What IDPs look like in practice
There is no single reference implementation. The shape a company lands on depends on what it already runs and how much platform work it wants to own.
| Approach | Example | What it is | Best fit |
|---|---|---|---|
| Portal framework | Backstage | Open-source catalog and plugin framework you deploy and wire to your own CI/CD and cloud | Large orgs with a platform team that wants full control |
| Managed portal | Port, Cortex, OpsLevel | Hosted catalog, scorecards, and ownership tracking with less assembly | Teams that want the catalog layer without maintaining Backstage |
| Kubernetes orchestrator | Humanitec | Self-service abstraction over Kubernetes for environments and deploys | Orgs already committed to Kubernetes |
| Code-first platform | Encore | Platform derived from how the app is written, rather than assembled from tools | Teams on AWS or GCP wanting self-service without running the plumbing |
The portal-based approach, most often Backstage, gives you a service catalog and a plugin system you extend to cover the rest. It is powerful and fully yours, and it asks for a team that can write and maintain plugins and keep the catalog reflecting reality. The Backstage alternatives landscape exists largely because that maintenance burden is real. Managed portals like Port, Cortex, and OpsLevel take the catalog and scorecard layer off your hands but cover that layer alone, so you still supply provisioning, environments, and deploys around them. Humanitec sits lower down, adding a self-service abstraction over Kubernetes for teams that have already committed to it. Each of these is a strong fit for the situation it targets, and the broader tooling survey maps out where they overlap.
Code-first platforms take a different route. Instead of assembling a portal on top of infrastructure, they derive the platform from the application code itself, which collapses several of the five layers into one place.
Where Encore fits
Encore is one example of a code-first internal developer platform. It is a backend framework, in TypeScript on a Rust runtime and in Go, paired with a cloud platform, and the self-service experience comes from how you write the application rather than from a portal you assemble beside it. You declare infrastructure as typed objects in your code, a Postgres database, a Pub/Sub topic with delivery guarantees, a cron job, an object storage bucket, and Encore provisions the matching cloud resources into your own AWS or GCP account with sensible defaults you can adjust in the dashboard.
import { SQLDatabase } from "encore.dev/storage/sqldb";
import { Topic } from "encore.dev/pubsub";
// Declaring infrastructure is declaring a typed object in your app.
// Encore provisions the real resource in your AWS or GCP account.
const db = new SQLDatabase("orders", { migrations: "./migrations" });
interface OrderPlaced { orderId: string; }
const placed = new Topic<OrderPlaced>("order-placed", {
deliveryGuarantee: "at-least-once",
});
Because the platform reads the application, several IDP capabilities come from the code without separate wiring. A service catalog and an architecture diagram are generated from what the app declares, distributed tracing is built in, environments including preview environments per pull request are provisioned automatically, and services call each other through type-checked functions rather than hand-maintained HTTP clients. It provisions into your own cloud rather than a vendor's, and encore build docker exports a standard container image, so the app is not locked to the platform. For teams that already have investments in infrastructure code, a Terraform provider exposes provisioned resources as data sources.
Encore is a different category from the portals and orchestrators above. It is not a developer portal in the Backstage sense, so it does not aim to be a catalog you register arbitrary services into or a plugin framework for cataloging systems you run elsewhere. If your goal is a single pane of glass over a heterogeneous estate spanning many languages and runtimes, a portal like Backstage or Port is the better fit. If your goal is a self-service backend platform for services you are building on AWS or GCP, and you are working in TypeScript or Go, a code-first platform covers provisioning, environments, and observability without a platform team assembling and maintaining the pieces.
Related reading
Frequently asked questions
What is an internal developer platform?
An internal developer platform, or IDP, is the self-service layer developers use to provision infrastructure, deploy code, and observe their services without filing tickets or waiting on an operations team. It packages an organization's approved ways of running software into paved paths, so a developer can get a database, an environment, or a deploy on their own while the platform applies the security and configuration standards the org has agreed on.
What is the difference between an IDP and a PaaS?
A PaaS like Heroku or Render runs your app on the vendor's infrastructure and hides the cloud entirely. An internal developer platform usually sits on top of your own cloud account and your own tools, encoding your organization's standards rather than a vendor's opinionated defaults. A PaaS is something you buy and use as-is; an IDP is something a platform team assembles or adopts and then shapes to fit how the company already builds and runs software.
What are the core components of an internal developer platform?
Most IDPs cover five things: self-service infrastructure provisioning for resources like databases, queues, and caches; environment management, including preview and staging environments; golden paths that scaffold a new service the approved way; observability with tracing, metrics, and logs across services; and access control that decides who can do what. The value comes from these working together as one experience rather than as five separate tools.
What is the difference between platform engineering and an internal developer platform?
Platform engineering is the discipline; the internal developer platform is the product it builds. A platform team studies how developers spend their time, treats the platform as a product with users and a roadmap, and ships the self-service capabilities that reduce cognitive load. The IDP is the running result of that work: the catalog, the paved paths, the provisioning, and the observability developers use day to day.
Do you need Kubernetes to run an internal developer platform?
No. Kubernetes is common underneath IDPs because many teams already run it, and tools like Backstage and Humanitec assume it, but it is not a requirement. Plenty of platforms provision managed cloud services directly, and code-first platforms deploy your services without exposing a cluster at all. Adopting Kubernetes purely to have an IDP adds a large operational surface for a small team, so it is worth checking whether you need it before taking it on.
What are examples of internal developer platforms?
There is no single shape. Many companies build a portal on Backstage, Spotify's open-source framework, and wire it to their CI/CD and cloud. Managed portals like Port, Cortex, and OpsLevel cover the catalog and scorecard layer. Humanitec adds a self-service abstraction over Kubernetes. Code-first platforms like Encore take a different route, deriving the platform from how the application is written rather than assembling it from separate tools.
Ship without waiting on Terraform
Encore lets developers and agents define application infrastructure directly in code, then automatically provisions it from local development to production in your AWS or GCP account.
