Managed vs Self-Hosted Developer Platforms

An internal developer platform is infrastructure a platform team commits to running for years, not a tool a team tries out for a sprint. The decision that precedes any specific product choice is whether to run that infrastructure yourself or pay someone else to run it — and it is the same tradeoff that shows up in on-premise vs cloud infrastructure : control and customization ceiling on one side, headcount and time-to-value on the other. For developer portals this decision is unusually visible because one open-source project, Backstage, sits at one end of the spectrum and a set of managed products — some built on Backstage, some not — sit at every point between it and a fully hosted SaaS catalog.

This comparison follows the wiki’s constraint-driven comparison methodology : rather than starting from a feature grid and bolting a recommendation onto the end, it starts from the constraints — headcount you actually have, data-control requirements, sunk investment, exit cost — that rule specific options out for a given organization before any feature is worth comparing at all. Some of those constraints are hard gates; most are tradeoffs worth weighing against each other. The sections below say which is which.

The spectrum, not a binary

“Managed vs self-hosted” implies two options. In practice there are at least five, and they differ on more than who runs the servers:

1. Self-hosted Backstage. You deploy and operate the open-source Backstage framework yourself: the app, the catalog backend, a database, whichever plugins you choose or write, and every upgrade. You own the entire stack, including any data pipeline you build on top of the catalog for search, RAG, or agent context.
2. Managed Backstage hosting (e.g. Roadie ). Roadie operates a Backstage instance for you — automatic upgrades, a curated plugin set, hosting, and support — while you keep the Backstage data model and plugin API.
3. A supported, curated Backstage distribution (e.g. Red Hat Developer Hub ). Still Backstage under the hood, but packaged with an Operator- or Helm-chart-based install, a vetted plugin set, and commercial support. It can run on Red Hat OpenShift, another Kubernetes distribution (Red Hat documents supported Helm-chart installs on GKE, EKS, and AKS specifically), or on-premises — you or Red Hat can operate it, but Red Hat maintains the distribution.
4. SaaS-native, catalog-first platforms (e.g. Port , Cortex , OpsLevel ). No Backstage anywhere in the stack. These are commercial products with their own data models — Port calls its version a “blueprint” model — configured through a web UI rather than YAML and code, and run entirely by the vendor.
5. Managed, provisioning-first platforms (e.g. Humanitec ’s Platform Orchestrator). Not a catalog at all. Developers describe a workload with the open-source Score specification; the orchestrator resolves it against platform-team rules and provisions or connects the underlying resources, then hands off to a deployment tool such as Argo CD. It is SaaS by default, with self-hosting offered only on the enterprise tier and only on GKE, EKS, or AKS.¹ It is meant to sit behind a catalog or portal rather than replace one — Humanitec’s own documentation lists Backstage, Port, and Cortex among the frontends it’s designed to pair with, not compete against.⁸

Options 1–3 share the Backstage data model and plugin ecosystem; options 4 and 5 don’t use Backstage at all. That split matters more than “managed vs self-hosted” alone, because it determines whether switching later means a data migration or a hosting migration.

What each one actually is

Vanilla Backstage is a CNCF Incubating project (accepted into CNCF in September 2020, moved to Incubating in March 2022).² It is a framework, not a finished product: the project’s own documentation describes it as “an open source framework for building developer portals,” which ships a software catalog, software templates, and TechDocs, and expects an adopter to configure, extend, and operate the rest.³ There is no vendor to call when it breaks.

Roadie is a commercial company that operates Backstage instances on customers’ behalf, adding automatic upgrades, a set of 75+ plugins, single sign-on, and (on its Growth tier) a secure on-premises connection option, custom RBAC, and REST API access.⁴ Its pricing is seat-based: the Teams tier runs $24 per developer per month for organizations with 50–150 developers; Growth is custom-priced, starting at a 100-developer minimum. Only developers who actively contribute to source control are counted as billable seats.⁴

Red Hat Developer Hub is Red Hat’s supported distribution of Backstage. Red Hat frames the value proposition as curation and support rather than new functionality: “a tailored platform with a complementary suite of verified and curated tools,” backed by enterprise support for both the Hub and its plugin set, installed via an Operator or Helm chart and integrated with OpenShift’s GitOps and pipeline tooling — while remaining deployable on-premises, in a private or public cloud, or at the network edge.⁵ It does not eliminate the self-hosting decision; it changes who you can call when the plugin ecosystem or upgrade path breaks.

