What is an internal developer platform? IDP explained

An internal developer platform (IDP) is a self-service layer built by an organization that standardizes infrastructure, tools, and workflows into a product-like experience for that organization’s internal developers. Its goal is to abstract away operational complexity, enforce guardrails, and give developers “golden paths” — predefined workflows or sets of best practices—to build and deploy software quickly and safely. IDPs are the flagship product of so-called platform engineering teams, serving as the structural glue between dev, ops, and business goals.

As cloud computing, containerization, devops, and microservice architectures have established themselves as the building blocks for modern application development, IDPs have emerged as a simple way to manage those resources for internal software developer teams. At many elite engineering organizations — think Google, Netflix, and Amazon— IDPs ease the operations load on their devops teams, while abstracting away unnecessary decisions for software developers, and other companies and organizations have also moved to take advantage of the concept. A good IDP should relieve developers of the burden of making infrastructure decisions, enable self-service environment builds, integrate with existing continuous integration and delivery (CI/CD) and deployment processes, and assign role-based access controls, all without a developer ever having to learn YAML.

The idea might remind you of a developer portal (e.g., catalogs, Backstage-style UIs). But a portal is just a piece of the larger picture; a platform also embeds automations, enforcement, APIs, and self-service

The benefits of an internal developer platform

In the 2024 edition of the Puppet’s State of DevOps survey, respondents consistently cited “increased productivity,” “better quality of software,” and “reduced lead time for deployment” as the top benefits delivered by their internal platform teams, and the 2024 DORA report found that IDPs “effectively increase productivity for developers.” A fully functioning internal platform should ease the complexity burden of modern software systems, speeding up software deployment cycles and creating more stable releases, as well as improving developer happiness and productivity, all while lowering the operational burden.

Modern internal developer platforms can also boost developer experience outcomes. Developer experience isn’t just about front-end polish but applies equally to back-end workflows and provisioning, and IDPs can reduce cognitive load and accelerate day-to-day work for developers by reducing context switching and lowering error rates arising from misconfiguration.

Who needs an internal developer platform?

An internal developer platform has two core user groups, each with its own view: the platform/operations/devops team and the developer team.

For platform and operations engineers, the IDP is the product they build and maintain. They configure the APIs into infrastructure and tools, establish security and compliance guardrails, and continuously evolve the platform based on user feedback. In many organizations, this is the work of a dedicated platform engineering team staffed not just with SREs or devops practitioners, but also with product managers who treat the IDP as an internal product with roadmaps, metrics, and user research.

“That product mindset is key to the success of an internal platform,” said James Whinn, CTO of Expert Thinking, a cloud consulting company. “Without it, teams will focus on stuff because it is cool and not necessarily what will provide business value.”

For developers, the IDP provides a streamlined, opinionated path to deployment. Instead of wrestling with YAML files or negotiating with multiple teams for access, they get self-service environments, standardized workflows, and a “golden path” to production. The balance is delicate. “It has to be flexible for the devops team but inflexible for the developers,” said Kaspar von Grünberg, the CEO of Humanitec, a startup founded in 2018 to help companies establish an internal platform. “All customization capability should reside with the devops team and create golden paths for developers who don’t want to think about the underlying infrastructure.”

But by doing that, aren’t we just separating dev and ops all over again?

Nigel Kersten, field CTO at Puppet, says that it is imperative that the teams responsible for the operational health of the platform need to be entwined with the people building solutions on top of it and, ideally, are the same group. “If you separate those, you end up in the old world of dev versus ops,” he said.

IDP vs. PaaS

It’s tempting to think of internal developer platforms as just another version of platform as a service (PaaS). The distinction lies in who controls the abstraction.

Traditional PaaS: Many smaller organizations turn to a PaaS to get their engineering team up and running quickly. Popular choices include Heroku, acquired by Salesforce in 2010, along with Cloud Foundry and OpenShift. Newer players like Vercel and Netlify and vendor tools like Google’s Cloud Run and AWS’s Copilot, provide serverless-style abstractions as managed services. But these often lack the flexibility to truly scale out.

