Internal Developer Platform (IDP): What It Is & How to Build It

What is an Internal Developer Platform (IDP)? 

An internal developer platform (IDP) is a solution or tool that enables developers to access everything they need to develop, deploy and operate applications. An IDP unifies previously fragmented developer experience to “pave a golden path” consisting of self-service tools, services, workflows, processes, support, APIs and more, integrated into a single platform to simplify and accelerate software development while supporting the underlying infrastructure. 

​

Internal Developer Platform versus Internal Developer Portal

The terms are often used interchangeably, but they aren't the same thing. An internal developer portal is the user-facing interface, a service catalogue, documentation hub, or dashboard where developers browse and request what they need.

The internal developer platform is the full system behind it: the automation, orchestration, infrastructure provisioning, and workflows that actually deliver on those requests.
 

Put simply, a portal is the front door. The platform is everything that makes the front door work. Many teams start by building a portal and mistake it for a platform. The section below, "What an IDP Is Not," covers this gap in more detail.​​

Why build internal development platforms?

Platform teams design and build internal development platforms as an internal “product” to support an integrated, self-service developer experience. The resulting IDP is built using the technologies and tools that will lighten the developer's cognitive load and enable developer self-service without removing access to underlying technologies and operations. 

​

IDPs exist to ensure that developers don’t have to do as much heavy lifting on the operations side while also providing some relief for DevOps teams – helping both to focus on the higher-value tasks of their respective roles. 

Platform engineering as a discipline has been built up around the growing need for IDPs in the face of increasing development complexity, especially in the era of cloud native development. Enabling developers with a “single pane of glass” view into what they need to do their daily work simplifies this complexity and supports efficiency, letting developers focus on their core development work across an application’s full life cycle. 

How have IDPs empowered developers in the face of cloud-native complexity?

The cloud-native development paradigm introduced new complexities to application development, despite the promise of faster development and feedback loops and faster feature and solution releases. As a part of this cloud-native shift, the “code-ship-run” responsibilities for applications have often fallen to developers, i.e., the “you build it, you run it, you own it” approach. Yet the range of technologies and tools required on the operations side makes it virtually impossible for a developer to understand and manage everything without some help. More broadly, development teams would struggle to collaborate and work efficiently if every developer started adopting their own preferred tools and workflows. 

​

At an organisational level, requiring developers to understand and unravel the complexities of networking, security, access management, and all the components of coding, shipping and running software places an unnecessary burden on developers. Expecting developers to be responsible for operational tasks also removes their focus from delivering the highest value product they bring to the table: application development. This can have real implications for the business, from slower feature and software delivery to operational inefficiencies to a lack of internal transparency, all of which take away from the supposed benefits of cloud-native software development. 

​

Developers are empowered by IDPs because they get a “paved” or “golden” path in the form of a self-service platform. The platform provides almost no barriers to entry, fast onboarding, and no need to understand underlying operational and infrastructural technology in-depth before developers can start being productive. At the same time, a well-designed IDP isn’t static: it should give application developers some freedom to take on as little or as much operational work as they want. Developers should also be able to contribute new or existing tools or development workflows that they prefer to use, which may benefit all team members and IDP users.

Taking a Platform-as-a-Product Approach

A good IDP that developers actually use is one that evolves with its users and continues to “learn” and adapt to changing requirements and conditions. When software delivery organisations struggle with or fail at implementing an IDP, it is frequently because they created a platform that didn’t have the flexibility to adapt or grow and which quickly became obsolete (or they built something in a vacuum or silo without consulting actual users). 

​

The dynamic nature of the developer experience and the needs of developer teams demand a platform as a product (PaaP) approach. That is, the IDP is managed exactly the same way as product development. IDPs are “evolving products with defined users (developers, operations teams) and life cycles” and are actively managed to ensure that they continue to address business needs in the long term and don’t succumb to platform decay. 

​

A good IDP is a dynamic but permanent internal product rather than a project designed to address a single issue. Adopting this approach asks teams to think about the IDP from a product mindset that strategically supports both developer productivity and experience and aligns with shifting business goals.

What an IDP is and is Not 

While there is no such thing as a universal “one-size-fits-all” IDP, developer platforms are designed to deliver self-service capabilities for developers across the entire software development lifecycle. 

Typical components of an IDP

A successful IDP requires that the organisation understand what the platform needs to deliver (easing the developer journey, relieving developer toil, speeding up and improving product launches, abstracting away the complexities of infrastructure, and so on), for whom and to whom. Fundamentally, what does the platform need to include to achieve these goals? 

​

IDPs usually include some combination of services, tools, and APIs for deployment, CI/CD, security, networking, observability and more. More broadly, it includes application choreography/configuration, deployment management, infrastructure composition, environment management,  role-based access management (RBAC), and platform orchestration.

​

While every IDP will be unique, here is a general overview of the components that an IDP might include:
 

• Developer portal:

  • Central interface where developers can manage environments, deployments, logs, and monitoring. It can include access to APIs, metrics, and tools, etc. A service catalogue is frequently part of this portal, where lists of pre-configured services, libraries or infrastructure components are available for use.

• Version control & collaboration:

  • Centralised code management and team collaboration (e.g., Git, GitHub, GitLab), allowing teams to work on code simultaneously and track changes.

• Automated CI/CD pipelines:

  • Continuous integration (CI): Automates code integration, testing, and validation (e.g., Jenkins, GitLab CI, CircleCI).

  • Continuous deployment (CD): Ensures new code can be quickly and reliably pushed to production (e.g., ArgoCD).

• Self-service infrastructure:

  • Infrastructure-as-Code (IaC): Allows developers to provision and configure cloud or on-premise infrastructure using code (e.g., Terraform, Pulumi,, etc.).

  • Kubernetes & container management: Platforms to deploy and manage applications in containers and orchestrate workloads (e.g., Kubernetes).

  • Service mesh: Enables developers and operations to ensure effective communication between microservices, providing traffic control, security, and observability (e.g., Istio, Linkerd).

