Engineering teams at every scale are often hamstrung by how hard it is to find information. Things like tracking down who owns a service, locating the runbook, figuring out whether something is production-ready or just nominally so, confirming which version of a library the org is running.
Internal Developer Portals (IDPs) exist because the challenge for developers has always been finding the right tools, context, and standards needed to do the work consistently. As engineering organizations grow, especially with agents in the mix, that problem compounds. Each new service, agent, tool, and team adds another thing to find, own, and keep current.
An IDP is one piece of a much larger operational puzzle, though. The companies getting the most out of their portals aren't treating them as standalone tools. They're embedding them into a broader discipline called Engineering Operations.
This article covers what IDPs do, what they solve, how AI has raised the stakes, and how a portal fits inside the larger discipline of Engineering Operations.
What is an Internal Developer Portal?
An Internal Developer Portal (IDP) is the engineering system of record for tracking, improving, and building high-quality software. Whether the components in question are services, agents, skills, APIs, Kubernetes clusters, or data pipelines, IDPs abstract away the complexities of ensuring software security, maturity, production readiness, and more. All using data from your existing tools.
At scale, that same system of record is where Engineering Operations begins.
Much has been written about Internal Developer Portals, but in this guide we’d like to provide a little more depth on foundations, critical capabilities, use cases, and even suggested onboarding plans.
What do Internal Developer Portals solve?
Internal Developer Portals solve the problem of software sprawl: more services, tools, and owners, changing faster than any team can track by hand. They pull the state of every service, owner, dependency, and standard into one system of record, so engineering organizations can hold quality and reliability steady without slowing delivery. Microservices, containerization, and the move to open source and cloud-native tooling are the main culprits behind the sprawl, and AI coding assistants, now in wide use, keep pouring more into it.
For development teams, this leaves a set of tensions that don't resolve on their own:
Cognitive load has to come down even as the toolchain fragments
Quality, security, and observability can't slip as the component count climbs
And delivery still has to speed up, because time-to-market windows keep shrinking
Internal Developer Portals emerged to address all three at once, and they became a standard part of the platform engineering toolkit. AI is now changing who, and what, the portal serves. In its 2026 Market Guide for Internal Developer Portals, Gartner describes the primary user shifting from developers to AI agents, and projects that by 2028 agent-driven interactions with portals will outnumber human ones by five to one.
How AI and agentic coding are raising the stakes for IDPs
Writing code was the easy part to automate. Everything downstream of it still has to be owned, reviewed, and kept reliable.
In our 2026 Benchmark Report, pull requests per author rose 20% over the past year, but incidents per pull request jumped 23.5% and change failure rates climbed about 30%. The bottleneck is the operational machinery around the code: ownership, readiness, consistency, and organizational alignment.
AI accelerates code output without addressing those underlying challenges, and in many cases compounds them. More code means more services, more components to track ownership for, more things to score for production readiness, more potential blast radius during an incident. A developer who can now produce what used to take a team of three still needs someone to own the services they ship, someone to review whether they meet standards, and an organization that can absorb the velocity without losing control.
Agentic coding makes this even more pointed. When AI agents can autonomously create pull requests, provision infrastructure, and chain together multi-step workflows, the guardrails that should have already been in place become structurally necessary. Without a strong IDP feeding accurate data into an EngOps practice, teams risk scaling output while degrading quality.
If your engineering operations aren't already in order, the volume of AI-generated code will outpace your ability to manage it. For many teams, it already has.
What is Engineering Operations?
Engineering Operations (EngOps) is the discipline of treating the engineering organization as a system to be operated and continuously improved. It unifies functions like Platform Engineering, SRE, DevEx, DevOps, and Security into a single operational mindset spanning the software development lifecycle.
Every other major function in a company already has an operational counterpart. Sales has Sales Ops. Marketing has Marketing Ops. Revenue, Finance, and Product all have dedicated teams focused on making the parent function better at its actual job.
Engineering is typically the largest cost center and the primary engine of innovation at most technology companies. And yet, it has historically lacked that same operational discipline. The responsibilities get distributed across half a dozen teams, each largely operating in its own silo, with no shared view of organizational health.
EngOps is built around three core mandates:
Clarity gives leaders and developers one accurate picture of what's happening across the org, so decisions get easier.
Improvement makes the team better at the work through measurement, standards, and structured improvement programs.
Friction removal automates toil and cuts the overhead that slows developers down, so the work itself gets easier.
What role do Internal Developer Portals play in Engineering Operations?
If EngOps is the discipline, the IDP is the foundation it runs on. IDPs put the materials, context, and self-service capabilities that agents and developers need in one place, so they can get to work quickly and ship with confidence.
An EngOps function needs to know who owns everything, whether services are production-ready, and whether a new engineer can get productive without two weeks of archaeology. An IDP is what makes those questions answerable at scale. The catalog is the data layer underneath it all. On top of it, scorecards measure each service against your standards, and self-service turns those standards into golden paths developers can run without waiting on a platform team.
That's necessary, but it isn't the whole system. Engineering operations platforms extend beyond cataloging and compliance into Engineering Intelligence (DORA metrics, delivery analytics, initiative tracking at the org level), structured improvement programs, and the tooling to act on what surfaces, not just report it.
What’s the difference between an Internal Developer Portal and an Internal Developer Platform?
We dive into this topic in a little more depth in another blog comparing portals to platforms, but in short, an internal development platform helps provide structure to a company's software delivery process.
Internal Developer Portals can complement, or sometimes partially eclipse the capabilities of Internal Developer Platforms, depending on an organization's use case. The system of record offered by Internal Developer Portals fuels more reliable and consistent CD pipelines offered by Internal Developer Platforms.
Engineering operations platforms like Cortex are built to bring these strengths together, combining a portal's catalog and standards with the broader operational tooling an engineering organization needs to run efficiently at scale.
Who uses Internal Developer Portals?
An IDP gets used in more than one place: inside the portal, through its data piped into tools like Slack and the IDE, and increasingly through an MCP (Model Context Protocol) server that exposes catalog and scorecard data to other tools and to agents. A range of roles rely on it:
Developers: Developers use IDPs to quickly understand software they own or have access to, reduce time to respond by understanding documentation, changes, and dependencies in one place, prioritize tasks to close gaps in software health or respond to changes needed, and use templates to bootstrap new software according to best practice.
Engineering leaders: Internal Developer Portals help engineering leaders build confidence in alignment to organization standards, improve the security and reliability of software, and even provide insight for project resource allocation and planning.
SREs: Reliability engineers use IDPs to set enforceable standards of quality and reliability, reduce overhead for devs in coming into compliance with initiatives, manage on-call rotations, and reduce time to respond by investigating context from within the platform.
Platform Engineers: Because platform engineers build tools and developer workflows to support efficient software development, they may focus more on the "last mile" of IDPs that focuses on self-service functionality like software scaffolding against core standards. (For a broader look at the ecosystem, see our list of recommended platform engineering tools.)
Developer Experience and DevOps/DevSecOps: As teams responsible for easing the cognitive load for developers while ensuring safe and scalable practices in software development, IDPs are valuable tools to abstract away complexity while enforcing standards.
Security: Security teams have a vested interest in ensuring software is set up to reduce risk and ensure rapid response when vulnerabilities occur. These teams can share minimum requirements for things like connection to vulnerability scanning and code coverage tools, or help set thresholds for maximum number of unresolved issues.
Agents: AI coding agents increasingly consume IDP data directly, pulling ownership, dependencies, standards, and golden paths as structured context so the changes they produce fit the systems around them and meet the same standards a human's would. Most reach that context through an MCP server rather than the portal UI.
On their own, each of these groups uses the IDP for its own ends, which leaves every team working from a different picture of the same systems. An Engineering Operations platform puts them on one: the same catalog, scorecards, initiatives, and intelligence, so standards and priorities hold across the org, agents included.
What are the core components of an Internal Developer Portal?
The primary users of developer portals are software developers, but that doesn't mean other groups like SREs, platform engineers, DevEx, DevOps, and Security don't play a critical role in optimizing that experience. With such a wide variety of stakeholders, it's easy to see how product strategy for IDPs has diverged from provider to provider.
However, in recent years we've seen a coalescing of functionality. It's now a relatively unchallenged truth that IDPs should consist, at minimum, of three core capabilities:
The ability to catalog software components
The ability to score software by standards of deployment readiness, health, and maturity
The ability for developers to self-serve software production according to such standards
These three capabilities (cataloging, scoring, and self-service) are also the foundational building blocks of engineering operations: you can't standardize what you can't see, improve what you can't measure, or scale a practice developers have to open a ticket to follow.
Software Catalogs
Software catalogs evolved from service catalogs. Those earlier solutions were created to help manage the sprawling and dynamic complexities of microservice ecosystems by providing engineering teams with a central system of record for service functionality, owners, dependencies, and documentation. These are the sorts of details not captured by existing ITSM or monitoring solutions, and often left to manual tracking via spreadsheet or shared wiki.
The deeper value of software catalogs, however, is in software optimization. Hydrating your catalog with information from across the stack is the first step forward in benchmarking quality, consistency, and use. It's impossible to have any confidence in software reliability, consistency, maturity, or security if you're not exactly sure where things live, who owns them, or what they're made of.
For teams practicing engineering operations, a well-maintained catalog is what makes operational visibility possible across a complex environment, and it is the prerequisite for every improvement that follows.
Learn more about Cortex's catalog →
Types of catalogs
Service catalogs still serve a purpose, but have waning relevance as a stand-alone solution. We now know architectural complexity comes in many forms, including microservices and multi-monoliths, and the components related to services are numerate and equally in need of greater attention to quality and consistency.
Software catalogs enable organizations to capture and manage details related to any type of software component, entity, or artifact, including services, ML models, Kafka topics, infrastructure, data pipelines, on-prem servers, APIs & endpoints, third-party vendors, K8s clusters and nodes, frontend React components, internally deployed tools and platforms (like Jenkins or HashiCorp tools), built artifacts like Docker images or versions of services running in different environments, and anything else you can dream up for your SDLC.
Catalog ownership and discovery
Understanding ownership is one of the most important use cases for software catalogs. But ownership isn't the easiest problem to solve. People join and leave organizations, switch projects, transfer teams, get promotions, and with these changes come changes in responsibility for software as well as access rights. Internal Developer Portals must integrate with identity and RBAC (role-based access control) platforms to ensure always-up-to-date ownership information.
In addition to providing ownership information, software catalogs must also enable users to answer nuanced questions like which workloads are currently running, what they do, what language they were written in, what version it uses, what changes have been committed over the last week, who's on call to support it, and what to do during an incident. By offering on-demand context on each software entity, IDPs help reduce risk, accelerate time to remediate, and reduce time to onboard.
Software scoring
The same data that gives software catalogs their detailed context on component state and dependencies can also enforce consistency in security, maturity, and efficiency.
Scoring software for alignment to best practice is now a table-stakes feature in any IDP. It's become particularly important as change velocity increases, whether teams are adding functionality, eliminating complexity, or reducing risk when vulnerabilities surface, versions need patching, or an end-of-life requires immediate upgrade.
Types of scorecards
Engineering operations platforms like Cortex come with an expansive set of integrations to top SDLC tools. Not only does this data provide depth and breadth to catalog contents, it can be used to create scorecard rules and levels that let users quickly assess how software stacks up against organizational standards.
Cortex's scorecards can use data from any out-of-the-box integration, or custom data from internal tools or unsupported third-party vendors. This is why we see such a wide variety of scorecard types across all of our customers, but here are just a few that tend to pop up regardless of company size, organization, or priority:
Acting on scorecards
Scorecards are meant to be an active and ongoing analysis of your software health, but acting on that information is a different story. Internal Developer Portals should have a mechanism for alerting and pushing progress against long-term initiatives, short-term projects, or parts of longer initiatives that require more immediate attention.
Cortex provides the Initiatives feature to ensure progress against scorecards. Initiatives ensure tasks are clear, owners are aware, and deadlines are met.
Developer self-service
While developers derive significant value from other parts of an IDP like catalogs, on-call management, alerting, and scorecards, self-service is still the most requested feature for developers to consider IDP adoption. Self-service, in this context, is defined by the ability of individual developers to bootstrap new software according to best practice, without facing lengthy approval queues or a stream of back-and-forth checks with the operations team. Two major components of self-service are project generation (scaffolding) and deployment actions.
Learn more about Cortex's self-service tools →
Project Generation/ Scaffolding
Internal developer portals should include the ability to quickly spin up new projects according to best practice and standards you define, and then ensure those services are appropriately cataloged. Scaffolding tools like Cortex's provide guardrails via templates and boilerplate code. This reduces opportunity for error, ensures consistency, and cuts rote work for developers.
Deployment Actions
After scaffolding new software it's important the IDP offer a way to also move that work into production. Cortex Workflows enable users to send payloads and chain together multiple actions out of the platform for execution elsewhere, including the ability to provision new resources. Where some Internal Developer Portals begin to hit their limits is in advanced orchestration that involves a chain of actions outside the platform. This competency is typically more aligned with Internal Developer Platforms, which have emerged in recent years to focus more on the later stages of the software development lifecycle. (We cover the intersection of CI/CD tooling and IDPs in more depth separately.)
What are the top use cases for an internal developer portal?
Internal Developer Portals are still a relatively new technology, and use cases continue to expand. Each of these is engineering operations in practice: a concrete outcome the discipline is built to produce.
Here are the top use cases we've seen:
Establish software ownership
Ownership can be difficult to maintain without IDPs to simultaneously track context like components, dependencies, and on-call rosters. IDPs ensure every software entity (service, infrastructure, API, etc.) has an owner and a rotating list of someone on-call to support it. Without a proper way to track ownership, incident management, onboarding, developer productivity, and resource allocation are all negatively affected.
Ensure production readiness
We often hear that growing organizations start to become fractured in how they build and launch new software. Standards aren't aligned, or are rarely even followed at all. IDPs help ensure all standards for production are met prior to launch.
Improve cost efficiency
As entropy creeps into software development practices across growing organizations, there can be wide fluctuations in the real cost of production, maintenance, and support for various software groupings and product lines. IDPs that provide custom data ingestion, flexibility in scorecard rubrics, and UI plugins enable users to monitor for cost of resolution time, excess resource allocation, and other signals that can help trim cloud costs.
Accelerate a migration
When it's time to off-board a solution, migrate a framework, or upgrade a software version, getting everyone on the engineering team to respond in a timely fashion is usually extremely challenging without a dedicated program manager to follow up individually with tasks, context, and deadlines. Internal Developer Portals that have initiative-based capabilities can ensure only appropriate resources are targeted for alerts, and deadlines are always met.
Ensure security and compliance:
Internal Developer Portals are most powerful as the central platform for all of your production standards, including those beyond tickets and PRs. Security tooling integrations can ensure appropriate security monitoring, code coverage, vulnerability response time, and more. Querying capabilities can quickly identify vulnerable versions of software in use across any software component, anywhere in your ecosystem, and target owners for immediate action.
Improve developer productivity
Many companies today are searching for ways to deliver a high-quality developer experience to their teams. This is because a better developer experience leads to increased engagement and velocity. IDPs are a single source of truth across all of your SDLC software to reduce context-switching for developers, and ensure they're aligned with managers on priorities, next steps, and timelines. IDPs also unify the software production lifecycle, including scaffolding new software, cataloging, updating, and improving it. Additionally, IDPs can incorporate tasks like API management, documenting services, running actions on them, deploying pieces of software, and rolling them back if needed, covering any and every step you consider critical in your development process.
Govern AI agents
An IDP applies the same governance to agents that it applies to human work: every agent and the services it touches carries an owner, and its output is scored against your production readiness, security, and testing standards before it ships. Feeding agents scoped context through an MCP server also raises the odds they generate compliant code in the first place, rather than something caught downstream. As agent-driven work grows, this is what keeps output from outrunning standards.
Reduce onboarding friction
Software development is a complex process, especially when it involves architecting a variety of software and assembling them to build an application. With the assortment of tools put to use to develop software today, the development lifecycle is more or less scattered across these tools. As a result, the developer experience is fragmented and discordant. Internal Developer Portals pull everything into a single place to give onboarding developers a single, unified, high-quality software development experience. They can continue to use the tools they prefer and follow certain best practices without having to worry about integrations or difficulties in communication with fellow team members or engineering leadership.
What’s the first step in onboarding an Internal Developer Portal?
Because of the variety of IDP use cases available, it can be confusing to decide where in the feature set of an IDP you should begin focusing your efforts. We recommend following the following steps to think through the IDP onboarding process, regardless of whether you opt for Cortex, choose an alternative solution, or even consider building your own.
Aggregate: The first step to accelerating developer productivity is enabling immediate access to reliable, up-to-date information about the software they use every day. This software cataloging step is the most critical, but shouldn't be the most time-consuming unless your IDP requires you to manually model or sync data from across your ecosystem.
Assess: Once you've collected and categorized your software, it's time to think critically about its health. In order to set standards, you'll need to first decide what your minimum requirements are and what excellent looks like. This step is especially useful ahead of moving into scaffolding, which will require you to templatize those standards.
Prescribe: Assessing the current state of your services is an important step towards service maturity. But as your team scales, use cases expand, and projects are added, you'll need a way to create alignment while removing any confusion about what to do next. Initiatives allow you to carve off portions of scorecards to make progress toward goals with steps and timelines.
Enable: One of the final steps in a progression towards engineering efficiency is a repeatable and reliable method for creating new software according to best practice. When tackled after setting standards of excellence, this phase results in DRYer code, speedier deployments, greater reliability, and a decreased rate of incidents.
Optimize: The platform itself should keep evolving, the same way the teams using it do, adapting to meet developers' changing needs. IDPs that provide UI customization and plugins for data embeds will improve adoption as you scale.
What’s next for IDPs
The IDP category is being absorbed into something bigger. The standalone portal, a catalog with scorecards and a self-service layer, gave engineering teams a single place to find things when everything was scattered across wikis, spreadsheets, and Slack threads.
However, a better catalog is now no longer the goal. Engineering organizations want a platform that connects visibility to action, one that can measure organizational health, coordinate structured improvement programs, surface engineering intelligence, and give leaders real-time insight into how the whole engineering function is running. That's an Engineering Operations platform.
IDPs will continue to matter as a capability layer. The catalog, the scorecards, the self-service workflows are all necessary, foundational work. But the era of the IDP as a standalone category is winding down. The platforms taking its place treat the portal as one component of a larger operational system.
How Cortex extends the IDP into an Engineering Operations platform
Cortex started as an IDP and evolved into an Engineering Operations platform because our customers kept running into the same ceiling. The portal could show them what was happening, but couldn't help them systematically improve it.
The IDP capabilities are still a major part of our platform offering. The catalog maintains a live inventory of every service, agent, component, and dependency in your organization. Scorecards let you define production readiness, security, reliability, and operational maturity standards and measure every entity against them automatically. Self-service workflows and scaffolding templates let developers and agents spin up new services that are compliant from the start.
Cortex goes further by turning that foundation into continuous organizational improvement. Initiatives attach owners, deadlines, and progress tracking to any standards program, so migrations, security remediations, and reliability pushes don't stall at 50% adoption. Engineering Intelligence surfaces DORA metrics, production readiness signals, and trend data across your entire org. The Context Graph automatically maps how services, teams, and dependencies connect, which matters most during incidents when you need to understand the blast radius immediately. And the Cortex MCP server connects your engineering catalog to AI coding agents, so developers get accurate context about ownership and health without leaving their IDE.
A portal shows you where every service stands. Cortex is the Engineering Operations platform that turns that picture into a healthier, faster, more secure engineering organization over time.
Frequently Asked Questions
What’s the difference between an Internal Developer Portal and an External Developer Portal?
The two share a name but serve different audiences. An External Developer Portal is the public front door to a company's APIs, where outside developers find the documentation, keys, and support they need to build against them. An Internal Developer Portal points inward, giving your own engineers a system of record for the services, standards, and ownership behind everything you run. Internal portals can manage internal APIs much as external ones manage public access, but their real job is operational visibility across your own systems.
Should we build or buy our IDP?
Deciding whether to build or buy comes down to more than just initial investment. It's about understanding the long-term implications for your engineering team's productivity, scalability, and adoption. A typical internal build holds up for its first 6 to 18 months, then buckles under edge cases, maintenance, and turnover, right as the capabilities that matter most (cross-team ownership enforcement, org-level metrics) get hardest to build. Build only if a developer portal is itself a strategic product for your business and you can fund a standing team to own it. Otherwise, a commercial platform delivers those capabilities on day one.
What is a minimum viable portal (MVP)?
A minimum viable portal is the smallest version that delivers value on day one: a complete, accurate catalog of your services with clear ownership. That inventory is the piece everything else depends on, so even a portal that only answers "what do we run and who owns it" earns its keep during the next incident or audit. The common mistake is launching scorecards, golden paths, and self-service all at once before the catalog is populated, which stalls adoption because the data underneath is too thin to trust. Start narrow, prove the value, then layer on standards and automation as teams come to rely on it.
How do we handle shadow IT and unmanaged services?
You handle it by making discovery automatic and continuous, because manual cataloging never keeps up with how fast services get created. Nearly 90% of engineering teams now use AI coding tools (per our 2026 Benchmark Report), and that output means more services, more dependencies, and more things spun up without an owner or a standard attached. The way to catch them is to auto-discover services straight from the code repositories, Kubernetes clusters, and cloud accounts you already run, flag anything new that lacks an owner, and infer the most likely team to assign it to. The stakes show up the moment a critical CVE lands: if a vulnerable service is missing from your catalog, no one can tell you it is affected, and it sits exposed while everyone else patches. With continuous discovery in place, that question takes one query to answer.
What are the common pitfalls of IDP adoption?
The biggest pitfall is treating the portal as a tool to install rather than a product to run. Without a dedicated owner who talks to developers and builds a roadmap around their real problems, the portal drifts from what teams need and adoption stalls. A second pitfall is skipping the business case: Forrester recommends deciding up front what benefits the portal should deliver and how you will measure them, because a portal no one can prove value for is the first line item cut. Third, teams that build on Backstage routinely underestimate the ongoing maintenance, which is how a portal ends up expensive to run and short on adoption. Avoid all three by naming an owner, defining how you will measure adoption from day one, and starting with the one workflow that solves your teams' most painful problem.
