All posts

Internal developer portals promised simplicity – most teams got a second platform to maintain

Over the last few years, internal developer portals (IDPs) and platform engineering became one of the hottest trends in software delivery. Gartner reports that more than 60% of large organizations are already deploying or have deployed internal developer platforms and portals, aiming to improve developer experience and standardize delivery. Portal vendors tout catalogs, scorecards and "paved roads" as the cure for cognitive overload and tool sprawl.

Reality on the ground looks very different in many enterprises. Instead of simplifying, IDPs often add yet another layer of complexity: a new system to deploy, integrate, maintain, upgrade, secure and justify. Gartner explicitly notes growing disillusionment with the investment and complexity required to deploy and sustain self‑service portals, especially when organizations assume that open‑source frameworks like Backstage are "ready to use" out of the box.

The portal paradox: a UI on top of the same mess

On paper, portals should help developers navigate a complex environment, understand service dependencies and access self‑service capabilities. In practice, most of the pain points raised in research come from the same issue:

• Many portals ship as thin UIs on top of existing, fragmented tooling. They don't remove the complexity – they catalogue it.
• They require heavy upfront integration work into CI/CD, environments, security tools and observability. Teams often underestimate this effort and end up with a half‑wired catalog.
• Organizations treat frameworks like Backstage as turnkey products, discover the real cost of customization and maintenance, and then quietly shelve the project.

Gartner even calls out "build it and they will come" portal projects as a recipe for poor adoption when they don't deeply integrate with how software is actually built, deployed and operated. Developers see another dashboard; they don't see their day‑to‑day pain getting smaller.

OptimusHub takes a very different stance: instead of putting a portal in front of the mess, it replaces the mess at the delivery layer. The "portal experience" is an outcome of a working platform, not a veneer on top of disconnected tools.

The forgotten world: on‑prem and air‑gapped platforms

There's another blind spot in the portal and platform engineering hype: almost all commercial IDPs and developer portals are SaaS, optimized for cloud‑native organizations. The assumption is that your workloads run in Kubernetes in a major cloud and that it's fine for your control plane to live in someone else's region.

For a huge chunk of the market, that assumption is simply wrong:

• Regulated industries that must stay on‑prem or air‑gapped for compliance and data‑sovereignty reasons.
• Enterprises with large VM estates across their data centers, where Kubernetes is one island, not the whole story.
• Security‑sensitive environments where a SaaS control plane with deep access into environments is a non‑starter.

Research on platform engineering and portals talks about "internal developer platforms" abstracting complexity, but it largely assumes a cloud‑native substrate. The on‑prem and air‑gap world is, at best, an edge case.

OptimusHub is built from the opposite direction: as a self‑hosted platform that starts from your VMs and existing infrastructure, not from a cloud‑only view. You run OptimusHub in your own environment, you keep your data and control plane inside your perimeter, and you still get a modern, opinionated platform experience.

Why teams are disappointed with their portals

The disappointment many teams feel with their first portal initiative isn't because the idea of a better developer experience is wrong; it's because the path chosen is backwards.

1. Start with a portal, not a platform Organizations invest months in building a catalog and UI before they have a unified way of provisioning environments, deploying applications or enforcing policies. The portal becomes a directory of snowflakes, not a system of paved roads.
2. Ignore the real operating model Gartner notes that internal developer portals need dedicated platform teams and product ownership to succeed. Many enterprises underestimate that, spinning up portals without a clear operating model, leaving them to rot once the first wave of enthusiasm passes.
3. Over‑rotate to cloud SaaS Most portal products assume cloud connectivity and cloud‑first tooling. For hybrid or on‑prem organizations, that creates more integration tax and more risk instead of solving existing constraints.

OptimusHub flips the script: it starts as a working platform for provisioning, deployment and governance across your real infrastructure (VMs, on‑prem, cloud), and only then exposes that capability through a coherent, developer‑friendly experience. The "portal" is a reflection of actual capabilities, not an empty shell waiting to be wired.

OptimusHub: a platform first, not "yet another portal"

Here's what that difference looks like in practice:

• Platform, not just catalog OptimusHub does give you catalog‑like views of services and environments, but those entries are backed by real pipelines, environment definitions and deployment logic that the platform owns. When a developer clicks something in OptimusHub, things actually happen: environments get created, applications are deployed, security scans run.
• Self‑hosted and VM‑native OptimusHub runs in Docker and is designed to reach the virtual machines and infrastructure you already have. Kubernetes can be a target if you need it, but it's not a prerequisite or the center of the universe. That makes OptimusHub viable for air‑gapped and on‑prem estates where SaaS portals can't even enter the building.
• Built‑in CI/CD at platform level Instead of wiring "whatever pipelines you already have" into a nice UI, OptimusHub brings its own CI/CD engine, tightly integrated with environments, templates and a catalog. A pipeline in OptimusHub can start from a Git change and end with a provisioned, running app that shows up as a first‑class entity in the platform.
• Security and governance baked in, not bolted on Designed to support organizations preparing for SOC 2 Type II audit controls (specifically CC6, CC7, and C1); OptimusHub centralizes identity and permissions, stores secrets encrypted in its own database and runs recurring security checks as part of its delivery flow. For platform and security teams, that means fewer moving parts to secure and a much stronger story for audits and risk management.

Why this matters if you're tired of over‑promised platforms

If you are a CTO, VP R&D or Head of Platform who has already felt the sting of an IDP or portal project that didn't deliver, the message is simple:

• You're not wrong to want a better developer experience and paved roads.
• You are likely to be disappointed if you start from a portal and try to retrofit a platform behind it.
• The on‑prem and air‑gapped parts of your estate are not second‑class – and any serious platform must treat them as first‑class citizens.

OptimusHub is being built for that reality: as a self‑hosted, VM‑native platform designed to support SOC 2 Type II audit preparation that can actually orchestrate your infrastructure and applications, not just list them. Portals and catalogs are interfaces; what you really need is a platform that makes the underlying complexity go away instead of giving it a nicer homepage.