• Monitoring & observability:

  • Logging, metrics and monitoring, infrastructure health and tracing are all critical components to things like debugging, performance insights, and distributed tracing for microservices.

• Security & compliance:

  • Security and compliance: Includes everything from role-based access control (RBAC) to secret management to policy enforcement and tools that enable each of these.

• APIs & developer tools:

  • API management: Centralised tools for managing, versioning, and documenting APIs 

  • Development environments: Integrated environments for application development (e.g., cloud-based IDEs, local environments).

• Testing & quality gates:

  • Automated testing (unit, integration and performance testing as part of CI pipeline) and quality control at different stages before reaching production.

• Environment management:

  • Development, staging, and production environments: Pre-configured mock environments for testing that mirror the production environment.

​

What an IDP is not: Moving from portal to platform 

Internal development platforms are designed to serve developers across the full development life cycle, meaning that they need to include, orchestrate and automate the aforementioned functions. Many portal solutions exist that provide a single or limited range of functions, such as service catalogues, application scaffolding, or other “day-one” focused solutions that don’t really address the full range of developer needs. 

​

An IDP brings together and integrates many different technologies and tools that specifically address the full software development and delivery life cycle for an individual organisation. 

Who builds and maintains internal developer platforms?

There are a variety of roles that may contribute to building and maintaining internal developer platforms. 

Platform engineers and platform teams plan and drive the development of internal developer platforms, building, maintaining and optimising what eventually becomes “an opinionated set of practices and tools”. These are typically specialised engineers who focus on building the platform itself, automating infrastructure management, and ensuring that developers can easily deploy, monitor, and scale applications.

​

Operations or DevOps teams work on specifying the resources needed, environment specifications, configurations, and permissions/access management, automating recurring tasks to eliminate repetitive work and to give developers self-service capabilities. They ensure that infrastructure as code (IaC) and automation tools are in place to provision resources. 

​

Site reliability engineers (SREs) may also be involved, securing the reliability, scalability and efficiency of the IDP. They are responsible for monitoring and alerting systems and making sure that the platform can handle production workloads with minimal downtime. 

​

To varying degrees, other roles that may contribute to an IDP include:

​

• Software architects who design the overall structure of the platform to ensure it aligns with business goals and integrates with the existing technology stack

• Cloud engineers who manage cloud infrastructure and optimise resource usage in cloud-native environments;

• Security engineers who help implement security protocols, mitigate risks and vulnerabilities, and ensure compliance

• Product managers who may act as dedicated product managers in cases where organisations manage IDPs as products (i.e., platform as a product).

​

They will work to understand developer needs, plan the roadmap and ensure the platform is fit for purpose from both a developer and business perspective.

What Does an IDP Look Like in Practice?

IDPs generally take one of three shapes:

• Portal-first tools: service catalogues and developer portals (e.g., Backstage-style tools) that provide visibility into services but rely on separate automation.

• Platform orchestrators: frameworks like Kratix (and SKE) that let platform teams compose their own IDP from existing tools, APIs, and infrastructure without vendor lock-in.

• All-in-one platforms: commercial products that bundle portal, CI/CD, and provisioning into a single opinionated stack.
   

The right shape depends on how much of your existing tooling you want to keep versus replace, and how much control your platform team wants over the underlying architecture.

​

The Benefits of an IDP

Adopting an IDP can help organisations realise a number of benefits, including speeding up the development and shipping of new features and applications, gaining operational efficiencies, reducing software developers’ cognitive load, facilitating better developer experience, realising business and customer value faster or some combination of these. 

​

Developers are the primary users of an IDP and, therefore, stand to gain the most from having access to a self-service platform that enables a faster ramp-up to productivity and a sustained focus on writing code and delivering customer value.

Key Internal Developer Platform attributes

Several attributes are key to making IDPs successful at supporting the development organisation: 

​

• Centralisation and standardisation: Across teams, centralising the same set of technologies and tools reduces time spent trying to manage processes, tools and workflows that are provided by default in the platform and cuts the risk of errors. 

• Collaboration and communication: A centralised platform makes it easy for development team members to cooperate and also to share and collaborate with other teams in the organisation, such as security or operations.

• Productivity gains: Removing the cognitive load and repetitive work involved in setting up environments, configuring build pipelines or provisioning databases, and other tasks that can be centralised and automated in an IDP frees developers up to focus on writing code and delivering business value.

• Self-service convenience: Developers who are new to the organisation or the team - or new to being developers - can speed time to productivity by skipping over steep learning curves and jumping right into the paved path to onboarding by accessing the self-service convenience of a well-designed IDP.

When is the Time to Build an IDP?

Organisations of all sizes can eventually face a critical problem: cognitive overload and reduced developer productivity. While an organisation does not need to wait until developers hit the wall or for the team to reach a certain size to invest in an IDP, there are some considerations to help determine when the investment makes the most sense: 

​

• Is the development team growing (and how fast)? 

• Will the growth of development teams increase complexity, and if so, will an IDP help ease this complexity? 

• How important is sharing institutional knowledge, best practices and the same tools and workflows? 

• How fast or challenging is onboarding currently, and how could this be sped up with an IDP?

• How much time are developers currently spending on operational tasks, and has this interfered with development tasks and software launches?

• Have you identified duplicative efforts in different parts of the engineering organisation where different teams are creating their own “platforms” in silos?

• Are DevOps teams overwhelmed and unable to optimise and improve? 

​

It is never too early to think about centralising developer self-service and streamlining tools and methods for greater productivity.

Learn More About Internal Developer Platforms