An internal developer platform (IDP) gives developers self-service access to environments, infrastructure, and deployments behind standardized guardrails. The strongest 2026 internal developer platforms split into two layers: provisioning and orchestration engines that build real infrastructure (Facets, Humanitec, Qovery, Appvia Wayfinder, Mia-Platform) and developer portals that catalog and govern it (Backstage, Port, Cortex, OpsLevel).
The defining shift in 2026 is that an IDP now has to be AI-operable, not just developer-operable. The audience for self-service is no longer only human developers filing fewer tickets. It is also the AI agents those developers delegate to, and an agent needs a platform it can read, reason about, and safely act on through a programmatic surface, not a dashboard it has to click through. That shift exposes a limit in the portal-only model. A catalog and scorecard layer sitting on top of infrastructure that someone else provisions is becoming a thinner value proposition, because the thing both developers and agents actually want is frictionless, interoperable access to provisioning itself, not another dashboard to populate and maintain. The portal layer still earns its place where the genuine gap is visibility and governance over an estate you already provision. It just stops being the whole story.
Most teams reaching for an IDP are trying to solve the same tension. Developers want to ship without filing infrastructure tickets, while platform and security teams need consistency, compliance, and cost control. The two layers above answer different halves of that tension. An orchestrator decides what infrastructure exists and enforces how it is provisioned across environments. A developer portal makes the resulting estate visible, scored, and governed. Picking the right tool starts with knowing which half is actually your bottleneck, and increasingly with knowing whether that half is one an AI agent can operate on your behalf. If you are still deciding whether environment consistency is your real problem, our breakdown of how to compare microservices across environments using Facets is a useful companion read.
What an IDP actually changes
The point of an IDP is to move infrastructure decisions out of the ticket queue and into a path developers can take themselves, without removing the controls platform and security teams depend on. Concretely, that shows up in a few mechanisms rather than a list of benefits.
A self-service path replaces the ticket round-trip. Instead of a developer opening a request, waiting for a platform engineer to hand-write a database, a queue, and the IAM bindings between them, the developer picks from a paved road: a pre-approved template where the IAM policy, network placement, and tagging are already decided. The cognitive load that disappears is real (knowing which subnet, which role, which encryption setting) because someone encoded the right answer once.
Guardrails are applied by default rather than after an incident. Role-based access control, maker/checker approval gates, and policy checks run on the provisioning path itself, so a non-compliant resource is rejected before it exists rather than flagged in an audit weeks later.
Drift detection closes the gap between what was declared and what is actually running. When a resource is changed out of band (a console click, a one-off patch), the platform can detect that the live state no longer matches the declared state and either flag it or reconcile it back. That is the difference between "we think production matches staging" and knowing it does.
Cost and resilience follow from consistency, not from a separate feature. Reproducible environments make idle non-production spend visible because every environment is built the same way and can be torn down the same way, and they make failover and rollback predictable because there are no snowflake configurations to surprise you.
There is one more mechanism that matters more every quarter: the provisioning path is becoming the surface AI agents act on. When the self-service path is a structured, declarative contract rather than a UI workflow, an agent can plan a change against it, reason about blast radius, and apply it under the same guardrails a human would, because the rules live on the path and not in a person's head. That is what AI-operable means in practice, and it is why the durable layer of an IDP is shifting toward provisioning and orchestration that an agent can drive, rather than a portal an agent can only describe.
The caveat is that an IDP is not free leverage. It is a system you adopt and operate, and the wrong layer for your problem adds friction instead of removing it. That is why selection matters.
How to choose
The goal of an IDP is to reduce the friction developers and the agents working alongside them face, not to add another layer of process. Evaluate candidates against six criteria, and read each one through the two-layer split: are you trying to provision and orchestrate infrastructure, or to catalog and govern what you already provision?
Scalability
The platform should grow with you across teams, environments, and clouds without forcing a rewrite. Ask whether it handles multi-environment and multi-cloud estates natively, or whether scale is something you bolt on later.
Integration
An IDP lives in the middle of your toolchain. It should extend your existing CI/CD, observability, secrets, and cloud accounts rather than replacing them. The best tools meet your stack where it is instead of demanding you rebuild around their opinions.
Ease of use
Self-service only works if developers can use it without reading a manual. Weigh the day-one developer experience against the day-one platform-team setup cost, because those two are often in tension.
Security and governance
Role-based access control, approval workflows, audit trails, and policy enforcement should be first-class, not afterthoughts. A platform that simplifies provisioning while weakening governance is a poor trade.
Cost
Account for both the license or SaaS per-seat cost and the operational cost in platform-engineering time. A "free" framework you build and maintain yourself can be the most expensive option once you price in the people who run it.
AI-operability
Ask whether an AI agent can actually operate the platform, not just read from it. The test is concrete: is the self-service path a structured contract an agent can plan a change against, assess blast radius on, and apply under the same role-based access control and approval gates a human gets, all through a programmatic interface? A platform that only exposes a catalog for an agent to describe is far less useful in 2026 than one whose provisioning path an agent can safely drive. This is the criterion that most cleanly separates a provisioning-and-orchestration engine from a portal that sits on top of one.
The platforms, by layer
The list below is organized into the two layers introduced above. Provisioning and orchestration IDPs build and manage real infrastructure. Developer portals and governance layers catalog, score, and govern services but do not provision infrastructure, so they coexist with an orchestrator rather than replace it. Each entry follows the same pattern: capabilities, benefits, the limitation worth knowing, and an explicit note on where the tool sits relative to Facets.
One note on scope: earlier editions of this list included Portainer, but it is a container and Kubernetes management tool, not an internal developer platform. It does not provision multi-environment infrastructure from a self-service blueprint or act as a developer portal, so we dropped it and added the portal layer (Backstage, Port, Cortex, OpsLevel) the category now expects.
Provisioning and orchestration IDPs
These tools build and manage actual infrastructure. They decide what exists, provision it across environments, and enforce how it stays consistent.
Facets
Facets is an AI-native SDLC orchestrator and internal developer platform that provisions real infrastructure rather than only cataloging it. The model is a blueprint: a declarative description of an application and the resources it depends on (its services, datastores, queues, and the relationships between them). Rather than describing each environment by hand, a team defines the blueprint once, and Facets resolves the dependency graph and provisions consistent environments from it across clouds. Because the blueprint is the source of truth, Facets can detect when a live environment has drifted from its declared state and bring it back, so drift elimination here means continuous reconciliation toward the declared graph rather than a one-shot apply that goes stale the moment someone edits a resource by hand.
Facets is the entry in this list built to be AI-operable, not just developer-operable. The blueprint is a structured contract, so Praxis, the AI Platform Engineer, can act on it rather than merely describe it. Praxis is delivered as a set of named agents that classify plain-English intent and then plan, decide, and delegate the actual change down to the declarative engine: it designs infrastructure from a request like "add a Redis cache," computes the dependency-ordered deployment, assesses blast radius and risk before it touches production, and runs SRE-style diagnosis when a deploy fails. Crucially, it operates inside the same governance model a human does. The agent carries no cloud credentials on the client; the server resolves the org and runs under org-managed integration credentials, inside the same role-based access control and maker/checker approval gates, and Praxis never deploys to production or approves a destructive action without explicit confirmation. That is the difference between an agent that can read your estate and one that can safely build it.
The honest limitation: Facets has a smaller market presence and less brand recognition than Backstage or Port, and it is heavier than a portal-only adoption like Cortex or OpsLevel. If your gap is purely a service catalog, Facets is more capability than you need.
Capabilities:
- Blueprint-driven self-service environments from a single declarative desired state
- Dependency resolution across the blueprint graph rather than per-resource hand-wiring
- Real infrastructure provisioning across AWS, GCP, and Azure, not catalog-only metadata
- Continuous drift detection and reconciliation back to the declared state
- Praxis AI Platform Engineer that designs, deploys, and diagnoses through a programmatic surface, with impact and blast-radius analysis before each change
- AI-assisted brownfield onboarding that imports existing Terraform state under blueprint management without recreating running workloads
- Governance guardrails the AI layer runs inside: role-based access control, maker/checker approvals, and full audit trails
- Extends existing CI/CD and observability rather than replacing them
On outcomes, Facets customers typically cut DevOps toil by 80%. Purplle reduced non-production infrastructure costs by 70%, and Vymo saved 12% on cloud costs. The common thread is that standardized, self-service provisioning lets developers move on their own while platform and security teams keep their guardrails intact. There is more detail on the self-service model on the developer self-service page and on blueprints under Facets product features.
With Facets we can now focus on high-value activities and not mundane Ops.
Suyash Katyayani, Co-Founder & CTO, Purplle
"
If you are weighing building this capability internally versus adopting a platform, our discussion of an in-house or third-party internal developer platform lays out the trade in detail.
Where this sits vs Facets: this is the anchor. Facets provisions and orchestrates real infrastructure with built-in governance, which is the layer the portals below depend on, and it exposes that layer as a contract an AI agent can operate rather than only catalog.
Humanitec
Humanitec pioneered the platform-orchestrator pattern and remains one of the most influential entries in the category. Its resource-graph and dynamic-configuration model lets platform teams encode how an abstract workload maps to concrete cloud resources, and the open Score specification gives developers a portable way to declare what their service needs. Orchestrator v2 (September 2025) broadened its cloud and on-prem support and strengthened enterprise governance.
The honest limitation: Humanitec expects meaningful platform-team setup and a degree of Kubernetes maturity. It is opinionated and powerful rather than turnkey, and it is not a developer portal on its own.
Capabilities:
- Resource-graph model that maps abstract workloads to concrete cloud resources
- Dynamic configuration management across environments
- Open Score specification for portable workload definitions
- Broad cloud and on-prem support after Orchestrator v2
- Enterprise-grade governance
Humanitec gives platform teams a rigorous, vendor-neutral way to standardize how infrastructure is composed, which reduces snowflake environments and centralizes guardrails. The trade is upfront investment: you get a strong orchestration backbone in exchange for designing and maintaining the resource definitions yourself.
Where this sits vs Facets: the closest peer. Both orchestrate real infrastructure. Choose Facets when you want blueprint-driven environments, natural-language operations through Praxis, and a lower platform-team assembly burden. Choose Humanitec when your team wants to build deeply on the resource-graph and Score model and has the platform engineering capacity to do so.
Qovery
Qovery is a developer-friendly abstraction over Kubernetes that prioritizes low setup friction. It is well-regarded for fast preview environments on every pull request, multi-cloud deployment, and a clean developer experience, and it has added AI-agent deployment guardrails to its roadmap.
The honest limitation: Qovery is more a deployment and PaaS layer than a full platform orchestrator or governance system. Its Kubernetes model is opinionated, which is a strength for teams that fit it and a constraint for bespoke enterprise infrastructure that Facets or Humanitec handle more flexibly.
Capabilities:
- Developer-friendly abstraction over Kubernetes
- Fast preview environments on pull requests
- Multi-cloud deployment
- AI-agent deployment guardrails
Qovery shines for teams that want to give developers a self-service deployment experience quickly without standing up a platform team first. The value is speed to a working paved road; the constraint is that the road is shaped by Qovery's Kubernetes opinions.
Where this sits vs Facets: Qovery is a deployment-centric PaaS layer. Choose Facets when you need full multi-environment infrastructure provisioning and governance from blueprints rather than an opinionated, Kubernetes-only deployment abstraction.
Appvia Wayfinder
Appvia Wayfinder leads with a strong security model. Ephemeral credentials, hardened templates, and workspace isolation make it a natural fit for teams where cloud-resource self-service has to clear a high compliance bar. It is Kubernetes-centric, underpinned by the open-source Terranetes project, and provides continuous compliance. It remains active and supported in 2026, contrary to occasional discontinuation rumors.
The honest limitation: Wayfinder is narrower than a full SDLC orchestrator. It centers on cloud-resource self-service and Kubernetes, and it offers less of the portal and catalog experience that Backstage or Port provide.
Capabilities:
- Ephemeral credentials and hardened templates
- Workspace isolation for multi-team safety
- Kubernetes-centric self-service
- Open-source Terranetes underpinning
- Continuous compliance
For security-conscious organizations, Wayfinder makes safe cloud self-service the default rather than something developers can sidestep. The strong isolation and credential model reduce the blast radius of mistakes.
Where this sits vs Facets: Wayfinder is a security-first cloud self-service layer focused on Kubernetes. Choose Facets when you want broader SDLC orchestration, blueprint-driven multi-environment consistency, and natural-language operations alongside governance.
Mia-Platform
Mia-Platform is built around microservices and API delivery. It pairs an integrated API gateway with templates and governance. It is enterprise-ready, with role-based access control, secrets management, and isolation, and is particularly strong in EMEA enterprise contexts.
The honest limitation: Mia-Platform is the heaviest fit for microservices and API-centric estates. It is broad and opinionated, which suits large enterprises building extensive API surfaces more than smaller teams with simpler needs.
Capabilities:
- Microservices and API delivery focus
- Integrated API gateway
- Templates and governance
- Enterprise controls: role-based access control, secrets management, isolation
For organizations standardizing on microservices and APIs at scale, Mia-Platform offers an integrated path from template to governed, gatewayed service.
Where this sits vs Facets: Mia-Platform is strongest for API-centric microservices delivery. Choose Facets when your need is general-purpose, multi-environment infrastructure orchestration across diverse workloads rather than an API-platform-led approach.
Developer portals and governance layers
These tools catalog, score, and govern services but do not provision infrastructure. They make an existing estate visible and accountable, so they coexist with an orchestrator like Facets rather than replace it. Many teams run a portal and an orchestrator together.
Backstage (Spotify)
Backstage is the de facto developer portal standard. Open-sourced by Spotify and now governed by the CNCF, it has a large plugin ecosystem and is the service catalog developers increasingly expect to find. Spotify Portal, a managed option, reached general availability in October 2025.
The honest limitation: Backstage is a framework, not a turnkey product. The build-and-maintain burden is real, there is no native infrastructure provisioning, and the true cost shows up as ongoing platform-team time.
Capabilities:
- Software catalog and developer portal framework
- Large plugin marketplace and ecosystem
- Vendor-neutral CNCF governance
- Managed Spotify Portal option
Backstage gives developers a single place to discover services, docs, and ownership, with deep extensibility through plugins. For organizations willing to invest in a platform team, it is the most flexible and widely adopted catalog available.
Where this sits vs Facets: Backstage catalogs and presents; it does not provision. It coexists with Facets, with Facets provisioning and orchestrating the infrastructure that Backstage makes discoverable. If you want the de facto plugin ecosystem, Backstage leads in that layer.
Port
Port is a fast-rising developer portal built around a visual, no-code builder. It offers mature scorecards and dependency mapping, is well funded, and has strong enterprise adoption. Its roadmap leans hard into AI agents.
The honest limitation: Port is a portal and governance layer, not a provisioning engine. Its per-seat SaaS cost scales with org size, and its agentic positioning is recent rather than long-proven.
Capabilities:
- Visual no-code portal builder
- Mature scorecards and dependency mapping
- AI-agent roadmap
- Strong enterprise adoption
Port lets teams stand up a tailored developer portal quickly without writing plugin code, which lowers the time-to-value compared with a build-your-own framework. The scorecards make service quality and maturity measurable across the org.
Where this sits vs Facets: Port governs and visualizes; it does not provision infrastructure. It coexists with Facets, which provides the underlying provisioning and orchestration that Port then catalogs and scores.
Cortex
Cortex is a developer portal focused on scorecards and service maturity tracking. It offers deep integrations with tools like PagerDuty, Datadog, and GitHub, AI catalog enrichment, and a strong reputation for governance at scale.
The honest limitation: Cortex does not provision infrastructure, and standing up full scorecard coverage across a large estate is a project rather than a quick install. Like its peers, it carries a per-seat SaaS cost.
Capabilities:
- Scorecards and service maturity tracking
- Deep integrations with PagerDuty, Datadog, and GitHub
- AI catalog enrichment
- Governance at scale
Cortex helps engineering leaders hold the org to consistent standards, with maturity scoring that turns "are we following our own best practices" into a measurable answer rather than an opinion.
Where this sits vs Facets: Cortex is a governance and scorecard layer over infrastructure provisioned elsewhere. It coexists with Facets rather than competing with it.
OpsLevel
OpsLevel is a developer portal that emphasizes fast time-to-value. It pairs AI-driven catalog auto-population with solid scorecards, self-service actions, and mature integrations.
The honest limitation: OpsLevel is a catalog and governance tool, not a provisioning or environment-orchestration engine. Its value depends on the breadth of integrations you connect, and it carries a per-seat SaaS price.
Capabilities:
- AI-driven catalog auto-population
- Scorecards and service maturity
- Self-service actions
- Mature integrations
OpsLevel gets a usable catalog and scorecards in place quickly, which makes it attractive for teams that want governance value without a long ramp.
Where this sits vs Facets: OpsLevel catalogs and governs; it does not provision. It coexists with Facets, which provisions and orchestrates the infrastructure OpsLevel then makes visible and accountable.
Conclusion
The right internal developer platform depends on which half of the self-service-versus-governance tension is actually slowing you down, and increasingly on which half you want an AI agent to operate. The two layers are complementary, not competing, and many mature engineering orgs run one of each. The durable layer, though, is the one an agent can act on rather than only describe, which is why provisioning and orchestration is where the category is consolidating.
Where Facets fits
Choose a developer portal like Backstage, Port, Cortex, or OpsLevel when your real gap is visibility: a service catalog, scorecards, and governance over infrastructure you already provision elsewhere. Each is genuinely strong in that layer, Backstage especially for the de facto plugin ecosystem, and you should run one alongside an orchestrator rather than expecting it to provision anything. But weigh the 2026 reality that a catalog sitting on top of someone else's provisioning is the thinner half, because what developers and AI agents both want is frictionless, operable access to provisioning itself. Choose Facets over Humanitec or Qovery when you want the orchestrator itself to provision real, multi-environment infrastructure from blueprints, with drift reconciliation and built-in governance, and you want Praxis to design, deploy, and diagnose through a structured contract an agent can safely drive under your role-based access control and approval gates, instead of assembling a platform yourself or living inside a Kubernetes-only PaaS. Concede the trade honestly: if you only need a lightweight catalog, Facets is more than you need, and Humanitec remains the closest peer for teams that want to build deeply on the resource-graph and Score model themselves.
Ready to see blueprint-driven, self-service environments in action? Book a demo with Facets.
File edited in place: /Users/pravanjan/git/facets-website-monorepo/apps/website/content/blog/7-best-internal-developer-platforms-idps-to-consider.mdx