What does Backstage cost of ownership look like after launch?
Backstage carries no license fee. It is released under the Apache License 2.0, and the project does not offer a paid edition, so the cost of running it yourself is staffing, hosting and upkeep. Those costs keep recurring for years after the first portal goes live. Reviews of this cost usually start for one of three reasons: the annual budget cycle asks for a multi-year line item, the first portal is approaching launch and someone must be named as owner, or a renewal notice arrives for a hosted Backstage product or a competing developer portal. In each case, the comparison only works if both options cover the same work, including upgrades, on-call, security fixes and plugin maintenance. Most organizations price the in-house option with a small platform team that owns the app day to day, plus a partner for specialist work such as major upgrades, custom plugins and security review.
Start by listing the cost components and who is paid for each. The platform team is the largest recurring line, and it usually needs an owner for the application, someone accountable for catalog data and software templates, and someone who handles identity and access. Hosting covers the Node.js runtime, a PostgreSQL database, a cache, object storage for TechDocs, the CI pipeline and network ingress. Plugin upkeep and upgrades recur every month. Backstage ships a main release monthly, and the versioning policy supports two adjacent even-numbered Node.js releases, which were Node.js 22 and 24 as of Backstage 1.46.0. Confirm the current pair before you budget, because the supported runtimes change over time. Build work, initial catalog ingestion and launch are one-time costs, and they are easier to separate from the recurring lines if you ask for them as distinct items.
Several factors push the recurring cost up or down. The number of plugins with external dependencies is one of the largest drivers, because each one needs compatibility checks at every upgrade. The number of identity providers matters too, since Backstage ships with 19 built-in authentication providers and each configured provider needs a sign-in resolver and testing. Catalog size, the number of teams onboarded and the number of custom backend plugins also change the staffing level. Security work is a recurring obligation. The versioning policy says high and critical vulnerabilities will be backported to releases from the last 6 months where feasible, so your team must track releases and move within that window. Ask each option how quickly it applies those fixes and who carries the risk if a fix lands during a holiday period.
Put a hosted product or another portal and the in-house option into one three-year model with recurring costs listed separately from one-time costs. For a hosted quote, ask which pricing unit applies (seats, catalog entities, or a fixed fee), what is included in upgrades, who handles Node.js and dependency changes, where data is stored, whether plugins you need are supported, and how you export your catalog and TechDocs if you leave. For a self-run option, ask a partner for a fixed-scope estimate that names the platform roles, the hosting components and the upgrade cadence, and that states what the partner does not cover. Confirm every figure with the vendor or partner in writing, because the answer depends on your team size, your identity setup and the plugins you choose.
What a Backstage cost of ownership review includes
A fixed-scope review turns the cost of running Backstage into four documents your leadership can challenge line by line. Each deliverable answers a different question: what it costs over time, which operating model fits, which assumptions drive the numbers, and what each vendor must confirm in writing.
Multi-year cost model
A spreadsheet model that separates one-time costs, such as initial platform build and catalog data cleanup, from recurring costs, such as platform team time, hosting, database and object storage, plugin upkeep and any support agreement. The model is built from your own salary bands, cloud rates and contract terms, so you can change any input and see the effect on each year. Check that every line names who is paid for the work.
Self-run, partner-run and hosted comparison
A side-by-side view of three operating models: your team runs Backstage, a partner runs it inside your infrastructure, or a commercial hosted product runs it for you. Each option is costed on the same cost lines so the differences come from scope, not from different assumptions. Use it to see which upkeep tasks move with each model, such as upgrades, security patches and on-call coverage.
Assumptions register
A single list of every assumption behind the model, with an owner, a source and a note on how sensitive the total is to it. Typical entries include the number of plugins you expect to maintain, how often you will take monthly main releases, and which Node.js line you will run. Review the register with finance and security before any figure goes to a steering committee, because it shows which numbers are estimates and which are contracted.
Questions for vendors
A written list of questions to send to each hosted product and partner, covering what the quoted price includes, how upgrades and security backports are delivered, how plugins are supported, where your data is stored, and what happens to your catalog and templates if you leave. Answers become part of the evidence in the model. Ask each vendor to confirm terms in writing, since DeployOpen publishes no price list and every quote follows from a written scope.
Upkeep and risk log
A record of recurring maintenance work and the risks it carries, including the Backstage release cadence, backports for high and critical vulnerabilities, Node.js version changes and plugin compatibility. Each item is tied to a cost line in the model so that a missed upgrade shows up as a budget and staffing question. Review it each year to see whether the upkeep load has grown as plugins were added.
Why Backstage has no paid edition and what that changes in the comparison
Backstage is released under the Apache License 2.0 (SPDX identifier Apache-2.0), as stated in its GitHub repository, and the project itself offers no paid edition. Nothing in the open-source code is metered, locked behind a license key or sold as a tier. That changes the comparison in one basic way: every cost of running Backstage is an operating cost that your organization either pays its own staff to carry or pays a third party to carry on its behalf. There is no vendor license line to compare against a subscription, so the comparison has to be built from the work itself: the platform team, hosting, plugin upkeep, upgrades and support. Commercial hosted Backstage products and other developer portals are sold differently. They charge subscriptions or services, and the number on the order form tells you little until you read what sits behind it. Ask each vendor to put the following in writing: where the hosted instance runs and in which regions, which plugins are covered and whether custom plugins are supported, who performs upgrades and how often, who owns the catalog data and the TechDocs output, and what happens to both at exit. Two offers with similar prices can differ sharply on any one of these points.
Hosting location is the first point to confirm, because it decides where your catalog, credentials and documentation live and which of your data-handling rules apply. Plugin coverage is the second. Backstage ships with core features such as the Software Catalog, Software Templates and TechDocs, plus Kubernetes and search plugins, but most organizations also depend on integrations for their source control, CI, cloud and incident tooling. Confirm whether a vendor's plugin list matches your integrations, and whether a plugin you need and the vendor does not support can be added by your own team without breaking the contract.
Upgrade responsibility is where the two models diverge most. Backstage publishes a monthly main release and weekly next releases, and high and critical vulnerabilities are backported to releases from the last six months where feasible. A hosted provider may apply these on its own schedule, while a self-run deployment depends on your team following the same cadence. Ask the vendor which Backstage version it runs, how quickly it applies security fixes, whether it covers Node.js version changes, and whether a breaking upgrade is included in the subscription or billed as a separate project.
Data ownership and exit terms decide what you can take with you. Confirm that you own the catalog entities, templates, TechDocs source and any configuration you supplied, and that you can export them in open formats. Ask how long data is retained after termination, how credentials and integration tokens are revoked, and whether the vendor will help move the portal to a self-hosted instance. For a self-run Backstage, the equivalent question is whether your own runbooks and backups would let you rebuild the portal without the original team. Write these answers into the comparison as line items with owners, not as footnotes.
Which factors raise or lower the Backstage running cost
This table lists the factors that move the running cost of a self-hosted Backstage portal, why each one matters, how to keep it manageable, and what to request in a quote. Use it to see which decisions in your scope will change the platform team's effort and your hosting bill. The main takeaway is that catalog size, plugin count and the number of Backstage apps usually shape ongoing cost more than the framework itself, which is free under Apache-2.0.
| Driver | Why it moves cost | How to keep it down | Ask a partner or vendor for |
|---|---|---|---|
| Catalog entities and users | More entities mean larger catalog processing, more ingestion work and more ownership data to keep accurate. User and group volume drives sign-in and group sync load. | Model only components, systems, APIs and owners that teams actually use. Prefer provider-based ingestion over hand-maintained files where data already lives in an identity or source system. | Estimated entity and user counts, the ingestion sources assumed, and the effort to maintain ownership data after go-live. |
| Number of plugins, built-in and custom | Each plugin adds configuration, upgrade work and possible compatibility breaks. Custom plugins need their own tests and maintenance owners. | Start with core features and a short list of integrations. Retire unused plugins and avoid custom plugins where a maintained community plugin fits. | A plugin inventory with build versus adopt decisions, and the upgrade effort assumed for each custom plugin. |
| Identity provider and group sync complexity | Sign-in resolvers, multiple providers and nested group mappings add design, testing and troubleshooting time. Mismatched identities create access errors. | Use one primary identity provider, one resolver that maps every provider to the same identity, and no guest access in production. | Which identity providers are in scope, how groups are mapped to owners, and how sign-in testing and permission rules are covered. |
| Number of environments | Each environment needs its own deployment, database, secrets, configuration and upgrade rollout. Non-production copies consume hosting and effort. | Keep a single non-production environment for testing upgrades and plugin changes. Automate deployments so new environments are cheap to create. | The environments included in the quote, who maintains each one and how configuration is promoted between them. |
| TechDocs volume | Documentation sites are built and stored, so repository count, page count and build frequency increase compute and storage use. | Publish docs from a defined set of repositories, set build triggers deliberately and store generated sites in object storage. | Expected number of documented repositories, the build pipeline design, and the storage and retention approach assumed. |
| Compliance evidence needs | Audit trails, access reviews, change records and retained logs need extra storage, reporting and review effort. The evidence design depends on the controls each assessor expects. | Agree the evidence list before build starts. Reuse logs and access records from existing platforms instead of creating separate ones. | The evidence artifacts produced, where they are stored, and who performs the periodic review. Confirm the assessor's expectations with them directly. |
| Kubernetes and search scope | Kubernetes and search plugins add cluster access, indexing jobs and additional configuration. Wider cluster scope adds permissions review and monitoring. | Limit Kubernetes views to clusters and namespaces that owners need. Index only the content that search users require. | Which clusters and search sources are in scope, the access model used and the monitoring included after handover. |
| Number of Backstage apps | Each separate app repeats hosting, upgrades, plugin management and security reviews. Shared code reduces that repetition but still needs ownership. | Run one app with shared plugins where possible. Split apps only for clear organizational or security boundaries. | The number of apps in scope, which code is shared, and how upgrades are applied across apps in one release cycle. |
| Database, cache and authentication choices | PostgreSQL, the cache and the authentication setup come from the architecture and authentication documentation. Their sizing, backups and failover determine hosting and recovery effort. | Follow the documented production database and cache options, and plan backups and recovery testing from the start. | The PostgreSQL, cache and authentication design, including backup, failover and sizing assumptions, stated in writing. |
How the release cadence sets the upgrade budget
Budget for upgrades as a standing line item, because the release cadence sets how often the work arrives. Backstage publishes a main release line monthly, on the Tuesday before the third Wednesday of each month, and a next release line weekly on Tuesdays. A team that follows the main line plans one upgrade cycle a month. A team that follows the next line absorbs a weekly stream of changes. Confirm with your platform team which line you will track, because that choice determines how many review cycles your budget must cover each year.
Security fixes add a deadline. The versioning policy says high and critical severity vulnerabilities will always be backported to releases from the last 6 months where feasible, and other security fixes may be backported. Backporting is not guaranteed for every fix, and the policy's wording is conditional, so you cannot assume a fix will reach an older release. Keep your deployments inside that six-month window. Record which release each environment runs and when it was last moved, so the window can be checked against actual dates. Reserve capacity for an out-of-cycle upgrade, since a critical advisory can arrive between scheduled windows.
Node.js support is the second moving part. Backstage supports exactly two adjacent even-numbered Node.js releases, and as of Backstage 1.46.0 these are Node.js 22 and 24, according to the versioning policy. Your runtime image, CI build agents and any base images must use a supported version. A Node.js change can land in the same window as a Backstage upgrade, so include the runtime work in the same plan. Confirm the supported pair for the exact release you run, because the supported pair moves as new Node.js releases are adopted.
The upgrade mechanism is yarn backstage-cli versions:bump, which moves all @backstage packages together, combined with the Backstage Upgrade Helper, which shows the template changes between versions that your repository may need. The tool handles the version changes. The recurring time goes to reading template diffs, adjusting custom plugins and integrations, running tests and checking the portal in staging. That review work is the main ongoing cost, and it grows with the number of plugins and custom code you carry. Ask any quote to state how many upgrade cycles a year it covers and who performs each review.
Which costs recur after go-live and who pays for each
This table lists the costs that continue after a Backstage portal goes live, who usually carries each one, and what makes it grow. Read the recurring column first to separate fixed run costs from upkeep that follows the release calendar. The main takeaway is that most recurring cost sits in people, because the Apache-2.0 framework carries no license fee but its upgrades, plugins and security fixes never stop.
| Cost line | Recurring or one-time | Who usually pays | What drives it up and what to ask for |
|---|---|---|---|
| Platform team staffing | Recurring | Your organization, from the platform or engineering budget | Number of plugins, teams served and release frequency. Ask for the named roles and hours a partner would cover. |
| Hosting for backend and frontend | Recurring | Your organization, through your cloud or data center account | Replica count, traffic from catalog and search, and environments. Ask for the sizing assumptions behind any quote. |
| PostgreSQL and backups | Recurring | Your organization, through managed database or infrastructure spend | One logical database per backend plugin, retention length and restore testing. Ask how backups and restore drills are priced. |
| Cache and TechDocs object storage | Recurring | Your organization, through cloud or on-premises infrastructure | Cache choice (Redis, Memcache, Infinispan or in-memory), documentation volume and retention. Ask which cache the design assumes. |
| Identity provider licensing | Recurring, if the provider is paid | Your organization, through the identity provider contract | Seat count and whether groups are ingested. Ask the provider and the integration partner which licenses apply. |
| Monthly and weekly upgrades | Recurring | Your platform team or a support partner | Monthly main releases, weekly next-line releases and template changes. Ask for the upgrade cadence and who applies it. |
| Plugin maintenance and compatibility fixes | Recurring | Your platform team or a support partner, for custom and third-party plugins | Number of custom plugins and upstream API changes. Ask who owns each plugin and how breaking changes are tested. |
| Security response and on-call | Recurring | Your platform team or on-call rota, with support partner help if contracted | High and critical fixes backported to releases from the last 6 months, and on-call hours. Ask for the response process and escalation path. |
| Partner retainer or subscription | Recurring, optional | Your organization, under a support or retainer agreement | Scope of upgrades, plugin work and testing included. Ask for a written list of what the retainer covers and excludes. |
How the cost model is built, step by step
The sequence turns today's portal demand, plugins, staffing and hosting into a written, multi-year cost model that you can compare against commercial and alternative options using your own contract figures.
Confirm portal demand and identity sources
We review how developers would use a portal today and in the planned scope: which teams, how many services and owners, which catalog sources exist (repositories, service registries, wikis), and which identity provider and groups would sign users in. Your engineering leads and identity team take part, and the output is a short demand and identity brief that states the assumptions behind every later line of the model. The step is done when you have confirmed that brief in writing.
Inventory plugins and integrations
We list each built-in feature you plan to use, such as the Software Catalog, Software Templates, TechDocs, Kubernetes and search, along with every community or custom plugin and each external system it connects to. For each item we record the owner, the upgrade exposure and whether it needs custom code or maintenance after launch. The output is a plugin register that shows which parts of the cost are recurring upkeep and which are one-time build work. The step closes when your platform owners have reviewed and accepted the register.
Model the staffing and skills
We map the roles needed to run the portal after launch, such as platform engineers for upgrades and plugin maintenance, a security owner for authentication and permissions, and a product owner for the catalog and templates. For each role we note whether it is filled internally, by a partner under retainer, or shared with existing teams, and which skills are missing. The output is a staffing and skills table with the recurring effort it implies. The step closes when the table is reconciled with your current headcount plans.
Model hosting and dependencies
We document where the portal runs, including Kubernetes capacity, PostgreSQL, the cache, object storage for TechDocs, CI pipelines, and the Node.js versions in use. Backstage supports exactly two adjacent even-numbered Node.js releases, so we record which runtime you will standardize on and how that choice affects upgrade timing. The output is a hosting and dependency sheet with each item marked as one-time or recurring and tied to a cost source you will confirm with your cloud or infrastructure team. The step closes when those owners have confirmed the figures.
Compare options against your contract figures
We build the comparison between running Apache-2.0 Backstage yourself, a commercial hosted Backstage product, and another developer portal, using the license and support terms you actually hold or are quoting. Commercial figures stay in your hands, and we do not estimate any vendor's prices. For each option we show the multi-year totals, the assumptions that move them most, and the points where a quote is still missing. The output is a side-by-side model in which every number traces to a named source. The step closes when you have verified each input against your procurement records.
Deliver the written model and assumptions
We hand over the cost model as a document and a working spreadsheet, with every assumption, its source, the owner who confirmed it, and the sensitivity to each driver. We also list what to ask a vendor or partner for in a quote, and which items would change the result if they moved. The handover includes a walkthrough with the people who will maintain the model. The step is done when your finance, platform and security leads sign off that the model matches the agreed scope.
How the cost picture changes by starting point
Teams leaving a commercial developer portal often expect the license line to disappear. Backstage has no paid edition from the project itself, so the subscription is replaced by staffing, hosting and plugin work. Migration is often the largest one-time line, because catalog data, templates and access rules must be rebuilt in the open-source model.
- Subscription fees: Removed from the project side. Any hosted Backstage vendor fee must be compared separately.
- Platform team staffing: Grows, because someone must own upgrades, plugins and on-call tasks that the vendor handled.
- One-time migration: Rises with the number of catalog entities, templates and integrations to recreate.
- Parallel running: Adds cost while both portals operate during cutover.
- Feature parity: Identify features the commercial product provides out of the box that you would now build or select as plugins.
Confirm which commercial features your teams use daily, the contract end date and whether you can export catalog data before you compare totals.
The main release line ships monthly and the next line ships weekly, so an app several versions behind carries a catch-up cost before any new work begins. Security coverage is the key constraint. High and critical fixes are backported to releases from the last six months where feasible, so an older version may fall outside that window and need a move to a newer line to receive fixes.
- Catch-up upgrade: One-time effort grows with the number of versions skipped and the number of custom plugins touched by template changes.
- Node.js alignment: Check your runtime against the two supported adjacent even-numbered Node.js releases in the versioning policy. A runtime change can ripple into plugins.
- Upgrade tooling: The Upgrade Helper shows template changes between versions. It reduces investigation time, though testing time stays the same.
- Recurring cadence: Once current, monthly upgrades become a recurring line that a retainer or internal rotation must cover.
- Security exposure: The longer the gap, the more likely a fix requires a larger jump in version.
Confirm your current version, the list of plugins pinned to older packages and whether any support agreement covers catch-up work.
Teams already operating Kubernetes can reuse clusters, ingress, secrets management and observability. This lowers hosting cost but moves some effort into integration. PostgreSQL is the production database for Backstage, and each backend plugin uses its own logical database, so the data layer needs planning even when cluster capacity exists.
- Hosting: Often shrinks because cluster capacity already exists, but Backstage still adds backend replicas, a database and object storage for TechDocs.
- Database operations: Choose between a managed PostgreSQL service and a self-run instance. Count the logical databases in capacity and backup planning.
- Identity: Backstage ships 19 built-in authentication providers. Reusing an existing identity provider keeps identity cost low, but sign-in resolvers must map every provider to the same identity.
- Tooling integration: Custom scaffolder actions and catalog providers that connect your CI, GitOps and service registry add build effort.
- Ownership: Existing platform engineers may absorb operations, which shifts cost from new hires to time allocation.
Confirm which existing platform tools are in scope for integration, who owns the cluster and database, and whether your tooling's release cycle conflicts with the monthly Backstage line.
In an air-gapped or restricted network, hosted Backstage options may not be permitted, so the whole deployment runs inside your boundary. That includes packages, container images, the Node.js runtime and TechDocs builds. Costs shift toward internal mirrors, offline dependency management and slower movement of security fixes into production.
- Hosted fees: Likely not applicable, but confirm whether any vendor product is permitted at all.
- Dependency mirroring: Adds one-time effort to mirror npm packages, container images and the Node.js runtime, then recurring effort to refresh them with each release.
- Upgrade logistics: Each monthly release must be imported, tested and approved before it reaches production, which can lengthen the path to security fixes.
- TechDocs and search: Documentation builds and storage must work offline. Check that every external service a plugin calls is reachable or replaced.
- Evidence and approvals: Change records for each upgrade are a recurring cost for security and compliance teams.
Confirm with your security team which hosted options are prohibited, whether the package and image mirrors are approved and how emergency security upgrades will be authorized.
Where Backstage cost estimates usually go wrong
Most Backstage cost estimates undercount recurring work, not the initial build. The cards below name the errors that repeatedly shift cost into later years and the control that keeps each one visible in a quote or internal budget.
Budgeting only for go-live
The estimate covers the first build and launch, then stops. Backstage is an Apache-2.0 framework with no paid edition from the project, so every release, dependency change and migration falls on your team or your partner. The main release line ships monthly, so the budget should include a recurring upgrade cycle from the first year. Ask for an annual upgrade effort line, separate from the build quote.
One engineer for plugin upkeep
Estimates often assign plugin maintenance to a single platform engineer. Each plugin has its own dependencies, configuration and compatibility with the core @backstage packages, so upgrades to one plugin can block others. Count the plugins you plan to run, identify who owns each one, and confirm that cover exists for vacations and departures before accepting a headcount figure.
Missing the security response window
The versioning policy says high and critical vulnerabilities are backported to releases from the last six months where feasible, but only if you are running a release in that window. An estimate that excludes time for urgent security upgrades, Node.js runtime changes and re-testing after a patch underprices the operating model. Define who responds, how fast, and what testing happens before production rollout.
Underestimating catalog data work
The software catalog is only as useful as its ownership and metadata. Teams often budget for installing the catalog but not for writing catalog-info.yaml files, correcting owners, retiring stale components and reviewing entries after reorganizations. This work recurs as services change. Ask for an estimate of catalog data effort per team, and who in each team keeps those files current.
Treating hosted price pages as complete
Commercial hosted Backstage products publish subscription prices, but those figures rarely include your plugin work, custom templates, identity integration or the platform team that runs the portal. Compare total cost of ownership across options by listing every component you would still own under each model. Request written scope from any vendor showing exactly which of those components the subscription covers.
Ignoring guest access and identity sync
The authentication guidance advises against guest access in production and recommends sign-in resolvers that map every provider to the same identity. If guest access is left on, or user and group ingestion is unmanaged, support tickets about access, duplicate accounts and missing group membership arrive later and consume engineering time. Budget for resolver configuration, group ingestion and removal of guest access before launch.
What the reader needs to provide for an accurate model
An accurate cost model depends on inputs that only your organization can supply. Start by naming the Backstage version you run today or plan to adopt, because that choice sets the upgrade workload and the Node.js versions your build pipeline must support. The versioning policy describes a main release line shipped monthly and a next line shipped weekly, so confirm which line your team intends to follow. Pair that with a plugin inventory listing every community and custom plugin, its owner, and whether it has been upgraded in the last release cycle. Plugin count is one of the strongest drivers of recurring effort, and a model built without this list will understate upkeep.
Next, gather identity and ownership data. Document which of the 19 built-in authentication providers you will use, or confirm your identity provider is covered by generic OIDC. Export the group structure you want reflected in the catalog, including how many users and teams need ownership records, and who maintains that data in your directory. Sign-in resolver design, guest access removal and catalog ingestion all shift labor between the platform team and the identity team, so the model should show who pays for each step. Also list the hosting environment: cloud accounts, Kubernetes clusters, PostgreSQL service, object storage for TechDocs, and cache, together with the pricing terms your finance team uses for each.
Staffing and finance inputs are the next layer. Provide the planned platform team size, the roles you expect to fill (for example, a platform engineer, a frontend developer, and a share of a security engineer), and the salary bands your HR function uses, including loaded costs such as benefits and taxes. Ask finance to confirm the discount rate or internal hurdle rate for multi-year comparisons. Name a single owner for the platform decision, a separate owner for identity integration, and a budget owner who can approve a multi-year commitment. Without named owners, the model will assume costs that no one has agreed to carry.
Existing contracts are the most common gap we see. Teams often know the list price of a hosted or portal vendor but not the renewal date, the minimum seat or user commitment, overage rules, price escalation clauses, support tier, data residency terms, or the notice period for non-renewal. Gather each contract and the terms that govern exit, data export and termination. Include any internal support agreements, and any vendor-specific upgrade or plugin fees. If a contract is unavailable, record that as an open assumption rather than filling the gap with an estimate, because the difference often decides the comparison.
Finally, record compliance requirements that affect hosting and support. List the frameworks your assessors will examine, the audit evidence you must retain, the data classes stored in the catalog and TechDocs, and whether logs must stay in specific regions. Each requirement can add controls such as access reviews, backup testing or vulnerability response timelines, and each control has a cost. Confirm with your compliance lead which requirements apply to a self-hosted portal and which the hosted vendor already covers, and ask that vendor for its current compliance documentation in writing.
Questions buyers ask before comparing costs
Does Backstage have a paid edition from the project itself?
No. The Backstage project does not offer a paid edition. The framework is released under the Apache License 2.0 (SPDX: Apache-2.0), according to its GitHub repository, so you can use, modify and run it in your own environment without a license fee to the project. Your costs come from running it: the platform team that owns the portal, hosting, PostgreSQL, plugin selection and upkeep, upgrades, and any support contract you choose. Commercial hosted Backstage products and other developer portals are priced by their vendors, so compare their quotes line by line against the same recurring costs you would carry yourself. Confirm any vendor-specific terms in writing before you compare.
What drives the cost of running Backstage the most?
The largest driver is the platform team: how many engineers you need, their skills, and how much of their time goes to upkeep compared with new features. Plugin count matters next, because each plugin adds versions to track and integrations to test. Upgrade cadence is also significant. The Backstage release and versioning policy ships a main release line monthly, and high and critical security fixes are backported to releases from the last six months where feasible. Hosting, database operations, Node.js version changes and the number of teams onboarded to templates and the catalog also move the total. Ask each vendor or partner to show how these drivers are assumed in their numbers.
How long does a Backstage cost review take?
A cost review takes as long as its written scope requires. DeployOpen does not publish a fixed duration because the work depends on the number of plugins in use, the state of your catalog data, how many identity providers and teams are involved, and how much of your current hosting and staffing you need us to examine. Most engagements are fixed-scope, which means the scope, deliverables and timeline are agreed in writing before work starts. When you request a review, ask for the timeline in the proposal, the inputs you must provide, and the date by which you need to provide them.
Can our team build a Backstage cost model ourselves?
Yes. A team can build the model using the drivers and recurring lines described on this page. Start by separating one-time costs, such as the initial build, catalog modeling, identity integration and first templates, from recurring costs, such as staffing, hosting, database backups, upgrades, plugin maintenance and any support agreement. Then assign each line an owner and a basis for the estimate, and model at least two scenarios for plugin growth and upgrade effort. Check your assumptions against the Backstage versioning policy and upgrade guidance. An outside review can test the model, but your team can produce a working version.
What does a Backstage cost review need from our team?
The review needs people and access, not only documents. Expect to provide read access to the current hosting and cloud accounts, the identity provider configuration and admin contacts, a list of the data sources you plan to ingest into the catalog, and a named owner for each product or platform area. You will also need a decision-maker who can approve scope, plus time from platform and security staff to answer questions about existing tooling. If you already run a Backstage instance, provide its version, plugin list and upgrade history. Missing inputs usually lengthen the review, so confirm the list in the written scope.
Can a partner replace our Backstage platform team?
Only in part. A partner can cover specific work under a written scope, such as an initial build, a migration, an upgrade, a security review or a set of custom plugins. Ownership of the platform stays with your organization. Your team still sets priorities, approves access, decides when to accept upgrades, and runs the portal after handover. Plan for an internal owner from the start, and define in the scope who maintains each plugin once the engagement ends. Ongoing support and upgrades are available as retainers if you want continuity between projects.
What recurring costs come after a Backstage launch?
After launch, recurring costs include the staff who run the portal, hosting for the backend and frontend, PostgreSQL with backups, shared caching if you use it, and object storage for TechDocs if you publish documentation there. Upgrades are recurring work: the main release line ships monthly, and you must keep the app on supported Node.js releases, which the versioning policy lists as two adjacent even-numbered versions. Plugin updates, security patches and template maintenance also recur. One-time costs are the initial build, catalog design, identity integration, first templates and any custom plugins. Ask for the recurring items to be listed separately in every quote.
How do Backstage costs compare with other developer portals?
Compare them on the same lines, not on the headline license or subscription price alone. Backstage has no license fee from the project, so its cost sits in staffing, hosting, plugin upkeep, upgrades and support. Commercial developer portals and hosted Backstage products usually bundle some of these items, so ask each vendor which lines are included, which are extra, and how upgrades and security fixes are delivered. Also compare the migration effort from existing tools, the number of integrations you need, and the contract terms for changing providers later. Confirm every figure in writing before using it in a decision.
How DeployOpen scopes and hands over a cost of ownership review
DeployOpen builds the cost of ownership picture for Backstage from your own environment, not from a generic template. We scope the review in writing, model the platform team, hosting, plugin upkeep and support against your choices, and hand over a comparison you can take to finance and leadership.
How we scope
- Written scope agreed before work starts, normally as a fixed-scope engagement with defined deliverables.
- Inventory of the Backstage features you plan to use, such as the Software Catalog, Software Templates, TechDocs and Kubernetes.
- Agreed list of comparison options: self-hosted Apache-2.0 Backstage, commercial hosted Backstage products and other developer portals.
How we build
- Multi-year model with separate lines for platform team effort, hosting, plugin maintenance and external support.
- Hosting assumptions tied to your cloud accounts or data centers, including PostgreSQL, caching and TechDocs storage.
- Upgrade effort estimated against the monthly main release line and the weekly next release line in the versioning policy.
How we hand over
- Written cost model with assumptions, one-time costs and recurring costs listed separately so each can be challenged.
- Sensitivity notes showing which inputs move the total most, such as team size, plugin count and upgrade cadence.
- Walkthrough with your finance, platform and security leads, plus the model in a format your team can update.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers if you want DeployOpen to carry part of the run cost.
- Refresh of the model when a new Backstage release line, Node.js support window or plugin change affects your assumptions.
- Confirm current release status, support windows and vendor terms directly with the vendors before the figures are final.