Port, Cortex, and OpsLevel are SaaS products built independently of Backstage. Port frames the difference as configuration versus code: its own comparison of Backstage alternatives describes Port as “an open commercial platform for building your own internal developer portal with no-code or low-code abilities” — you define entities, relationships, and scorecards through a UI, in what Port’s docs call a “blueprint,” rather than catalog-info.yaml and TypeScript plugins.⁶ Port’s pricing runs from a free tier (15 seats, 10,000 entities) through Basic ($30/seat/month, 50 seats) and Standard ($40/seat/month, 200 seats) to a custom Enterprise tier; Port describes itself as “a cloud-native SaaS platform,” offering dedicated-tenancy and Private Link options to enterprise customers on request — not self-hosting.⁷ Cortex and OpsLevel follow a similar SaaS-only model, each with its own catalog and scorecard implementation rather than a shared open-source core.

Humanitec’s Platform Orchestrator inverts the usual frontend: instead of a catalog of existing services, developers submit a Score workload spec, and the orchestrator matches it against platform-team-defined rules to provision or bind resources before handing off deployment to a tool like Argo CD.⁸ It is SaaS by default; self-hosting is an enterprise-tier option restricted to managed Kubernetes (GKE, EKS, AKS).¹ Because it solves provisioning rather than discovery, it is commonly paired with a catalog product rather than treated as a substitute for one — see declarative control planes for agents for how that split extends to agent-driven infrastructure.

What actually decides this, before features do

Five constraint categories do most of the work in this decision. Not every one binds for every reader — a team with no data-sovereignty requirement can skip that one entirely — but each is common enough among organizations evaluating a developer platform that it belongs in the comparison itself, not left implicit in a “choose the one that fits” conclusion at the end.

Internal capability and knowledge retention

A gate in one direction, a tradeoff across the rest. Self-hosted Backstage is the option with no customization ceiling — but that ceiling doesn’t matter if nobody can build against it. Roadie’s own cost analysis of self-hosted Backstage — a vendor source, so read it as directional rather than independently benchmarked — frames 3 FTEs in the first year and 2 FTEs in ongoing maintenance years as a minimum-viable baseline, and separately reports that organizations who end up satisfied with a self-hosted deployment typically dedicate a wider 3–12 FTEs to it, against a commonly reported 6–12 month time to a production rollout with real integrations.⁹ Even at the low end of that range, an organization with no platform engineering team, and no plan to build one, doesn’t have a weaker case for self-hosted Backstage — it has no case for it, regardless of how attractive the customization ceiling looks on a spec sheet. That’s a gate, not a score to weigh against the alternatives.

Below that headcount threshold, the remaining options trade capability differently, not identically:

• Roadie removes Backstage’s upgrade and infrastructure burden but keeps the Backstage data model and plugin API — the skill your team retains is Backstage-specific, and it stays useful even if you later move off Roadie’s hosting.
• Red Hat Developer Hub still requires operating a Kubernetes cluster (yours, or Red Hat’s under the support contract), so it reduces plugin- and upgrade-maintenance burden without eliminating cluster-operations knowledge as a requirement.⁵
• Port, Cortex, and OpsLevel require essentially no platform-ops headcount to run, but the capability your team builds — configuring a vendor’s UI and schema — doesn’t transfer to any other product, including back to Backstage, if the relationship ends.
• Humanitec on its default SaaS tier requires no infrastructure headcount at all; its enterprise self-hosted tier still requires the Kubernetes-operations skill needed to run GKE, EKS, or AKS.¹

Trust, data control, and regulatory or jurisdictional exposure

Usually a gate, not a tradeoff, for the organizations it binds. A catalog holds service ownership, deployment topology, on-call routing, and — increasingly — a retrieval index built on top of that metadata for coding agents (see the AI-era section below). If a regulatory rule, a customer contract, or an internal policy requires that this data never leave infrastructure the organization directly controls, only two of the five options satisfy it outright: self-hosted Backstage, and Red Hat Developer Hub deployed on-premises or in a private cloud the organization itself operates.⁵ Roadie, Port, Cortex, OpsLevel, and Humanitec’s default tier all place catalog or workload data on the vendor’s infrastructure by design — that’s the product, not an oversight.

