Internal Developer Platforms — Building Yours Without Vendor Lock
IDPs went from custom-built to product category in 2026. The architecture for an IDP that delivers value without locking you into a single vendor.
Internal Developer Platforms (IDPs) went from “what big tech companies build” to a defined product category in 2026. Backstage, Port, Cortex, Roadie, OpsLevel, Humanitec — multiple credible vendors, plus the open-source Backstage core. The architecture that delivers value without locking you into a single vendor is well-understood; the execution is the work.
What an IDP that earns its place looks like.
What an IDP actually does#
The functional definition: a single, opinionated, self-service interface for application teams to do the day-to-day work of building, deploying, and operating software.
The capabilities:
- Service catalog. What services exist, who owns them, what they depend on
- Templates and scaffolding. Spinning up a new service from a vetted template
- Self-service provisioning. Environments, databases, queues, etc.
- Deployment workflows. CI/CD integration with safe defaults
- Observability links. Logs, metrics, traces from one place
- Documentation hub. Service docs, runbooks, ADRs
- Operations actions. Restart, scale, rollback from the portal
- Cost visibility. Per-service spend
- Compliance visibility. Security findings, dependency health, license issues
A platform that does most of these is a real IDP. One that’s just a service catalog is a step on the path.
The vendor landscape#
Backstage (open-source). The most flexible; biggest community; highest engineering investment to operate well.
Port. Commercial; opinionated; faster to deploy than Backstage but with vendor lock.
Cortex. Strong on service maturity scoring and engineering effectiveness.
Roadie. Hosted Backstage; trades flexibility for managed service.
OpsLevel. Service catalog and maturity focus.
Humanitec. Platform orchestrator focus; less developer portal, more deployment orchestration.
Pick by what your team will actually use, not by feature list.
Backstage as the lock-resistant choice#
For organizations concerned about long-term vendor lock, Backstage is the safer choice — open-source core, large community, plugin ecosystem.
The tradeoff: substantial engineering investment to operate Backstage well. Teams that deploy Backstage and don’t invest in maintaining it produce a Backstage instance nobody uses.
A reasonable rule of thumb: budget ~1 FTE of platform engineer time for Backstage operations once it’s serving the org.
The architecture pattern#
For IDPs we’ve built via our DevOps automation service:
- Service catalog as system of record — every service, every owner, every dependency
- GitHub/GitLab as source of metadata — service definitions live in code
- Cloud providers as backing infrastructure — IDP triggers actions; cloud executes
- Observability tools integrated but not replaced — IDP links to them
- Security and compliance tools integrated for findings surfaced in the portal
- Cost data integrated at per-service granularity
The IDP orchestrates; it doesn’t replace the underlying tools.
What goes wrong#
Replacing existing tools. Trying to put observability, security, deployment, and provisioning all under the IDP fails. The IDP surfaces and orchestrates; it doesn’t replace.
Bottom-up adoption only. A platform without leadership commitment doesn’t get adopted at scale.
Top-down mandate only. A platform engineers don’t want to use produces compliance theater.
Premature standardization. Standardizing on an IDP before you have the patterns to embed is putting the cart before the horse.
Vendor lock in disguise. Adopting a vendor IDP that promises portability but produces deep custom integration with the vendor’s data model.
What we ship for enterprise IDP#
For enterprise IDP engagements:
- Service catalog design and population
- Backstage deployment with curated plugin set
- Self-service templates for new services
- Integration with the firm’s CI/CD, observability, security stacks
- Service-maturity scorecards
- Adoption-measurement infrastructure
The maturity model#
An IDP grows through stages:
- Phase 1. Service catalog + ownership. Knows what exists.
- Phase 2. Self-service scaffolding. New services from templates.
- Phase 3. Self-service infrastructure. Environments and supporting resources from the portal.
- Phase 4. Observability and operations integration. Day-2 operations from the portal.
- Phase 5. Compliance and cost visibility. Continuous baseline enforcement.
Most orgs adopting in 2026 are at Phase 1 or 2. Phase 5 is achievable but takes years.
The 2026 trends#
AI-assisted platform actions. Natural-language interface to the IDP. “Create a new service with these characteristics.” Working in early deployments.
Self-service AI infrastructure. Provisioning RAG indexes, vector stores, fine-tuning jobs through the IDP.
Better cost visibility. Per-service, per-team, per-feature cost surfacing at portal level.
Multi-org IDPs. For very large enterprises with multiple business units, federation across multiple IDPs.
An IDP earns its place when it’s the place engineers actually go to do their work. Our team builds IDPs that get adopted, not just deployed. Tell us about the org.