Backstage vs Red Hat Developer Hub: when each one fits
A platform team choosing between building its own Backstage app and adopting Red Hat Developer Hub should start with one question: who will own the upgrades, plugins and support for the portal over the next several years? Backstage fits teams with TypeScript and React capacity who want to own the app and its plugins. Developer Hub fits teams that want a supported, preinstalled distribution installed with the Operator or Helm chart on OpenShift Container Platform, Azure Kubernetes Service or Amazon Elastic Kubernetes Service. Both are Apache-2.0 licensed, and Developer Hub is based on Backstage, so the difference is less about the core framework than about who maintains the distribution around it.
The decision turns on five points. The first is upgrade ownership: a self-built app means your engineers track the Backstage release lines, which ship monthly on the main line with weekly next releases, and apply changes to your code. The second is plugin needs: Developer Hub ships plugins such as Argo CD, Quay, Tekton, Keycloak and GitHub integrations, while a custom app means you select, build and patch each plugin yourself. The third is identity setup, since Backstage offers 19 built-in authentication providers and its guidance is to configure sign-in resolvers so every provider maps to one identity and to avoid guest access in production. The fourth is support: confirm with Red Hat exactly what its subscription covers for your Developer Hub version, and confirm with your own team who answers when a community plugin breaks. The fifth is your existing Kubernetes platform, because Developer Hub's documented targets are OpenShift, AKS and EKS.
Before you commit, run a short spike. Install Backstage from the upstream project on your target cluster, connect your identity provider and two or three plugins you actually need, then estimate the engineer time for one minor upgrade. Compare that with a Developer Hub trial on the same cluster. Ask Red Hat for the support terms, the supported plugin list and the upgrade path for your version, and check the Developer Hub documentation on high availability for the database and cache layers. The answers will show whether you are buying a supported distribution or paying your own engineers to run one.
Which platform fits which team situation
This table matches common team situations to the better starting point, Backstage as an app you build and maintain or Red Hat Developer Hub as a supported distribution with preinstalled plugins. Read each row as a condition: the recommendation holds only while the stated condition is true, and a change in that condition changes the answer.
| Team situation | Better fit | Reason and condition |
|---|---|---|
| Existing OpenShift estate | Red Hat Developer Hub | RHDH installs on OpenShift Container Platform through the Operator or Helm chart, and its plugins include Argo CD, Tekton and Topology. This favors RHDH only if your platform team already runs OpenShift and wants those integrations out of the box. |
| No Red Hat subscription | Backstage | Backstage is Apache-2.0 with no paid edition from the project itself. Confirm with Red Hat whether RHDH's supported distribution, images and plugins require a subscription in your case before assuming a cost difference. |
| Heavy custom plugin work | Backstage | Teams that write their own TypeScript and React plugins build directly on the upstream framework, which the Backstage documentation describes as the basis for adopters' own app. RHDH can be extended, but confirm how your custom plugins are packaged and supported in its install model. |
| Need for vendor support | Red Hat Developer Hub | RHDH is a supported enterprise product from Red Hat, while upstream Backstage is maintained by the community and CNCF. Choose RHDH if a contractual support path is a requirement; confirm the support terms and scope with Red Hat. |
| Small platform team | Red Hat Developer Hub | A preinstalled plugin set and documented Operator or Helm installs reduce the initial build work. Note that Backstage's monthly main release line and Node.js support policy still apply to you if you run upstream, so the saving is largest on initial setup. |
| Regulated environment needing documented HA for database and cache | Red Hat Developer Hub | Red Hat documents high availability for the database and cache layers. Backstage uses PostgreSQL in production and supports several cache options, but you would need to design and document that HA yourself. Ask your assessor what evidence they expect and whether it can come from your own architecture. |
| Team that tracks upstream closely and upgrades frequently | Backstage | Backstage ships a monthly main release line and a weekly next line, and backports high and critical vulnerabilities to releases from the last 6 months where feasible. Choose upstream if your team can absorb that cadence; RHDH's upgrade timing follows Red Hat's own release schedule, so confirm it against your change process. |
How each is built, deployed and kept current
Backstage is a framework you turn into your own app, while Red Hat Developer Hub is a packaged distribution of Backstage with its own install paths and support terms. The cards below cover what each model asks of your team on day one and every month after, from the core features and database layout to the installers and the release cadence that sets your upgrade workload.
Backstage as an app you build
Backstage is a framework, so adopters build and maintain their own TypeScript and React application. Your team chooses the plugins, writes the code that wires them together, and owns every change to the app. Developer Hub starts from the same upstream base but ships as a finished distribution. Check whether your engineers have the front-end and Node.js skills to keep a custom app working over several years.
Core features and built-in plugins
The Software Catalog, Software Templates and TechDocs are core built-in features, and the Kubernetes and search plugins sit alongside them. In a self-built app, you decide which of these to enable, configure and extend. In Developer Hub, plugins such as Argo CD, Tekton, Keycloak and the GitHub plugins come preinstalled, which shifts the question to whether the bundled set covers your toolchain. Confirm each plugin version against your own toolchain before committing.
PostgreSQL and per-plugin databases
Backstage uses PostgreSQL in production and SQLite for development. Each backend plugin gets its own logical database through Knex, so schema changes are scoped to individual plugins. Caching can use Redis, Memcache, Infinispan or in-memory options. Ask your DBA how backups, restores and plugin database growth will be handled, and confirm which cache option fits your availability needs, since these choices land on your team in a self-built deployment.
Operator and Helm installs
Red Hat documents installing Developer Hub on OpenShift Container Platform, Azure Kubernetes Service and Amazon Elastic Kubernetes Service using either the Operator or the Helm chart. The Operator suits teams already running OpenShift lifecycle tooling, while the Helm chart suits teams that manage releases through their own GitOps pipelines. Confirm which target platform and install method your platform team supports, and whether your cluster versions fall within Red Hat's support matrix.
High availability for data layers
The Developer Hub documentation covers high availability for the database and cache layers, which is a documented path your platform team can follow rather than designing from scratch. A self-built Backstage app needs the same design work, including replica counts, failover for PostgreSQL and cache behavior under node loss. Ask Red Hat to show the exact HA topology it documents for your target platform and compare it with your own recovery objectives.
Release cadence drives upgrade work
Backstage ships a main release line monthly and a next release line weekly, and high and critical vulnerabilities are backported to releases from the last six months where feasible. An own-build app must absorb these releases, test plugin compatibility and move Node.js versions, since Backstage supports two adjacent even-numbered Node.js releases. Developer Hub moves on Red Hat's own schedule, so ask how long each Developer Hub version receives fixes before you plan your upgrade calendar.
How identity sign-in and plugins differ in practice
Backstage ships 19 built-in authentication providers, including GitHub, GitLab, Google, Azure, Okta, Auth0, OneLogin, Bitbucket, Cloudflare Access, AWS ALB, Google IAP and generic OIDC. In a self-built app, your team wires these providers into the configuration, writes the sign-in resolvers and owns every change when an identity provider updates its behavior. The upstream guidance is to configure resolvers so every provider maps to the same identity, and to avoid guest access in production.
- Provider coverage: Backstage's built-in list includes generic OIDC, which covers many identity providers that are not named individually.
- Resolver design: A resolver that maps each provider to one canonical user keeps catalog ownership and permissions consistent across sign-in paths.
- Guest access: Guest sign-in is useful in development but should be disabled in production, which your build must enforce.
- Keycloak and Red Hat support: Confirm with Red Hat which identity providers and the Keycloak integration are supported in Developer Hub for your version, and whether any are limited to specific deployment methods.
- Ownership: In a self-built portal, your team tests sign-in after each upgrade of the auth plugins.
Before committing, confirm the supported provider list and Keycloak integration path with Red Hat for the Developer Hub version you plan to run.
Red Hat Developer Hub includes a preinstalled set of plugins that Red Hat hand-picks or builds with the Backstage community. The documented list includes Argo CD, OCM, Quay, Kubernetes, Topology, Tekton, Keycloak, GitHub Actions, GitHub Issues and GitHub Pull Requests. This set is most useful when your delivery stack matches it, because the integrations are present at install time rather than assembled by your team.
- Delivery tooling: Argo CD, Tekton and Quay cover GitOps, pipelines and image registry views if your platform uses them.
- Cluster visibility: The Kubernetes and Topology plugins give application owners workload views without custom work.
- Source control: The GitHub Actions, Issues and Pull Requests plugins cover GitHub-centered teams.
- Gaps: If your stack uses other CI systems, registries or observability tools, you will still need plugins that are not in the preinstalled set.
- Selection: In a Backstage build, you choose, install, pin and maintain each plugin yourself, which gives full control but adds recurring review work.
Map your current toolchain against the preinstalled list before deciding how much plugin work the self-built path would add.
Red Hat says its Red Hat Plug-ins for Backstage complement Developer Hub and the wider Backstage ecosystem, extending the upstream project rather than replacing it. Red Hat also describes certified pipelines and GitOps plugins designed to integrate with Red Hat OpenShift. For teams that run OpenShift, these plugins are the main reason to evaluate the supported distribution's plugin set in detail.
- Upstream compatibility: Plugins built for Backstage are the same kind of extension, so skills and code carry across both paths.
- OpenShift integration: Red Hat's certified pipelines and GitOps plugins are designed for OpenShift environments.
- Community plugins: The Backstage plugin ecosystem remains open to you in either path, but community plugins are your responsibility to vet in a Red Hat distribution.
- Support boundary: Confirm which plugins Red Hat supports and which are community or customer-maintained, since the support terms differ.
- Custom plugins: Your own plugins are yours to build, test and support in either model.
Ask Red Hat for the current list of supported plugins and the support boundary for any plugin your teams depend on.
Capability comparison on upgrades, plugins, support and licensing
This table compares a self-built Backstage app with Red Hat Developer Hub on licensing, install paths, plugins, upgrade ownership, release cadence, Node.js support, security backports, identity, data stores and vendor support. Read each row as a question to put to your team and to Red Hat, since the rows where a supplied fact is missing say so directly. The main takeaway is that both share the same Apache-2.0 upstream code, so the decision turns on who carries upgrade work and support obligations.
| Capability | Backstage (self-built app) | Red Hat Developer Hub |
|---|---|---|
| License | Apache-2.0 framework with no paid edition from the project itself | Based on Backstage; the redhat-developer/rhdh repository is Apache-2.0, and subscription terms need confirmation with Red Hat |
| Distribution model | You build and maintain your own TypeScript and React app from the framework | Packaged distribution of Backstage maintained by Red Hat, with plugins preinstalled |
| Install methods | Your own build and deployment pipeline, on infrastructure you choose | Operator or Helm chart on OpenShift Container Platform, Azure Kubernetes Service and Amazon Elastic Kubernetes Service |
| Preinstalled plugins | Core catalog, templates and TechDocs; other plugins are added and maintained by your team | Includes Argo CD, OCM, Quay, Kubernetes, Topology, Tekton, Keycloak and GitHub plugins, hand-picked or built by Red Hat and the community |
| Upgrade ownership | Your engineers apply upstream releases, resolve plugin conflicts and test the app | Red Hat publishes versioned releases; confirm with Red Hat which upgrade paths and support windows apply to your version |
| Release cadence | Main line monthly and next line weekly; v1.55.3 released September 29, 2026 | Red Hat Developer Hub 1.10 is the latest documented version; confirm the release schedule with Red Hat |
| Node.js support | Supports exactly two adjacent even-numbered Node.js releases, currently 22 and 24 as of Backstage 1.46.0 | Confirm the supported Node.js versions for your RHDH version with Red Hat |
| Security backport policy | High and critical vulnerabilities backported to releases from the last 6 months where feasible | Confirm the backport commitments and support window with Red Hat |
| Identity providers | 19 built-in authentication providers, including GitHub, Okta, Azure and generic OIDC; sign-in resolvers must map each provider to one identity | Keycloak plugin included; confirm the full provider list and supported configurations for your version |
| Database and cache options | PostgreSQL in production, SQLite for development; Redis, Memcache, Infinispan or in-memory caching | Documents high availability for database and cache layers; confirm the supported database and cache versions |
| Vendor support | Community support through the project; no vendor support contract from the project itself | Red Hat support tied to the subscription; confirm the scope, severity levels and terms with Red Hat |
What is free and what is paid on each side
Backstage is an Apache-2.0 framework from the Backstage project, and the project itself offers no paid edition. Nothing is charged for the software, so the money you spend goes to people and infrastructure. You build your own TypeScript and React app, choose your plugins, and run the result in your own environment. The costs that recur are the engineers who keep that app current and the hosting for it.
- No license fee: The framework carries no license charge from the project, so the spend is staff time, hosting and any third-party services you connect.
- Build effort is yours: You assemble the app, select plugins, and configure the catalog, templates and TechDocs yourself.
- Upgrades are yours to schedule: The main release line ships monthly and the next line ships weekly, so someone must test and adopt them.
- Security backports depend on your version: The versioning policy says high and critical vulnerabilities are backported to releases from the last 6 months where feasible, so staying on a recent release matters.
- Node.js support is a constraint: Backstage supports two adjacent even-numbered Node.js releases, so runtime upgrades become part of your plan.
Confirm internally how many engineers will own upgrades, plugin maintenance and incident response, because that staffing is the main cost of this option.
Red Hat Developer Hub is based on Backstage, and its redhat-developer/rhdh repository is also Apache-2.0. The open license therefore applies to the code, but Red Hat sells the distribution, its supported images and its support. The repository publishes a community image at quay.io/rhdh-community/rhdh next to Red Hat's RHEL 9 and RHEL 10 based rhdh-hub images on Quay.io. Using the community image costs nothing in license terms, while the supported images belong to Red Hat's subscription model.
- Open code, sold distribution: The source is Apache-2.0, but the supported build, lifecycle and support come from Red Hat's commercial offering.
- Community and supported images: The community image at quay.io/rhdh-community/rhdh differs from the supported rhdh-hub images, so confirm which one your support covers.
- Preinstalled plugins: RHDH includes plugins such as Argo CD, Kubernetes, Tekton and Keycloak, which reduces build work but still needs your configuration.
- Certified pipelines and GitOps plugins: Red Hat describes these as designed for OpenShift, so their value depends on whether you run OpenShift.
- Supported install paths: Red Hat documents Operator or Helm installs on OpenShift Container Platform, Azure Kubernetes Service and Amazon Elastic Kubernetes Service.
Confirm with Red Hat which subscription tiers exist, what support covers, which images and plugins are included, and the support window for each version, because these terms are set in the agreement and not in the repository.
The subscription terms decide what you pay for beyond the open code. Red Hat's public material describes the product and its install options, but the tiers, pricing and support scope are set in the commercial agreement. Ask for these items in writing before you compare totals with a self-built Backstage app.
- Subscription tiers: Ask which tiers exist, what each includes, and whether pricing depends on cluster, node or user counts.
- Support scope: Ask what support covers, including plugins, the database and cache layers, and upgrades between versions.
- Supported versions: Ask how long Developer Hub 1.10 and other versions receive support, since version history runs back to 1.0.
- Image and plugin coverage: Ask which images, Red Hat Plug-ins for Backstage and third-party plugins fall under support.
- Exit terms: Ask what happens to your configuration and support if you leave the subscription and move to a self-built Backstage app.
Record the answers in your evaluation, because they are the basis for any comparison of recurring cost.
What drives running cost for an own-build Backstage app
This table lists each recurring and one-time cost of running a self-built Backstage app next to the equivalent cost under Red Hat Developer Hub, with the drivers that move each line. Read it as a quote checklist: for each row, ask who is paid, whether the cost recurs, and what the vendor or your own team would carry. The main takeaway is that the Backstage license is free, so most of the cost sits in the engineers and infrastructure you own, while the Red Hat subscription replaces some of that effort with a supported, preinstalled distribution.
| Cost component | One-time or recurring | What drives it up or down, and what to ask for in a quote |
|---|---|---|
| Engineers who build and upgrade the app | Build is one-time; upgrades recur | Cost rises with custom plugins, the number of upgrade cycles you adopt and the depth of TypeScript and React work. Under Backstage, your team pays for every upgrade, given the monthly main line and weekly next line in the versioning policy. Under Red Hat Developer Hub, ask which upgrade and migration work the subscription covers and what you still build. |
| Plugin maintenance | Recurring | Cost rises with the count of community or custom plugins you pin and must patch when Backstage moves. Red Hat Developer Hub ships plugins such as Argo CD, Kubernetes, Tekton and Keycloak, so ask which of your required plugins are included, which are community-maintained and which you would still own. |
| Hosting on Kubernetes | Recurring | Cost depends on the cluster you run on, such as OpenShift Container Platform, AKS or EKS, and on the replicas you need. Ask Red Hat which installation paths and cluster versions the subscription covers, and ask your own platform team what capacity the Backstage app needs. |
| PostgreSQL and cache operations | Recurring | Backstage uses PostgreSQL in production and supports Redis, Memcache, Infinispan or in-memory caching. Your team pays for backups, failover and version upgrades unless you buy a managed service. Ask Red Hat how high availability for the database and cache layers is documented and supported in its installation. |
| CI pipelines | Recurring | Cost grows with build frequency, test coverage and the number of plugin packages you compile and publish. Owning the app means owning the pipeline that tests each upgrade. Ask what build and test assets Red Hat supplies and what your pipeline must still validate. |
| Security patching against the backport policy | Recurring | Backstage backports high and critical vulnerabilities to releases from the last 6 months where feasible, and other security fixes only at maintainers' discretion. An own-build app must stay on a supported line to receive those fixes, so the patch cadence is your cost. Ask Red Hat what security response window and backport coverage its subscription states in writing. |
| Red Hat subscription cost for Developer Hub | Recurring | Subscription cost depends on the support tier, deployment footprint and terms in your quote, and no price is set out here. Ask for the subscription price, what it includes (support, certified plugins, documented installs), the term length and renewal conditions, and whether it reduces your own upgrade and plugin work. |
Moving from a self-built Backstage app to Developer Hub, or back
This sequence shows which catalog data, templates and TechDocs sources carry over unchanged, which custom code must be rebuilt, and how to cut over sign-in without stranding users or data. Each step closes with a check you can run before moving on.
Inventory custom plugins and catalog entities
Your platform team lists every custom backend and frontend plugin in the self-built app, every catalog entity kind in use, and every software template and TechDocs source repository. Record which plugins call internal APIs, which read secrets, and which depend on a specific Backstage version. The inventory is done when each item is tagged as transfers, rebuilt or retired, and the owner of each tag has signed off in writing.
Check plugin parity with the RHDH set
Compare the inventory against the plugins Red Hat Developer Hub ships, such as Argo CD, Kubernetes, Tekton, Quay, Keycloak and the GitHub plugins, and against the Red Hat Plug-ins for Backstage. Confirm with Red Hat's current documentation which versions of each plugin are supported on the RHDH release you plan to run. Any custom plugin without a supported equivalent becomes a rebuild item that must be packaged for the distribution. The check is complete when every gap has a named owner and a decision to rebuild, replace or drop.
Map identity resolvers and sign-in providers
Document how your current app authenticates users and how each sign-in provider maps to a catalog identity. Backstage's authentication guidance advises resolvers that map every provider to the same identity and no guest access in production, so confirm your existing resolver logic meets that standard before porting it. Identity resolver code is rebuilt or reconfigured in the target deployment, not copied blindly, because the identity source and claims may differ. The step closes when a test user signs in through each provider and resolves to the same catalog user.
Back up PostgreSQL databases per plugin
Backstage gives each backend plugin its own logical database through Knex, so take a consistent backup of every plugin database, not only the catalog. Store the backups and the app configuration in a location your recovery process can reach, and test a restore into a separate database instance. Confirm with your database team which PostgreSQL high availability and backup procedures apply in your environment. The step is done when a restore has been verified and the restore steps are written down.
Deploy the Operator or Helm chart in a test cluster
Install Red Hat Developer Hub in a non-production cluster using either the Operator or the Helm chart, following the installation path Red Hat documents for OpenShift Container Platform, Azure Kubernetes Service or Amazon Elastic Kubernetes Service. Choose between the two methods based on your cluster tooling and how you want upgrades handled, and record that decision. Load your restored data and plugin configuration into the test instance. The check is that the portal starts, the catalog loads, and each plugin you kept shows healthy status.
Migrate catalog data and templates
Move catalog entity definitions, software templates and TechDocs sources into the Developer Hub instance. These are the parts that transfer most directly, because they are data and repository content rather than code bound to your app. Re-run catalog ingestion, then compare entity counts and sample entity pages against the source. Rebuild any pipeline configuration that the templates call, since CI and CD wiring usually lives outside the portal. The step closes when a sample of templates scaffolds a working project in the test instance.
Cut over sign-in and users
Switch the production sign-in route to the Developer Hub instance during a planned window, with the old app still available for rollback. Confirm that users, teams and group ownership resolve correctly and that no session depends on the old app's cookies or callback URLs. Update the identity provider's registered redirect URLs as part of the change. The cutover is complete when a set of pilot users from each team has signed in and completed a routine task such as opening a catalog entity.
Retire the old app
Once the cutover has run without open defects for a period your team agrees on, stop the old Backstage app, archive its repository and configuration, and remove its database after you have kept a final verified backup. Record what was transferred, what was rebuilt and what was dropped, so the decision trail is available to auditors and the next team. The step is done when the old endpoints return no traffic, the backup is stored under your retention rules, and the decision record is filed.
Where Backstage and Developer Hub projects usually run long
Projects built on Backstage usually run long because the team owns the whole application, not just a product install. Scoping has to cover app scaffolding in TypeScript and React, the choice of plugins, authentication with sign-in resolvers that map every provider to the same identity, catalog modeling for components, systems and templates, and a CI pipeline that builds and deploys the app. The upgrade routine is part of that scope from day one. Backstage ships a main release line monthly and a next release line weekly, so the team must decide which line it follows, how often it rebases its app, and who tests each upgrade. Confirm the current release line and the Node.js versions the project supports before estimating, since the versioning policy ties supported Node.js releases to specific Backstage versions.
*Red Hat Developer Hub* moves much of that work into the platform, but the delay points shift to the cluster and the identity estate. Before scoping, confirm that the target OpenShift Container Platform, Azure Kubernetes Service or Amazon Elastic Kubernetes Service environment meets the prerequisites in the Developer Hub installation documentation, and decide whether the Operator or the Helm chart fits your change process. Identity setup, plugin configuration for Argo CD, Kubernetes, Tekton and GitHub, and the database and cache layers for high availability each need a named owner. Ask Red Hat or your partner which documented version your Developer Hub 1.10 deployment will follow and how Red Hat handles plugin compatibility during upgrades in your environment.
The two delay points that most often push schedules are catalog data quality and identity mapping. Catalog entries are only as good as the ownership, lifecycle and dependency metadata behind them, and that data often lives in repositories no one has reviewed in years. Identity mapping fails quietly when group or team membership in the identity provider does not match what the portal expects, which surfaces as access errors after go-live. Upgrade testing is the third risk: plan a staging environment that mirrors production plugins and sign-in configuration, and agree in writing who signs off each upgrade. Ask any proposal to name the Backstage or Developer Hub version it targets, the plugins in scope, the database HA design, and the testing responsibilities split between your team and the implementer.
Questions buyers ask before choosing Backstage or Developer Hub
How much does each option cost to run, and what drives the cost?
Backstage has no license fee, since the project is Apache-2.0 and there is no paid edition from the project itself, so its cost is people and infrastructure: engineers who build and maintain a TypeScript and React app, the database and cache layers, and the hosting underneath. Developer Hub is also Apache-2.0 licensed, but Red Hat sells it as a supported product, so the subscription is an added recurring line. The main drivers are the size of your plugin set, how many engineers you can spare for upgrades, and whether you already run OpenShift, AKS or EKS. Ask any vendor for the subscription terms, support tiers and what is included in the quote, and ask your own team to estimate the engineering hours per quarter.
How long does a first deployment usually take?
The time depends mostly on how much custom work you need before the portal is useful. Developer Hub can be installed through its Operator or Helm chart on OpenShift Container Platform, Azure Kubernetes Service or Amazon Elastic Kubernetes Service, which shortens the platform work, but you still need to configure authentication, catalog sources and the plugins your teams use. A self-built Backstage app adds the work of scaffolding the app, choosing and wiring plugins, and building your own container and deployment pipeline. Scope the first release as a fixed list of catalog sources, identity providers and plugins, then ask each candidate partner for a written timeline against that list.
What does the internal team need to have in place?
You need platform engineers who can run Kubernetes workloads, a database owner for PostgreSQL in production, and someone who understands identity. A self-built Backstage app also needs TypeScript and React skills, because adopters build and maintain their own app and plugins. Developer Hub reduces that front-end load because it ships with plugins such as Argo CD, Kubernetes, Tekton, Keycloak and GitHub Actions, but your team still owns configuration, catalog data and any custom plugin you write. Before committing, list the plugins your developers need and check which of them are preinstalled and which you must build.
Can a team build and maintain Backstage without outside help?
A team with strong TypeScript, React and Kubernetes skills can build and maintain Backstage in-house, and the project's documentation covers the architecture, authentication and upgrade steps. The harder part is sustained maintenance: Backstage's versioning policy ships a main release line monthly and a next line weekly, and it supports two adjacent even-numbered Node.js releases, so someone must keep the app current. Teams without that capacity often bring in an implementation partner for the first build and hand the upgrade routine to their own staff. DeployOpen plans, implements, upgrades and documents self-hosted platforms inside your environment, and its work is fixed-scope with the scope agreed in writing first.
Does Developer Hub lock us into Red Hat?
Developer Hub is based on Backstage and its repository is Apache-2.0 licensed, and Red Hat says the product is built on Backstage to help avoid vendor lock-in. Lock-in risk therefore sits mainly in the parts you add on top: Red Hat's certified pipelines and GitOps plugins are designed to integrate with OpenShift, and running the Operator and supported images ties your upgrade path to Red Hat's release cadence. To test this, check whether your plugins and catalog data would run on an upstream Backstage app, and ask Red Hat in writing which parts are supported when you move off the product.
How do upgrades differ between a self-built app and Developer Hub?
A self-built Backstage app is upgraded by your team against the upstream release line, which means merging framework changes into your own code, rebuilding plugins and testing. The upstream project backports high and critical severity vulnerabilities to releases from the last 6 months where feasible, so you must stay within that window to receive them. Developer Hub moves on Red Hat's documented versions, and version 1.10 is the latest documented release with versions back to 1.0 listed. Upgrade work then shifts to validating Red Hat's release against your plugins and Operator settings. Ask each option for its supported upgrade path and how security fixes reach your environment.
Must Developer Hub run on OpenShift?
No. Red Hat documents installing Developer Hub on OpenShift Container Platform, Azure Kubernetes Service and Amazon Elastic Kubernetes Service, using either the Operator or the Helm chart. OpenShift is the best fit when you already run it and want the certified pipelines and GitOps plugins that Red Hat designed for it. A self-built Backstage app can run on any Kubernetes platform you operate, and Developer Hub's community image is also published on Quay.io. Confirm your target cluster, support matrix and database high availability requirements with Red Hat before you commit to a deployment pattern.
How DeployOpen helps teams choose and implement a portal
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and that includes Backstage running in your own cloud account or cluster. If your team leans toward building on Backstage, the engagement covers the parts that most often stall a self-maintained portal: the app structure, the sign-in resolvers that map each identity provider to one user identity, the database and cache layout for production, and the upgrade path through the monthly main release line. If you lean toward Red Hat Developer Hub, the same work applies to installing and integrating it on OpenShift, AKS or EKS with the Operator or the Helm chart. Either way, the question to settle first is who will own the platform after go-live.
DeployOpen is not a partner or reseller of Red Hat, and it does not sell Red Hat subscriptions, so the advice on this page stays neutral between the two options. Scope and deliverables are agreed in writing before work starts, and quotes follow from that written scope. Ask for the scope to name the components in play: the plugins you need, the catalog sources, the authentication providers, the Node.js and PostgreSQL versions, the backup and restore procedure, and the upgrade runbook. Ask for each of these to be listed as a deliverable, not an intention. Ongoing support, upgrades and continuous testing are available as retainers, so ask separately what recurs after handover and what is one-time.
Before requesting a quote, confirm three points with the vendor or in your own environment rather than assuming them: which Red Hat Developer Hub release and subscription terms apply to your clusters, whether the plugins your teams depend on are included in the distribution or must be built and maintained by you, and which support window covers the Backstage version you run. DeployOpen can document the answers and turn them into a scoped plan, which gives your CISO, platform lead and procurement team the same written basis for comparing the two options.