Humanitec’s enterprise self-hosted tier is a partial exception worth naming precisely: it keeps workload-spec and provisioning data on infrastructure the organization controls, but only on a specific set of managed Kubernetes services — Google Kubernetes Engine, Amazon EKS, or Azure AKS.¹ If the constraint is “not on a third-party SaaS,” that satisfies it. If the constraint is “not on any public cloud,” it doesn’t — self-hosted Humanitec still runs on a hyperscaler’s managed control plane, not bare metal or a private data centre.

What this comparison cannot resolve: whether a specific regulation or a specific customer’s security questionnaire actually reaches service-catalog metadata — as opposed to customer or production data — is a legal and contractual question no general comparison can answer. Data sovereignty and the US CLOUD Act cover the general vocabulary this depends on (jurisdiction attaches to the provider entity, not to where a data centre physically sits); which vendor entity is subject to which jurisdiction, and whether your specific catalog data falls under a specific rule, needs a review against your own contract and your own regulator, not this page.

Vendor lock-in, exit cost, and data gravity

Mostly a tradeoff, with one concrete gate embedded in it. The gate: Humanitec’s self-hosted tier is only available on GKE, EKS, or AKS.¹ An organization whose infrastructure is on-premises, OpenShift, or a Kubernetes distribution outside that list doesn’t have a degraded self-hosted-Humanitec option — it has no self-hosted Humanitec option, full stop, and is limited to the SaaS tier regardless of any other preference.

The tradeoff underneath the rest of the field is the data-model split introduced above. Self-hosted Backstage, Roadie, and Red Hat Developer Hub all share the same catalog (catalog-info.yaml) and plugin API — moving between those three later is a hosting migration: the data and its shape stay the same, only who operates it changes. Moving from any of those three into Port, Cortex, OpsLevel, or Humanitec, or the reverse, is a genuine data-model migration: Port’s schema concept is its own “blueprint” model,⁶ Humanitec resolves against the open-source Score specification rather than a catalog at all,⁸ and Cortex and OpsLevel each have their own scorecard implementation. An organization with meaningful existing investment in catalog-info.yaml entities, ownership mappings, and TechDocs carries a real switching cost if it leaves the Backstage ecosystem, independent of which product scores better on any given feature. Software licensing and vendor lock-in and cloud exit costs and data gravity cover how to turn an exit-cost worry like this into an actual, checkable estimate.

Cost structure and sunk investment

A tradeoff, and the two sides differ in kind, not just amount. Self-hosted Backstage’s cost is engineering headcount and infrastructure, not a license fee — the headcount figures above are the real price, paid in salary rather than invoice.⁹ The managed and SaaS options convert that into a subscription: Roadie’s Teams tier runs $24 per developer per month for organizations with 50–150 developers, counting only developers who actively contribute to source control as billable seats;⁴ Port runs from a free tier (15 seats, 10,000 entities) through Basic at $30/seat/month and Standard at $40/seat/month;⁷ Red Hat Developer Hub is sold as a subscription with no published list price — one third-party reseller listing shows a 10-user, one-year premium subscription as a single observed data point, not an official rate card;¹¹ Humanitec’s Platform Orchestrator is custom/enterprise-priced with a free trial available.¹² Reported time-to-value follows a similar split, but it is not uniform within the SaaS tier: 6–12 months for a self-hosted rollout, against a vendor-reported figure of under a month for Roadie.⁹ SaaS catalog products vary sharply by vendor rather than forming one fast tier — OpsLevel reports its own onboarding at 30–45 days, while that same OpsLevel source (a head-to-head piece against a named competitor, so read it skeptically in both directions) puts Cortex’s setup timeline at six months or longer.¹⁰ Every one of these faster figures is reported by the vendor selling — or, in Cortex’s case, being compared unfavourably against — the faster option; read all of them as directional, not independently benchmarked.

Contractual and customer-driven requirements