Internal developer platforms: IDPs aren’t based on a vendor’s fixed workflows. Rather they’re custom-built (or assembled from vendor components) around the organization’s existing toolchains and compliance needs. The abstractions are designed by internal platform teams, with the flexibility to evolve and the guardrails needed for governance.

As the Google technologist Kelsey Hightower tweeted in 2017, “I’m convinced the majority of people managing infrastructure just want PaaS. The only requirement: It has to be built by them.”  Still, opting for the IDP approach does lead to the risk of engineers looking to reinvent the wheel when given the chance to build their own platform, or worse, trying to run like Amazon or Google, which is a recipe for distraction and disaster.

“Even when those big companies provide their solutions as open source software, they often encode all kinds of assumptions about the surrounding ecosystem of available products and the culture and needs of the engineers using the product that may not work well in your company,” Camille Fournier, head of platform engineering at the hedge fund Two Sigma, wrote. “It is not good product management to say, ‘Google does it, therefore we should.’”

Puppet’s Kersten, an ex-Google SRE himself, sees things in a similar light: “We have seen numerous large organizations try to adopt the small autonomous teams’ model, which works at Amazon as they have hugely skilled developers, but everything there is built as a service; they aren’t as regulated or limited by legacy software. [For other organizations, though,] it creates chaos and organizational debt.”

Where to start with an internal developer platform

Moving from a monolithic deploy process to continuous delivery is a major cultural change, and not one to be underestimated. “I believe it’s actually not that hard to start a small organization with a ‘you build it, you run it’ mindset, but making the transition takes courage and continuity of vision,”  wrote Evan Bottcher, head of engineering at ThoughtWorks.

Kersten has seen too many companies try to rebrand their existing processes as an internal platform because it is the latest buzzword. “One of the biggest antipatterns we have seen is rebadging central IT to a platform team but not making the technical or cultural changes required. As the term gains popularity, we expect to see more of this,” he said.

Shifting to an internal developer platform or deciding to build one from scratch can also be a difficult thing to sell into a wider organization, from convincing management to make such a big shift to making developers comfortable with a new way of working that they don’t have total control over.

“Having the capability to understand users and make those cultural changes is the bigger problem,” Kersten said.

His and many other experts’ advice: Start small. Expert Thinking’s Whinn advised: “Stand up a center of excellence and identify use cases where the platform could be developed to make a real difference.” Even standing up a test environment for a single application and building out the required APIs from there can help a platform team get on the right path. Small grassroots initiatives, like those at Zalando and Yelp, often grow into full IDPs.

One way to think about this is as the thinnest viable platform, or “being explicit about what about the platform is important and ensuring it is no bigger than necessary,” said Matthew Skelton, one of the authors of Team Topologies, during the Devops Enterprise Summit in 2019. “We need to make sure whatever we build is compelling to use, has strong developer experience, and treating users as customers who we need to speak to so we can understand their needs and meet them.”

Kaspar von Grünberg, CEO of Humanitec, said, “It is the same if you build or buy: You have to start at the grassroots level.… We usually see organizations take a small group of their best engineers and ask them to be the glue across segregated tool chains. Then you start to centralize this around a common API that teams can work against and bring structure to that sea of unstructured tools.”

A look ahead: Gen AI and platform automation

As is true everywhere in the world of software development, IDPs are being transformed by the generative AI wave. Platform teams are experimenting with AI assistants that generate pipeline configurations, scaffold deployment templates, and even suggest best practices in real time. For example, Red Hat’s Developer Hub has begun shipping AI-powered templates for common workloads — such as chatbots and transcription services — that can be provisioned through an internal portal.

These integrations aim to reduce repetitive toil for both developers and platform engineers. Instead of hand-coding YAML or Terraform modules, engineers can ask an assistant to scaffold a compliant template that adheres to organizational guardrails. Platform teams can then focus on reviewing and evolving these golden paths rather than manually fielding support requests.

The opportunity is significant, but so are the risks. Automated code and configuration generation requires strong oversight and may not deliver on its productivity promises. But their continuing impact on IDPs seems inevitable.