What Is an Internal Developer Platform? (2026)
How teams provide shared workflows for creating services, managing infrastructure, and deploying applications.
An internal developer platform (IDP) gives developers a supported way to create services, provision resources, and deploy applications. It packages the organization's infrastructure and development tools into workflows that teams can use themselves.
For a developer adding a service, that can mean getting a database and a review environment through the same process used by other teams. The platform applies the agreed configuration as part of that process, so each project starts with the settings the organization maintains.
We'll also look at how Encore provides backend development and deployment through a managed platform in your own AWS or GCP account, using application declarations to configure infrastructure across environments.
What does an internal developer platform include?
The platform connects these operations to the underlying cloud services and development tools. A request can begin in a portal, a CLI, or a code change. The platform then provisions the resources and applies the configuration needed for the selected environment.
How does the workflow fit together?
An IDP brings a developer's request through to the systems that fulfill it. A service template can supply the repository structure and deployment configuration. The environment workflow creates its resources, and the deployment system builds and releases the application.
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.
The infrastructure team maintains the settings used by those workflows. For a database, that can include the supported engine, access configuration, and backup settings. Developers work with the choices exposed by the platform, while changes to the shared setup can be maintained centrally.
Templates for a common type of service are often called golden paths. They provide a starting configuration the platform team supports. As the organization's tools change, that team updates the templates and the workflows used to deploy them.
Creating and deploying a service
A developer starts with the service definition or template used by the organization and adds the application code. The platform connects the service to its build process and the resources it needs. The developer can then run it locally or deploy it to a development environment, according to the platform's workflow.
A pull request can also trigger a preview environment. That gives reviewers a running version of the proposed change, with the infrastructure it needs for testing. After review, the release workflow deploys the selected revision to production.
Access permissions apply throughout the process. A developer can be allowed to create review environments while production deployment is limited to specified roles. The deployment records identify what was released, and the platform's observability tools show how that version behaves.
Who builds and maintains the platform?
A platform engineering team develops the workflows used by application teams. It maintains integrations with source control, cloud services, and operational tools, and updates the platform as those systems change.
Application teams use the platform and provide feedback about the work it supports. A request for a new database type or deployment pattern becomes a change to the platform's supported capabilities. The platform team can make that capability available across projects once it is configured.
Organizations can build these workflows around existing tools or adopt a managed platform that provides more of them. The choice affects how much software and infrastructure the internal team operates. A managed backend platform can supply provisioning and deployment while the organization maintains its own application standards and cloud access policies.
How does an IDP differ from a developer portal?
A developer portal presents information and actions to developers. It can show the service catalog, API documentation, and a form for requesting an environment. The IDP includes the systems that carry out the request and operate the resulting application.
Backstage is one framework for building that interface. Its catalog and plugins connect to deployment and infrastructure systems maintained by the organization. An IDP can also use a CLI or code-based workflow as its main interface, with a dashboard for inspecting what is running.
How does it differ from PaaS?
A platform as a service provides a managed environment for deploying and running applications. An IDP describes the development experience an organization provides to its own teams, including its chosen tools and configuration. A managed application platform can therefore supply part of an IDP.
The organization can adopt a service with an existing deployment workflow or build one around its infrastructure. Either way, it needs a way to apply its application and access requirements. The IDP and PaaS comparison covers those approaches in more detail.
Does an IDP need Kubernetes?
No. An IDP can provision managed cloud services directly, including application compute and databases. Its workflows use the APIs and tooling of the infrastructure selected by the organization.
Kubernetes can provide the runtime when teams already use it for their applications. The platform then configures workloads and connects them to the other resources they need. The developer-facing workflow can remain the same even when the platform team changes how those resources are provisioned.
A backend platform with Encore
With Encore, developers declare services and infrastructure in application code. The platform uses those declarations to provision and connect the resources in your own AWS or GCP account, then deploys the application through a managed workflow.
A declared database runs as Postgres locally and becomes RDS or Cloud SQL in the cloud. The platform configures access for the services that use it. Developers maintain the resource requirement with their application, using the same declaration across local and deployed environments.
The development tools also generate service and API information from the code. Developers can inspect the application's architecture and follow requests through tracing without separately registering each dependency in a catalog.
Preview environments provide a deployed version of a pull request for testing and review. Environment settings and platform permissions control how teams use the deployment workflow, while the account and provisioned resources remain owned by your organization.
Run in your terminal to get started locally.
Related reading
Frequently asked questions
Does every organization need a dedicated platform team?
No. A team can adopt a managed platform that handles provisioning and deployment, with its own developers maintaining the application configuration. Building custom workflows and integrations requires people to maintain that platform code.
Does each application team need to use the same programming language?
Not necessarily. An internal platform can support multiple runtimes through different templates and deployment workflows. The languages available depend on the tooling and infrastructure the organization chooses to support.
Deploy to your cloud on AWS and Google Cloud
without managing infrastructure
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.