A soft gate for procurement-driven organizations. Vanilla self-hosted Backstage has no vendor of record — there is no support contract to invoke when a plugin breaks or an upgrade fails, because it is a CNCF framework, not a commercial product.² ³ An organization whose procurement policy requires a supported vendor product with an SLA behind it — independent of the technical merits of any option — has effectively gated out plain self-hosted Backstage, and is choosing among Roadie, Red Hat Developer Hub, Port, Cortex, OpsLevel, or Humanitec on other grounds instead.

Which options survive your constraints

Put the gates above together, and the field narrows differently depending on which constraint actually applies to you:

• No platform engineering headcount, and none planned: self-hosted Backstage is gated out. Roadie, Red Hat Developer Hub, Port/Cortex/OpsLevel, and Humanitec (either tier) remain.
• A data-sovereignty rule or contract that bars catalog data — including anything indexed for retrieval — from leaving infrastructure you control: Roadie, Port, Cortex, OpsLevel, and Humanitec’s SaaS tier are gated out. Self-hosted Backstage and an on-premises or private-cloud deployment of Red Hat Developer Hub remain. If the rule specifically bars public cloud rather than third-party SaaS, self-hosted Humanitec is gated out too, since its self-hosted tier requires GKE, EKS, or AKS.
• Infrastructure that’s on-premises, OpenShift, or a Kubernetes distribution outside GKE/EKS/AKS, combined with a need for Humanitec’s provisioning model specifically: self-hosted Humanitec is gated out; only its SaaS tier is available to you.
• Procurement requires a vendor of record with a support contract: plain self-hosted Backstage is gated out; Roadie, Red Hat Developer Hub, Port, Cortex, OpsLevel, and Humanitec all remain, since each is a commercial product with support behind it.

These gates aren’t mutually exclusive — an organization can face two or three at once, in which case the surviving set is the intersection of what each gate leaves standing, not the union. Once the gates that actually apply have narrowed the field, what’s left is a genuine tradeoff among the remaining options: engineering headcount cost against subscription cost, unbounded customization against time-to-value, and — for anyone staying inside the Backstage ecosystem — how much of an existing catalog-info.yaml investment a given option preserves. The table below compares the full field on those dimensions; treat any column your own gates have already ruled out as informational rather than a live option.

The comparison

Why this decision is different for AI-era platforms

Two developments push more weight onto the trust-and-data-control constraint above than it carried a few years ago. First, platform catalogs are increasingly used as context for coding agents — an agent asking “which team owns this service” or “what’s the golden path for a new Python service” queries the same catalog a human would. If that catalog’s data — including anything indexed for retrieval — sits on a vendor’s infrastructure, the agent’s context pipeline depends on that vendor’s API and retention policy, not just your own systems. Second, agents acting through a platform (via MCP or a scoped service identity ) need the platform’s data model to be either fully under your control or contractually bounded by a vendor you trust with automated, not just human-reviewed, actions. Both turn what used to be a soft preference for self-hosting into something closer to a real gate for organizations building AI tooling directly on top of the catalog — while leaving the calculus for everyone else roughly where it was, since managed hosting still removes an entire category of infrastructure to secure.

What this comparison can’t tell you

This page can narrow the field with the gates above, but three things stay organization-specific in a way no general comparison can settle: whether a specific regulation or a specific customer’s security questionnaire actually reaches your service-catalog metadata, rather than just customer or production data; the actual negotiated price for Red Hat Developer Hub, Humanitec’s enterprise tier, or Port’s Enterprise plan, none of which publish a list price for that tier; and whether a specific plugin your team already depends on in Backstage has a real equivalent in Port, Cortex, or OpsLevel’s schema, which is a product-by-product evaluation this comparison doesn’t attempt. Each needs its own check against your contract, your regulator, and the vendor’s current docs — not an inference from this page.

Further reading

