Where self-hosted Backstage costs less than Roadie, and where it costs more
A Roadie renewal or pricing change usually forces one question: what does the subscription buy that your own team would otherwise have to build? Backstage carries no license fee from the project itself, so the comparison turns on people, infrastructure and upgrade effort set against Roadie's subscription. Backstage is licensed under Apache-2.0 and there is no paid edition from the project, which means the recurring cost of self-hosting is the team and the infrastructure around it, not a line item you can negotiate away. Roadie's public pricing figures were not available to us, so do not compare against a number from a forum or a competitor's page. Ask Roadie for a written quote that states the per-developer rate, the plan minimum, whether Scorecards are included or billed separately, and what support and upgrade work the price covers. Then build your own model with these components: hosting for the Backstage backend and frontend, a PostgreSQL database (Backstage uses PostgreSQL in production), a caching layer if you add one, the search and authentication setup, and the engineers who handle upgrades. Backstage's versioning policy ships a main release line monthly and a next release line weekly, so the upgrade effort recurs. Confirm with your own engineers how many hours a month that takes in your environment. Self-hosting costs more where the work is people-heavy and continuous. Budget for custom plugin development, sign-in resolvers that map every identity provider to one user, the security review of your deployment, and at least one platform engineer who owns the portal. Self-hosting costs less when your developer count is large, your plugin needs are modest, or data location and network isolation are requirements that a SaaS subscription cannot meet. Ask each cost to be shown as one-time (migration, initial plugin build) or recurring (hosting, upgrades, on-call), because the recurring part decides the long-run comparison.
Cost components on each side
This table lists each cost component of a hosted Roadie portal and a self-hosted Backstage portal, who receives the payment, and whether the cost is one-time or recurring. Roadie's pricing is set by its own quote and contract, so confirm per-developer rates, Scorecards add-ons and plan minimums in writing. The main takeaway is that Backstage removes the license line but moves hosting, upgrades and staffing onto your budget.
| Cost component | Roadie (hosted) | Self-hosted Backstage |
|---|---|---|
| Software license | Recurring subscription to Roadie, priced per developer with plan minimums; ask Roadie for the current rate card | None. Backstage is Apache-2.0 licensed with no paid edition from the project itself |
| Scorecards and advanced features | Recurring, may be a paid add-on; confirm which features are included in your plan | One-time build or open-source plugin adoption, then recurring maintenance by your team |
| Hosting compute (Kubernetes or VMs) | Included in the subscription; Roadie pays for hosting | Recurring cloud or data center spend paid to your infrastructure provider, sized to your catalog and traffic |
| PostgreSQL and caching | Included in the subscription | Recurring database service or self-managed cluster, plus backups; Backstage uses PostgreSQL in production |
| Search and TechDocs builds | Included in the subscription | Recurring compute for search indexing and TechDocs builds, paid to your infrastructure provider |
| Plugin development | Limited to what Roadie supports; custom work is quoted separately if offered | One-time for initial plugins (often a consulting or internal engineering cost), then recurring for updates |
| Monthly and security upgrades | Handled by Roadie within the subscription | Recurring engineering time. Backstage ships a monthly main release line and weekly next releases, and high or critical fixes are backported to recent releases |
| Authentication and sign-in resolvers | Typically set up during onboarding; confirm scope with Roadie | One-time configuration of identity providers, then recurring review as identity systems change |
| Support | Recurring, included in the plan tier you buy; confirm response terms in the contract | Recurring if you buy a retainer from a partner or vendor; otherwise internal on-call time |
| Platform engineer time | Lower; Roadie operates the service | Recurring, the largest line item in most self-hosted budgets. Ask a partner for a written scope before estimating headcount |
What moves the comparison most
Roadie's bill and a self-hosted Backstage bill respond to different inputs, so the same team can land on either side depending on its profile. The six drivers below show which direction each one pushes the total, and what to pull from your own environment before requesting a quote.
Developer count and seat pricing
Roadie is priced per developer, so its subscription grows with every engineer who needs a seat, and the increase is recurring. Self-hosted Backstage has no per-seat license, so its cost grows more with infrastructure, support and platform staffing than with headcount. Confirm the seat definition, whether read-only viewers are billed, and the plan minimum in the current Roadie order form before comparing.
Scorecards and custom plugins
Scorecards are a paid add-on in Roadie, so each additional scorecard or rubric can add to the recurring bill. On the self-hosted side, scorecards and custom plugins are code your team writes, reviews and upgrades, which means engineering time instead of a line item. Count the scorecards you need today and the plugins you expect to maintain for the next two years.
Catalog entity volume and TechDocs size
Entity counts and documentation volume drive database size, indexing work and search load. Backstage stores catalog and plugin data in PostgreSQL in production, so a larger catalog raises database storage and backup needs on your side. Ask Roadie how entity and documentation usage is metered, and estimate your own volume from the number of catalog-info.yaml files and the size of your MkDocs sites.
Availability and on-call coverage
A managed service shifts uptime responsibility to the vendor under its contract terms, while a self-hosted portal makes your team answerable for outages, database failover and paging. Higher availability targets increase on-call rotations, monitoring and redundancy costs on the self-hosted side. Check the uptime commitment and support hours in Roadie's contract, then compare them with the on-call hours your platform team can sustain.
Data location requirement
If your policy requires the catalog, documentation and integration data to stay in your own data center, another region or an isolated network, Roadie's SaaS model may not meet the requirement. Self-hosting removes that constraint but adds hosting, backup and access-control work that you must staff and evidence. Confirm where Roadie stores data and which contractual terms apply before you decide that residency alone settles the question.
Existing platform and Kubernetes skills
Teams that already run Kubernetes, PostgreSQL and CI pipelines can absorb a Backstage deployment with less new hiring, which lowers the self-hosted cost. Teams without that experience will pay for training, a platform engineer or an implementation partner, and those costs recur as upgrades arrive. Inventory the skills your platform team has, then decide whether the monthly upgrade cadence fits your capacity.
How to build the comparison with your own numbers
This sequence turns a vague sense that self-hosting is cheaper into a three-year total built from Roadie's written quote, your own cloud bills and your own staffing rates. Every figure in the final comparison should trace back to a document your organization holds.
Get Roadie's written quote for your headcount
Ask Roadie for a written quote that states the per-developer price, the plan minimum that applies to your size, and whether any Scorecards, integrations or support tiers are priced separately. Ask the vendor to confirm how seats are counted, including contractors, bots and service accounts, and how the price changes at renewal. The step is done when you have a document that lists every line item and its billing unit, and you can point to the clause that sets the minimum.
Inventory every Scorecard and integration in use
Export the list of Scorecards, data sources and plugins your teams rely on today, and mark which ones are included in the Roadie plan and which are add-ons. Count the integrations by system, such as source control, CI, cloud accounts and incident tools, because each one needs a plugin, a credential and an owner after migration. The step is done when every Scorecard and integration has a row in a shared sheet with its owner and a note on whether a Backstage equivalent exists or must be built.
Estimate platform engineering hours for upgrades
Backstage ships its main release line monthly, on the Tuesday before the third Wednesday of each month, and its next release line weekly on Tuesdays, according to the Backstage versioning policy. Plan for the monthly main line at minimum, because high and critical vulnerability fixes are backported to releases from the last six months when feasible. Multiply the expected hours per upgrade cycle, including dependency updates, plugin compatibility checks and Node.js changes, by your fully loaded platform engineering rate. The step is done when you have a monthly hours figure you can defend, with the assumptions written down.
Price hosting and PostgreSQL in your own accounts
Ask your cloud or infrastructure team to price the compute, load balancing, storage, backups, monitoring and PostgreSQL service that a production Backstage instance needs in the accounts where it will run, using your own discount rates. Include staging and development environments if you will keep them, because they are a recurring cost too. Backstage uses PostgreSQL in production, and each backend plugin gets its own logical database through Knex, so size the database for that layout. The step is done when a finance-readable table shows monthly hosting cost by component, sourced from your cloud bill estimate.
Add plugin and authentication build time
Estimate the one-time work to build or adopt the plugins your inventory marked as missing, and the work to configure authentication. Backstage includes 19 built-in authentication providers, but the authentication documentation advises setting sign-in resolvers so every provider resolves to the same identity and not offering guest access in production, so budget time for resolver design and testing. Record the estimate as one-time effort, separate from recurring upkeep, and note who will maintain each custom plugin after launch. The step is done when one-time build hours are listed per plugin and per authentication provider, with a named owner for each.
Compare three-year totals side by side
Build a table with one column for Roadie and one for self-hosted Backstage, and split each into one-time costs and recurring costs for years one through three. Recurring Roadie costs are the seat price multiplied by headcount, plus any add-ons and any renewal increase stated in the quote. Recurring self-hosted costs are hosting, database, monthly upgrade hours, plugin maintenance and the share of platform engineers' time the portal consumes. Run the table twice, once with your best estimates and once with the upper end of each range, so the decision holds under uncertainty. The step is done when both columns total to three years and the difference is traceable to specific rows.
Test the result against team size and skills
Review the totals with the people who would operate the portal and with finance. Ask whether your platform team has the Kubernetes, Node.js and TypeScript skills to absorb monthly upgrades, and whether the data location requirements would make a managed option unavailable in any case. If the numbers favor self-hosting only when hours are assumed to be low, flag that as a risk instead of a saving. The step is done when the team signs off on the assumptions in writing and the open questions are assigned to named owners.
Why monthly upgrades are the recurring cost you cannot skip
The recurring cost of self-hosted Backstage is not the server. It is the upgrade cycle. Backstage's main release line ships monthly, on the Tuesday before the third Wednesday of each month, and the next release line ships weekly on Tuesdays, according to the Backstage versioning policy. Under that policy, high and critical severity vulnerabilities are backported to releases from the last six months where feasible, and other security fixes may be backported. That means a team that stays on a release for a year is running a version that may no longer receive backports, so the realistic plan is a standing monthly upgrade window, not an occasional project.
Each upgrade also moves the runtime underneath it. The versioning policy says Backstage supports exactly two adjacent even-numbered Node.js releases, and as of Backstage 1.46.0 these are Node.js 22 and 24. When a Node.js line is dropped, your Node version, base images and CI build images change with it. Before each cutover, the team should test every custom plugin, template and internal integration against the target release, check the upgrade notes for breaking changes, and keep a patched version running in production while the next one is tested. Ask whether your engineers have time for this every month, and who covers it during holidays or staff turnover.
In a cost comparison, Roadie's upgrades are part of its service, so the monthly work above is a line item you would move onto your own payroll if you switch. That is a comparison point, not a judgment about Roadie's quality. When you request figures from Roadie and from any other vendor, ask what is included in upgrades, whether custom plugins are covered, and how long they keep older releases in service. Then estimate your own hours per release cycle, multiply by the number of engineers who must be trained to do it, and compare that with the subscription. Confirm the current release cadence on the Backstage versioning policy before you build the model.
What a self-hosted Cortex or OpsLevel costs in practice
Cortex documents a self-managed deployment into your own Kubernetes cluster using a Helm chart. The deployment requires a JWT license key and an access token, both issued by the Cortex account team, and a PostgreSQL database. The cluster can run on EKS, AKS, GKE or a locally installed Kubernetes distribution, so the infrastructure lines of your bill depend on where that cluster already lives.
- License key and token: Cortex issues the JWT license key and access token through its account team, so the subscription terms and renewal dates sit in that contract.
- Kubernetes capacity: You pay for the nodes, storage and load balancing the chart consumes, whether on a managed cloud service or on hardware you already operate.
- PostgreSQL: You provide and operate the database, including backups, patching, failover and sizing as the catalog grows.
- Platform staff: Someone must upgrade the Helm release, rotate the access token when needed and troubleshoot the cluster, which is recurring internal labor.
- Connectors and integrations: Confirm with Cortex which integrations are included in the self-managed license and which need separate work.
Ask Cortex for a written statement of what the license covers, how it renews and whether the self-managed edition changes the price. Confirm the Kubernetes and PostgreSQL requirements against your own platform team's standards before comparing totals.
OpsLevel documents a self-hosted edition installed through Replicated. It requires a license file from OpsLevel and runs on a Kubernetes cluster, which OpsLevel prefers, or on a virtual machine. The instance must be reachable over the internet for push-based integrations, which affects your network design and security review. OpsLevel publishes minimum specifications of 16 CPU, 16 GB of memory, capacity for at least 20 pods and 24 Gi of disk for pilots or 120 Gi for production.
- License file: OpsLevel supplies the license file, so the subscription continues alongside the infrastructure you run.
- Replicated install: The installer and its update path are part of the operating work, and someone must own them.
- Published minimums: The 16 CPU, 16 GB memory, 20 pod and disk figures are a floor for sizing, not a forecast of your usage.
- Internet reachability: Push-based integrations require inbound access, which may need firewall changes, a reverse proxy and extra review by your security team.
- Storage growth: Plan for the production disk figure of 120 Gi from the start and monitor it as the catalog and integrations grow.
Request the current specifications and license terms in writing from OpsLevel before you size hardware, because published minimums can change between releases.
Backstage is open source under the Apache License 2.0 and has no paid edition from the project itself, so there is no license fee to remove. Your cost is the infrastructure, the database and the engineering time to build and keep the portal running. Backstage uses PostgreSQL in production and supports several caching options, including Redis. Upgrades are part of ownership: the main release line ships monthly and the next line ships weekly.
- No license line: The framework itself carries no subscription, but you still pay for hosting, PostgreSQL and any caching service you choose.
- Monthly upgrades: Plan recurring time to take main release line updates, test plugins and deploy to production.
- Plugins and integrations: Custom plugins, authentication resolvers and integrations are built and maintained by your team or a partner you hire.
- Security patching: The versioning policy says high and critical vulnerabilities are backported to releases from the last six months where feasible, but applying those fixes is your job.
- Platform engineers: Staffing is usually the largest recurring cost, and it scales with the number of plugins and the depth of your customization.
Before comparing totals, estimate the platform engineering time you can dedicate to upgrades and plugins, and compare that against the vendor quote.
Questions buyers ask before comparing Roadie with self-hosted Backstage
How much effort does self-hosting Backstage take, and what skills does it need?
Self-hosting means your team deploys, configures and operates the portal, so the work is ongoing platform engineering rather than a one-time install. The skills you need are Kubernetes or container hosting, PostgreSQL administration, Node.js and TypeScript for plugins, identity provider configuration, and CI/CD for the Backstage application itself. Backstage's main release line ships monthly, and the next release line ships weekly on Tuesdays, so someone must own the upgrade cadence. Backstage supports exactly two adjacent even-numbered Node.js releases, which means Node.js upgrades are part of routine maintenance. Ask any implementation partner to show the skills matrix and the upgrade calendar in the written scope.
Can a small platform team run self-hosted Backstage alone?
A small team can run it, but the answer depends on how many plugins, integrations and authentication providers you need and how much custom code you own. Backstage is Apache-2.0 licensed with no paid edition from the project itself, so the software itself carries no license fee. The recurring load comes from monthly upgrades, plugin maintenance, security patches and on-call coverage for the hosting layer. The Backstage versioning policy says high and critical severity vulnerabilities will always be backported to releases from the last 6 months if feasible, which means you must still take in those releases on time. Plan for named owners, a backup person, and a defined upgrade window before you commit to running it alone.
How long does a migration from Roadie to self-hosted Backstage take?
No researched figure is available for this, so ask for a scoped timeline in writing rather than relying on a general estimate. The duration depends on the number of catalog entities, whether your catalog-info.yaml files already live in your repositories, how many integrations and scorecards must be rebuilt, the authentication setup, and how TechDocs and search are configured. Entities created only through the UI or API need exporting before the contract ends, which can add work. DeployOpen plans and implements these engagements on a fixed scope with deliverables and timelines agreed in writing before work starts, so the scoped timeline is the document to request from any provider.
What do Roadie's paid Scorecards replace in a self-hosted setup?
In a self-hosted setup, scorecard logic is not a single product you buy but a combination of catalog data and custom code. Backstage's catalog stores ownership and metadata through descriptor files, such as catalog-info.yaml with kinds like Component, System and Group, so most scorecard inputs already exist in your repositories. The scoring rules, checks and dashboards must then be built or adapted by your team or a partner, using plugins or custom development. Ask Roadie for a full list of the checks a paid Scorecard runs, then map each check to a data source you already control. Count the build and maintenance of those checks as an ongoing engineering cost.
Does buying a commercial self-managed edition remove the subscription?
No. Commercial self-managed editions still require a vendor license, so self-hosting them does not remove the subscription. Cortex's self-managed deployment requires a JWT license key and access token from its account team, and OpsLevel's self-hosted edition requires a license file from OpsLevel. Both also need their own infrastructure, such as a PostgreSQL database or a Kubernetes cluster, so you pay for the license and the hosting. Backstage itself has no paid edition from the project. If you are comparing options, ask any vendor whether the license fee, support and infrastructure costs are all in the quote, and whether renewal terms change the total.
What does the work need from our internal staff?
The work needs named staff for several roles, even when a partner does the initial build. Expect a sponsor who approves scope and owns the budget, an engineer who understands your identity provider and sign-in resolvers, someone who maintains catalog-info.yaml standards across teams, and a platform owner for upgrades. Backstage's authentication documentation advises configuring sign-in resolvers so every provider resolves to the same identity and not offering guest access in production, so security reviewers must be involved early. Staff time is the cost most often underestimated, so ask for a written list of internal dependencies in the scope.
Does an implementation partner change the total cost of self-hosting?
A partner changes the mix of costs rather than removing them. You still pay for hosting, PostgreSQL, monthly upgrades and the platform engineers who keep the portal running. A partner adds a one-time or scoped fee for planning, implementation, integration, hardening and documentation, and may add a retainer for ongoing support, upgrades and testing. DeployOpen does not publish a price list. Its engagements are usually fixed-scope, and a quote follows from the written scope. Compare the partner's quote against your internal effort and against the recurring Roadie subscription over the same period, and make sure the scope covers the upgrade and support model you will actually use.
When the numbers favor staying on Roadie
A subscription is often the cheaper option for a small organization with few or no platform engineers, or where the catalog does not need to live in a particular location and upgrades are a low priority. The honest comparison is not the subscription price against server costs. It is the subscription against the salaried time needed to run Backstage well. Backstage itself is Apache-2.0 licensed with no paid edition from the project, so the decision rests on who does the operating work, not on a license fee. Ask Roadie for its current per-developer pricing, plan minimums and what is included, then compare that figure with your own staffing cost for the same capability.
Break-even depends on three variables you can count. The first is headcount: the number of developers who will use the portal and the number of services and components it must catalog. The second is staffing: the share of one or more platform engineers' time that upgrades, authentication, database operations and incident response will consume each month. The third is customization: each custom plugin, scorecard rule or integration with an internal system adds build, test and upgrade work that persists after launch. A small team with a handful of standard integrations may find the subscription wins. A larger team with custom plugins and strict data rules may find self-hosting wins, but only after the staffing line is priced honestly. Illustrative example: a team that writes three custom plugins and upgrades monthly will carry a recurring maintenance load that a team using only built-in catalog features does not.
Before deciding, write the scope down. List the entities you expect to catalog, the identity provider you will sign in with, the custom plugins and integrations you need, the TechDocs and search requirements, and the availability and support expectations you hold the portal to. Then ask each option, including Roadie, to quote against that same written scope so the figures are comparable. Confirm with your own engineers how long a monthly Backstage upgrade takes in your environment, and whether your security team requires the high and critical vulnerability backports that the Backstage versioning policy describes to be applied on a fixed schedule. If the answers show little custom work and no platform staff to absorb upkeep, staying on Roadie is a sound outcome.
How DeployOpen scopes a fixed-price Backstage implementation
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from Roadie to Backstage, we start with a written scope that shows what you would own, what it would cost to run, and what you would still need to decide internally.
How we scope
- Inventory your current Roadie entities, integrations, plugins and scorecards before any build work starts
- Agree the written scope, deliverables and timeline with you before work begins, since engagements are fixed-scope
- Document which Roadie features need a replacement, which need a custom plugin, and which you will drop
How we build
- Deploy Backstage into your own Kubernetes or VM environment, with PostgreSQL configured for production
- Configure authentication with sign-in resolvers so every identity provider maps to the same user, with guest access disabled
- Build and test custom plugins, catalog integrations and TechDocs pipelines against your own repositories and data
How we hand over
- Deliver runbooks covering upgrade steps, backup and restore, and the monthly Backstage release cycle for your team
- Provide documentation of the architecture, configuration, access controls and catalog ownership model
- Walk your platform engineers through operation so they can run the portal without relying on DeployOpen
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the handover, if you want it
- Prepare systems, controls and evidence for compliance assessments, while independent auditors issue any reports
- Confirm a retainer scope in writing, so the recurring effort and fees are visible before you commit
