Roadie vs self-hosted Backstage: when each fits
Roadie suits teams that want someone else to run the portal, and self-hosted Backstage suits teams that have platform engineering skills and a concrete reason to keep the portal inside their own infrastructure. If your renewal is coming up and the question on the table is whether to keep paying for a managed portal or move it in-house, the answer depends less on features than on who will carry the operational load after the cutover. Both options run the same Apache-2.0 framework, so the catalog model, templates and TechDocs behave the same way. What differs is who performs upgrades, maintains plugins, operates the database and owns the sign-in configuration.
Roadie handles hosting, upgrades and vendor support as part of the subscription, which is why it fits organizations with a small platform team or none at all. Self-hosting shifts those duties to your staff: tracking the monthly main release line and the weekly next line, keeping Node.js versions within the two supported even-numbered releases, applying security backports, and maintaining PostgreSQL and any custom plugins. Ask Roadie to confirm in writing which plugins and Backstage versions it supports, and ask your own engineers to estimate the hours a month they can commit to upgrades before you decide.
The decision turns on three things: data location requirements, the team's capacity to run upgrades and plugins, and the sign-in model. If regulators or internal policy require the catalog to stay in your own data center, another region or an isolated network, self-hosting is the only path, and the question becomes whether you can staff it. On sign-in, Backstage ships 19 built-in authentication providers, and the authentication documentation advises a sign-in resolver that maps every provider to one identity and no guest access in production. Confirm that your identity provider and that resolver design are settled before choosing, because they shape the work either way.
Which option fits which situation
This table matches common buyer situations to the option that usually fits better, with the reason tied to each condition. Read each row as a condition first: the advantage only holds while that condition is true for your organization. The main takeaway is that the decision turns on who will carry upgrades, plugins and identity work, and where the data must sit.
| Situation | Better fit | Reason and condition |
|---|---|---|
| Small team with no dedicated platform engineers | Roadie | Managed upgrades, plugins and support reduce the ongoing work that would otherwise fall to developers who already have other jobs. This holds while no one on the team can own a monthly Backstage upgrade cycle. |
| Large platform team with custom plugins | Self-hosted Backstage | Your engineers can build, test and maintain in-house plugins against the framework directly. This holds when the team has capacity to track Backstage releases and own the plugin code long term. |
| Strict data residency or isolated network | Self-hosted Backstage | You choose where the catalog, TechDocs builds and PostgreSQL databases run. This holds when rules require the portal inside your own data center, a specific region or an air-gapped network, which Roadie's EU-hosted SaaS model may not meet. Confirm the exact residency terms with Roadie. |
| Existing Backstage experience in-house | Self-hosted Backstage | Engineers already familiar with plugin structure, sign-in resolvers and upgrades can run the platform without a vendor layer. This holds when that knowledge is spread across more than one person. |
| Multi-cloud or mixed identity providers | Depends on the identity setup | Backstage ships 19 built-in authentication providers, but you must configure sign-in resolvers so every provider maps to the same identity. Self-hosting gives you full control of that mapping; Roadie handles it for you. Choose based on who will own identity configuration. |
| Need for vendor-backed support on a fixed schedule | Roadie | A commercial contract gives you a named support path for incidents and upgrades. This holds when your internal policies require a supplier to answer for availability. Ask Roadie what support levels its plans include. |
| Want to avoid per-developer licensing growth | Self-hosted Backstage | Backstage is Apache-2.0 licensed with no paid edition from the project itself, so the main recurring costs become your infrastructure and staff time. This holds when you are prepared to fund platform engineering time. |
What stays the same in both models
Backstage itself is Apache-2.0 licensed and has no paid edition from the project, so the software you would host yourself is the same code that Roadie builds its managed portal on. The Software Catalog, Software Templates, TechDocs and the plugin model work the same way in both options. Your catalog entities, scaffolding templates and docs sources are not locked to either path. Confirm with Roadie which Backstage version and which plugins its current plan includes, and whether any of its features are proprietary extensions rather than upstream Backstage, because that determines how much of your setup carries over without rework.
Ownership data lives in the repositories, not in the portal. Entities are described in catalog-info.yaml descriptor files, so the same Component, API, System, Group and User definitions can be read by a self-hosted instance once it is pointed at your repositories. Authentication is also not a differentiator in principle: Backstage ships 19 built-in authentication providers, including GitHub, GitLab, Google, Azure, Okta and generic OIDC. What you do control in both models is the sign-in resolver configuration, which should map every provider to one consistent identity, and the decision to disable guest access in production. Check that your identity provider is on the supported list before you commit to either path.
The release cadence is set by the Backstage project, not by the operator. The main release line ships monthly and the next line ships weekly, and high and critical security fixes are backported to recent releases where feasible. Roadie decides when its customers receive those versions, while a self-hosted team decides when to pull them in, so the lag is a schedule you choose, not a difference in code. The real difference is who operates the instance: who applies upgrades, runs the database, patches Node.js versions and keeps custom plugins compatible. Those operating duties are the subject of the sections that follow.
Capabilities compared: Roadie and self-hosted Backstage
This table sets Roadie's managed offering beside self-hosted Backstage, row by row. The open-source column uses only what Backstage documents, while the Roadie column lists what you must confirm with Roadie in writing before comparing contracts. Read it as a checklist of where your team would own the work.
| Capability | Self-hosted Backstage (open source) | Roadie (what to confirm in writing) |
|---|---|---|
| Software Catalog | Built-in core feature; entities defined in catalog-info.yaml files kept in your repositories, with kinds such as Component, API, System and Group | Confirm that catalog-info.yaml files in your repositories remain the source of truth and how UI- or API-created entities are stored and exported |
| Software Templates | Built-in core feature for scaffolding new services and docs from templates you write and maintain | Confirm which template actions are supported, whether custom actions are allowed, and who maintains template changes |
| TechDocs | Docs-like-code: Markdown lives beside source code and is built into sites with MkDocs, including MkDocs plugins | Confirm the MkDocs plugins and build pipeline Roadie supports and where generated docs are stored |
| Plugin ecosystem | Open plugin ecosystem; you select, install and patch plugins, and write custom plugins in your own code | Confirm which plugins are included, which are paid or add-on, and how custom plugins are supported and upgraded |
| Authentication providers | 19 built-in providers, including GitHub, GitLab, Google, Azure, Okta, Auth0 and generic OIDC; you configure sign-in resolvers and disable guest access in production | Confirm which identity providers and SSO options are supported, and who configures sign-in resolvers |
| Upgrades and security backports | Main release line ships monthly; high and critical vulnerabilities are backported to releases from the last 6 months where feasible; your team applies upgrades | Confirm upgrade cadence, who performs upgrades, testing before rollout, and the backport commitments in your contract |
| Database and caching | PostgreSQL in production, SQLite for development; each backend plugin gets its own logical database; Redis, Memcache, Infinispan or in-memory caching | Confirm the database engine, backup and restore responsibilities, and which caching options Roadie operates |
| Support | Community support through the open-source project; any commercial support comes from a partner or your own team | Confirm support hours, response targets and escalation paths in the written agreement |
| Data location | Runs in infrastructure you choose, including on-premises, another region or an isolated network | Confirm where the catalog, documents and logs are stored and processed, and which sub-processors have access |
What data control and sign-in change for your organization
Moving from a hosted portal to your own Backstage shifts where catalog data lives, how people sign in, and who guards the network path to the instance. Each card below is a decision you own once you host it, and each has a written question to put to Roadie before you decide.
Data location and residency
Roadie stores portal data in the EU as a SaaS service. If your rules require the catalog, TechDocs output or search index to stay in a specific data center, region or isolated network, a self-hosted instance lets you choose the location. Ask Roadie in writing where each data type is stored, which sub-processors touch it, where backups are kept, and how long they are retained after contract end. Then compare those answers with your own residency obligations.
Sign-in design across providers
Backstage ships 19 built-in authentication providers, including GitHub, GitLab, Google, Azure, Okta and generic OIDC. The sign-in resolver decides which user identity each provider maps to, and a poor mapping can give one person two catalog identities or let the wrong account claim ownership. Ask Roadie how its sign-in resolvers map identities, whether guest access is available in production, and who controls the mapping rules when your identity provider changes.
Network exposure of the instance
A self-hosted portal is reachable from wherever you allow it, so you decide which networks, load balancers and ingress rules expose the frontend and backend. Push-based integrations and webhooks may need inbound paths that a hosted vendor otherwise manages for you. Ask Roadie which inbound endpoints its service requires, which IP ranges it calls from, and how it isolates one customer's tenant from another. Use those answers to set your own firewall and ingress policy.
Secrets and database access
A self-hosted Backstage holds integration tokens for source hosts, cloud accounts and CI systems, and it stores catalog and plugin state in PostgreSQL, with each backend plugin using its own logical database. You become responsible for storing those secrets, rotating them, restricting which service accounts can read the database, and encrypting backups. Ask Roadie how it stores integration credentials, who in its operations team can access customer databases, and how it handles credential rotation and access logging.
Compliance evidence
Assessments need evidence that controls operate over time, such as access reviews, change records, backup restore tests and vulnerability patch history. A hosted vendor may provide some of this, and a self-hosted instance gives you the logs, but both still need to be collected and mapped to your framework. Independent auditors issue reports and certifications; DeployOpen prepares the controls and evidence for that assessment. Ask Roadie which independent reports it holds, their scope and dates, and whether it will share them under your NDA.
Who each option suits by team size and skills
A small product team usually has no dedicated platform engineers, and its engineers would rather ship product than run infrastructure. For this profile, Roadie removes the work of hosting, patching and upgrading Backstage, and the vendor carries the operational load of keeping the portal current. Self-hosting is workable only if one or two engineers can take on the portal as a sideline, with clear ownership.
- Skills to run Roadie: Catalog ownership, YAML descriptors in each repository, and familiarity with Backstage concepts such as Components and Groups.
- Skills to self-host: Kubernetes or a comparable container platform, PostgreSQL administration, Node.js and TypeScript for plugin work, and OAuth or OIDC configuration.
- Upgrade load: Backstage's main release line ships monthly and the next line ships weekly, so a self-hosted team must schedule upgrades and resolve plugin breakage each cycle.
- On-call load: Someone must own outages of the portal, the database and the authentication flow, often with no backup person.
- When Roadie remains the better fit: The team has no one who can own upgrades and incidents, or the portal is needed quickly and the team cannot fund a platform role.
Before deciding, ask who on the team will hold the upgrade calendar for the next year and what happens when that person is on leave.
A mid-sized platform team has some Backstage experience, usually from a pilot, and treats the developer portal as one service among several it runs. This team can absorb routine upgrades and small plugin changes, but custom authentication, search and TechDocs pipelines add work that competes with other platform priorities. The decision often turns on whether the team wants to own the portal's roadmap or spend its time on the wider platform.
- Skills to run Roadie: Catalog and template authoring, plugin configuration requests to the vendor, and governance of entity ownership across teams.
- Skills to self-host: Backstage app and plugin development, sign-in resolver design, PostgreSQL backups, and CI pipelines that build and deploy the portal image.
- Upgrade load: The team should plan for each monthly main release, read the versioning policy, and test plugin compatibility before rollout. High and critical vulnerabilities are backported to releases from the last six months where feasible, so staying within that window is a practical target.
- On-call load: A shared rotation covers the portal alongside other services, so the team needs runbooks for database failover and identity provider outages.
- When Roadie remains the better fit: Custom plugin work is light, the team wants vendor-managed Scorecards and support, and platform engineers would rather focus on golden paths than portal internals.
Check whether your team can name a plugin owner for each custom integration and who approves an upgrade when a plugin lags behind the core release.
A large platform organization often runs many custom plugins, integrates with internal identity and ticketing systems, and must keep the portal inside its own data center, cloud account or isolated network. For this profile, self-hosting is frequently the only option that meets hosting rules, and the operating cost is spread across a dedicated team. Roadie can still fit where data location rules allow SaaS and the organization prefers to buy operations.
- Skills to run Roadie: Vendor management, plugin request processes, and internal integration work that calls vendor APIs or exports data on a schedule.
- Skills to self-host: Platform engineering across Kubernetes, PostgreSQL, caching such as Redis, search, and TechDocs builds, plus security engineering for sign-in resolvers and secrets handling.
- Upgrade load: Upgrades need staging environments, plugin regression tests and change records, and the team must watch the Node.js versions Backstage supports at each release.
- On-call load: Dedicated rotations cover the portal, identity flows and the data layer, and incident response must match the organization's regulatory reporting obligations.
- When Roadie remains the better fit: The data location rules permit EU-hosted SaaS, custom plugin volume is low, or the organization cannot staff a durable platform team for the portal.
Confirm with your security and legal teams which data location and access rules apply before comparing costs, because they often decide the question on their own.
Teams in banking, healthcare, public sector or critical infrastructure often need the portal and its catalog inside their own network, possibly without outbound internet access. Roadie's SaaS model does not fit those constraints. Self-hosted Backstage can run in that environment, but the team must mirror container images, packages and documentation dependencies, and manage every upgrade through its own change process. The security and compliance workload grows with the scope of the portal.
- Skills to run Roadie: Documenting the SaaS data flow for risk reviews and reviewing the vendor's security documentation.
- Skills to self-host: Offline package mirroring, certificate management, and control design for access reviews on the portal.
- Upgrade load: Each Backstage release, including the monthly main line, passes through the organization's approval and testing stages, so upgrade lead time matters.
- On-call load: Incidents may require isolated troubleshooting with no vendor support channel, so runbooks and internal expertise carry more weight.
- When Roadie remains the better fit: Only when the organization's rules explicitly allow the EU-hosted SaaS model, which is often not the case for air-gapped or on-premises requirements.
For each control your auditors ask about, confirm the evidence source with your assessor, since DeployOpen prepares controls and evidence but does not issue assessment outcomes.
What the cost of each option is made of
Roadie's cost is a subscription, and the subscription bundles more than hosting. Your invoice pays for the managed Backstage service, the upgrades and plugin maintenance Roadie carries, and the support tier you buy. Plan minimums and add-ons, including paid Scorecards, are separate line items that can change the total more than the headline per-developer rate. Ask Roadie for the price basis in writing: what is counted as a seat or user, how the minimum is set, which features sit in which plan, what an add-on costs, how often prices can be revised, and what happens to data and access at the end of the term. Pricing is one-time only at signup. Everything else recurs, so the seat count and the plan tier are the main drivers.
Self-hosting moves those costs onto your own budget. The recurring items are compute and storage for the Backstage backend and frontend, a PostgreSQL service (Backstage uses PostgreSQL in production), search and caching if you run them, and staff time. Staff time is the largest and least visible part. Backstage's versioning policy ships a main release line monthly and a next line weekly, and high and critical vulnerabilities are backported to releases from the last 6 months if feasible. Each upgrade, Node.js version change and plugin update takes engineering time, and so does security patching. Plugin development for integrations you need, and the platform engineers who own the instance, complete the recurring picture. Confirm with your own team how many release cycles per year you can absorb before you rely on this estimate.
One-time costs on the self-hosted side are the initial build, the authentication and sign-in resolver design, the migration of catalog data and integrations, and the first TechDocs and search setup. Their size depends on how many custom plugins and integrations you need and how much of your existing catalog you rebuild. Get a fixed-scope written proposal from any implementation partner before you commit, including the deliverables, the timeline and the handover of runbooks. DeployOpen plans and delivers this kind of work under a written scope, and its ongoing support and upgrade work is available as a retainer, so the quote reflects what you choose to hand over and what you keep in-house.
What a move from Roadie to self-hosted Backstage involves
The sequence takes a catalog that already follows the Backstage model and moves it onto a Backstage instance your team runs, with sign-in, integrations and docs rebuilt and ownership data intact at cutover. The effort depends on how many entities were created through the Roadie UI or API rather than in repositories.
Inventory where the catalog lives
Start by sorting every entity into one of two groups: those already described in catalog-info.yaml files in repositories, and those created through the Roadie UI or API. Repository-based entities move with their code. UI- and API-created entities need to be exported or rewritten as descriptor files before they can be carried over. Confirm Roadie's export terms and data retention rules now, while the contract is still in force. The step is done when every entity has a named source and an owner, and the team agrees on the list of entities that must be recreated by hand.
Stand up a Backstage instance with PostgreSQL
Deploy a Backstage application in your own cloud account, data center or cluster, backed by PostgreSQL, which Backstage uses in production. Use SQLite only for local development. Choose a Node.js version from the set supported by the release line you pick, and set up a pipeline that builds and deploys the app. The step is done when the instance starts, the Software Catalog loads a test catalog-info.yaml from a repository, and the database holds the catalog tables your backend plugins create.
Configure sign-in resolvers for one identity
Connect your identity provider and the source-control providers your teams use, then configure sign-in resolvers so every provider maps to the same user identity. Disable guest access in production. Your security team should review this step, since it decides who can read and change catalog ownership. The step is done when a user who signs in with two different providers appears as one user, group membership resolves from your directory, and an unauthenticated request to the catalog is refused.
Rebuild integrations, scorecards and custom plugins
Recreate the discovery sources, Kubernetes and search integrations, scorecards and any custom Roadie features your teams rely on as Backstage plugins or configuration. Scorecards are not carried over automatically, so their rules must be rewritten and tested against the migrated catalog. Custom plugins need owners, a test suite and a plan for upgrades. The step is done when the portal shows the same components, owners and scorecard results for a sample set of services that teams have checked by hand.
Set up TechDocs and search
Configure TechDocs so that Markdown kept next to code builds into documentation sites with MkDocs, including any MkDocs plugins your teams use. Set up search over catalog entities and docs, and choose the storage and caching that your scale needs. Confirm how the build runs and where the generated sites are stored. The step is done when documentation for a representative set of services builds on the new instance and search returns entities and pages from both catalog and docs.
Cut over and retire the Roadie tenant
Run the two portals in parallel for a short period agreed by your team, compare ownership and entity counts, and then point teams and links at the new instance. Keep the exported catalog and a record of owners, groups and scorecard definitions until the migration is signed off. Retire the Roadie tenant only after the export is complete and verified. The step is done when ownership data matches between systems, every team can sign in and find its services, and the remaining Roadie data has been exported and stored under your retention policy.
Questions buyers ask before choosing self-hosted Backstage
How much effort does running Backstage take after launch?
Running Backstage is ongoing work, not a one-time install. Effort comes from keeping the framework current, maintaining the plugins your teams depend on, operating PostgreSQL and the hosting platform, and supporting users. The Backstage versioning policy describes a main release line that ships monthly, on the Tuesday before the third Wednesday of each month, plus a next line that ships weekly on Tuesdays. Someone must test and roll out those releases. The policy also says high and critical vulnerabilities are backported to releases from the last 6 months where feasible, so staying on a supported release line matters for security. Ask your team to size the upgrade cycle against the release cadence before committing.
Can our team run Backstage without outside help?
A team can run Backstage without outside help if it already has strong Node.js, TypeScript, Kubernetes and identity skills and enough capacity to own the platform long term. The hard parts are rarely the first install. They are authentication, custom plugins, upgrade testing and on-call response. Backstage ships 19 built-in authentication providers, but configuring sign-in resolvers so every provider maps to the same identity, and disabling guest access in production, requires careful design. Check whether two or more engineers can carry this work without it stalling when one leaves.
What does the work need from our organization?
Plan for three things: skills, access and a named owner. Skills should cover Kubernetes or your hosting platform, PostgreSQL, OIDC or SAML identity integration, and the source systems you connect, such as Git providers and CI. Access means cloud accounts, a database, identity provider application registrations, and tokens for each integration. The most important item is a named product owner with authority to decide plugin priorities and the upgrade schedule. Without that owner, the catalog drifts and the portal loses trust with engineering teams.
How long does a move from Roadie to self-hosted Backstage take?
The timeline depends on catalog size, the number of integrations to re-create, how many custom plugins or scorecards must be rebuilt, and how much identity and TechDocs work is needed before cutover. Because catalog entities are usually kept as catalog-info.yaml files in repositories, the data move is often the smaller part. Integrations, authentication and any Roadie-specific features are usually the longer items. No duration is fixed here, so ask for a timeline that breaks the work into discovery, build, parallel run and cutover, with the dependencies named for each step.
Does the Backstage license cost anything?
The Backstage framework is released under the Apache License 2.0 (SPDX: Apache-2.0), and the project offers no paid edition of its own. The license itself is free, so your cost is the infrastructure and people needed to run it: hosting, PostgreSQL, monitoring, engineering time for upgrades and plugins, and support if you buy it. Backstage was accepted to the CNCF on September 8, 2020 and moved to the Incubating maturity level on March 15, 2022, which signals an active governance model but does not change the cost. Compare this with Roadie's subscription, paid features and plan minimums, and ask any third-party provider what is priced separately.
When should we hire a consultant or implementation partner?
Consider a partner when the migration has a fixed deadline, when identity or compliance requirements are strict, or when your team lacks the capacity to run a platform alongside product work. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for the scope to list the integrations, plugins, authentication setup and knowledge transfer included.
What should we check before deciding to self-host?
Check four areas before deciding. First, confirm which Roadie features you actually use, including scorecards, plugins and support, and which ones you can replace. Second, confirm your data location requirements, because self-hosting moves the portal and catalog into your own environment. Third, confirm whether your team has the skills and capacity described above. Fourth, get a written estimate of ongoing run costs, not only the first build. Ask your team to test an upgrade in a staging environment before committing, since that test shows the real recurring effort more clearly than any comparison table.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so a Backstage portal can run in your cloud account, data center or isolated network. We start with a written scope that tells you what a self-hosted Backstage would take before you commit to either path.
How we scope
- Inventory your current Roadie usage, including catalog entities, plugins, scorecards, TechDocs sites and sign-in setup.
- Agree which Backstage plugins, authentication providers and catalog sources the self-hosted portal must support.
- Define who owns upgrades, plugin maintenance and on-call for the portal before any build starts.
- Confirm hosting location, data residency needs and network access rules in writing.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- Deploy Backstage in your environment with PostgreSQL, caching and search configured for your load.
- Connect catalog-info.yaml discovery from your repositories and rebuild any integrations your teams rely on.
- Configure sign-in resolvers so every identity provider maps to the same user, with guest access disabled in production.
- Set up TechDocs builds and custom plugins, and test them against the upgrade cadence you choose.
- Run security testing of the portal and its integrations before it carries real ownership data.
How we hand over
- Document the deployment, configuration, upgrade steps and plugin ownership for your platform team.
- Walk through the runbooks for monthly Backstage releases and for security patches on a supported Node.js version.
- Provide evidence and configuration records that support your internal or external compliance reviews, without issuing any attestation.
- Agree a cutover plan that keeps ownership data intact and gives your teams a rollback path.
- Hand over access and credentials under your control, with your team holding the keys to the environment.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover Backstage version upgrades, plugin updates and periodic security testing of the portal.
- Ask for a quote that separates one-time build work from recurring support, so you can compare it with your Roadie renewal.
- Confirm response expectations and escalation paths in the retainer scope before signing.
- Your platform team can take over operations at any point, with documentation kept current as the portal changes.