• Constraint-driven comparisons: why “better” is the wrong question : the methodology this page follows — how to separate gates from tradeoffs in any technology comparison.
• Platform engineering for AI teams : what to build in an internal developer platform when the consumers include AI agents, not just humans.
• Backstage vs Red Hat Developer Hub : a closer look at the vanilla-vs-curated-distribution choice within the Backstage ecosystem.
• Backstage vs Port vs Cortex vs OpsLevel : a feature-level comparison of the catalog products themselves, for readers whose own constraints have already put all four in play.
• Catalog as agent context : why the data-control constraint in this comparison matters more once agents query the catalog.
• Cloud exit costs and data gravity : making the vendor lock-in and data-gravity constraint concrete and calculable.
• Software licensing and vendor lock-in : the general mechanics behind the data-model lock-in discussed above.
• Data sovereignty and the US CLOUD Act : the vocabulary behind the trust-and-jurisdiction constraint — which entity can be compelled to disclose what, independent of where a data centre sits.
• The shared responsibility model for AI on AWS : a worked example, in a different domain, of the same operate-it-yourself-vs-vendor-operates boundary this comparison turns on.
• Governance thresholds as you scale : when a growing system — including one built on a developer platform holding real operational data — actually crosses into needing a formal contract or compliance process, rather than a felt need for more process.
• On-premise vs cloud for AI workloads : the same control-vs-speed tradeoff applied to infrastructure rather than developer tooling.

Sources

1. Humanitec, FAQs (self-hosting availability restricted to enterprise tier on GKE, EKS, or AKS; SaaS is the default): https://humanitec.com/faqs
2. Cloud Native Computing Foundation, “Backstage” project page (CNCF acceptance and Incubating-status dates): https://www.cncf.io/projects/backstage/
3. Backstage.io documentation, “What is Backstage?”: https://backstage.io/docs/overview/what-is-backstage/
4. Roadie, Pricing page (Teams and Growth tier pricing, seat minimums, feature lists): https://roadie.io/pricing/
5. Red Hat, “Red Hat Developer Hub” product page (curated plugin positioning, on-prem/private-or-public-cloud/edge deployment, support model), and Red Hat product documentation (Operator- or Helm-chart-based install on OpenShift): https://www.redhat.com/en/technologies/cloud-computing/developer-hub , https://docs.redhat.com/en/documentation/red_hat_developer_hub
6. Port, “Top 4 Backstage Alternatives” (describes Port as a no-code/low-code platform for building an internal developer portal, positioned against Backstage’s code-driven approach); Port’s own docs use “blueprint” for its schema concept: https://www.port.io/blog/top-backstage-alternatives , https://docs.port.io/
7. Port, Pricing page (Free/Basic/Standard/Enterprise tiers, seat and entity limits; SaaS-only positioning with dedicated-tenancy and Private Link options offered to enterprise customers, not self-hosting): https://www.port.io/pricing
8. Humanitec Developer Docs, “Platform Orchestrator: Overview” and “Score: Overview” (Score workload specification, its integration with the Platform Orchestrator, and Humanitec’s own positioning of itself relative to catalog frontends like Backstage, Port, and Cortex): https://developer.humanitec.com/platform-orchestrator/docs/introduction/overview/ , https://developer.humanitec.com/platform-orchestrator/docs/score/overview/
9. Roadie, “Backstage: How much does it really cost?” (self-hosted headcount figures — a “minimum viable” 3 FTEs year one / 2 FTEs ongoing, and a separate, wider figure of 3–12 FTEs for organizations satisfied with their self-hosted setup — plus a 6–12 month time-to-production estimate, versus Roadie’s own reported sub-month rollout; Roadie is a vendor of the managed alternative, so these figures should be read as a vendor estimate rather than an independent benchmark): https://roadie.io/blog/backstage-how-much-does-it-really-cost/
10. OpsLevel, “Cortex vs Backstage: What’s the best internal developer portal?” (OpsLevel reports its own onboarding at 30–45 days and Cortex’s at six months or more; this is OpsLevel’s own head-to-head comparison against a named competitor, not a neutral survey, so read both figures as directional at best — and as evidence that “SaaS catalog product” is not one uniform speed tier): https://www.opslevel.com/resources/cortex-vs-backstage-whats-the-best-internal-developer-portal
11. CDW, “Red Hat Developer Hub - premium subscription (1 year) - 10 users” product listing (third-party reseller price point; Red Hat does not publish public list pricing for Developer Hub, so treat this as one observed data point, not an official rate card): https://www.cdw.com/product/red-hat-developer-hub-premium-subscription-1-year-10-users/7891791
12. Humanitec, FAQs (45-day free trial, ROI calculator reference): https://humanitec.com/faqs