Internal Developer Platforms (IDPs):
Why, What, and How

What is an Internal Developer Platform? 

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. 

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 make 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 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.

The Evolving Internal Developer Platform: 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 demands 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 Internal Developer Platform 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 internal developer platform

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 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 catalog 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 internal developer platform 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 catalogs, 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 make 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.

The Benefits of an Internal Development Platform

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 Internal Developer Platform?

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.​

​

Do You Have Questions About Internal Developer Platforms (IDPs)? Get in Contact

Please contact us with questions about designing and building platforms or implementing platform orchestrators.

You can also learn more about Kratix, our platform orchestration framework for building composable internal developer platforms, at kratix.io.

Learn More About Internal Developer Platforms