Does self-hosting Backstage cost less than Port?
Self-hosting Backstage can cost less than Port, but only if the savings outweigh what you pay to run it, and that depends on your seat count, the Port features you need and the skills already on your platform team. Backstage is an Apache-2.0 licensed framework with no paid edition from the project itself, so there is no license fee to replace. The comparison is therefore Port's subscription on one side against infrastructure, build effort and staffing on the other. No Port prices are supplied for this page, so a renewal decision should start with a written quote from Port that states the per-seat rate, the plan tier, and which features (such as SSO, RBAC, audit logs or self-hosted integrations) are included or gated to Standard or Enterprise.
Seat count changes the math in both directions. Port's cost scales with the people who use the portal, while a Backstage cost is largely fixed: hosting, a PostgreSQL database for the catalog and plugins, the people who build and maintain the portal, and the time spent on upgrades. Backstage's main release line ships monthly and its next line ships weekly, so an in-house team has to budget recurring time to keep up with releases and security backports. Ask your platform team to estimate the hours per month for upgrades, plugin maintenance and on-call support, then compare that figure with Port's quoted annual cost at your current and projected seat counts. A portal used by a small group of engineers rarely justifies a dedicated team, while a large organization with several services already running Kubernetes and identity tooling may find the fixed cost easier to absorb.
Plan features are the most common hidden variable. Port features that you would need to build yourself in Backstage, such as particular sign-in resolvers, role-based access controls, or custom self-service actions, add engineering cost even though they carry no license line item. Backstage supports 19 built-in authentication providers, but it still requires sign-in resolvers configured so every provider maps to the same identity and no guest access in production. Before deciding, list the Port capabilities your teams depend on, mark which ones are included in your current plan, and estimate the build and test effort for each one in Backstage. Also ask Port to confirm any self-hosted integration option and its license terms, because the Port integrations you run may still carry a subscription even if the portal does not.
Which cost components change when you move from Port to Backstage
This table compares each cost component on the Port side with its counterpart on a self-hosted Backstage portal, and marks whether it is one-time or recurring. Read it as a checklist for a quote request: the Backstage side has no license fee, so most of the difference sits in people, hosting and plugin upkeep. Confirm each Port line with your account team, since its plan terms and self-hosted integration terms decide which rows apply to you.
| Cost component | Port (SaaS with optional self-hosted integrations) | Self-hosted Backstage | One-time or recurring |
|---|---|---|---|
| Portal subscription or seats | Seat-based plans; confirm which features are gated to Standard and Enterprise | No license fee from the project; Apache-2.0 licensed | Port: recurring. Backstage: none |
| Hosting the portal | Included in Port's SaaS | Your Kubernetes or VM capacity, PostgreSQL, and backups | Recurring |
| Initial build | Blueprint modeling and setup in the no-code model | Engineering time for catalog model, auth, and templates | One-time, with ongoing changes |
| Data integrations | Hosted by Port with a resync interval, or self-hosted with Helm or Docker, which still needs infrastructure and operators | Catalog ingestion through providers and plugins you configure and run | Recurring |
| Migration | Export effort from Port's API or Terraform state | Mapping blueprints to catalog-info.yaml and rebuilding actions as templates | One-time, with a parallel run during cutover |
| Upgrades | Handled by Port for SaaS; self-hosted integrations need your upgrade cycle | Monthly main line or weekly next line, plus Node.js version changes | Recurring |
| Plugin maintenance | Not applicable for core features; vendor roadmap applies | Upkeep of community and custom plugins as Backstage changes | Recurring, driven by plugin count |
| Support and internal skills | Vendor support by plan; internal admins for Port configuration | Platform team staffing, or a retainer for support and upgrades | Recurring |
What moves the Backstage side of the comparison
Backstage has no license fee, so its cost is the people and infrastructure needed to run it. The drivers below decide how large that cost gets and how it compares with Port's seat-based plans. Check each one against your own catalog size, plugin list and team before you put numbers next to a Port quote.
Catalog size and team count
The number of entities, teams and owners sets how much data the catalog must ingest, refresh and search. A catalog of a few hundred services with clear owners is a small operation, while thousands of entities fed from many sources need more compute, database capacity and someone who curates catalog-info.yaml files across repositories. Port charges by seat and usage tier, so a large engineering population raises Port's bill directly, while on the Backstage side it mostly adds ingestion load and curation work. Ask Port how its plans count users and entities, and size your Backstage estimate against the same counts.
Plugin and integration count
Every plugin you add is code your team installs, configures, upgrades and debugs. Built-in features cover the Software Catalog, Software Templates and TechDocs, while Kubernetes and search plugins ship with the project, and further integrations (cloud accounts, CI systems, security scanners) are typically community or in-house plugins. Port's integrations, most built on its Ocean framework, can be hosted by Port or self-hosted with Helm or Docker, so the integration cost moves between Port's bill and your infrastructure. List each integration you need today and mark which ones already have a maintained plugin.
Node.js and release upkeep
Backstage ships a main release line monthly and a next release line weekly, and high and critical vulnerabilities are backported to releases from the last six months where feasible. Keeping up means a recurring upgrade cycle in which engineers update dependencies, resolve breaking changes and test plugins. The project supports two adjacent even-numbered Node.js releases, which sets the runtime you must patch. Budget a standing share of platform engineering time for upgrades, not a one-time setup effort. Confirm with your team how far behind the current line you are willing to run.
Availability and PostgreSQL needs
Backstage uses PostgreSQL in production and gives each backend plugin its own logical database through Knex, so the database is a core dependency. You must provision, back up, patch and monitor PostgreSQL, and choose a caching layer such as Redis, Memcache, Infinispan or in-memory caching. High availability for the portal, its database and its search index adds replicas and load balancing, which raises both infrastructure spend and on-call coverage. Compare this against Port's hosted availability and the support terms in its plan, and ask what uptime Port commits to in writing.
Identity provider setup
Backstage ships 19 built-in authentication providers, including GitHub, GitLab, Google, Azure, Okta and generic OIDC. The cost lies in configuring sign-in resolvers so every provider maps to the same identity, and in turning off guest access in production, as the authentication documentation advises. Mapping users to groups and keeping ownership data current becomes ongoing work as people join and leave teams. Port's SSO and role controls are gated by plan, so confirm which features your target tier includes and whether you need to pay for them separately.
Platform team skills
The largest cost driver is usually the platform team's existing skill set. Teams already fluent in TypeScript, Node.js, Kubernetes and React can absorb Backstage development with less ramp-up, while teams without those skills will buy outside help or hire. Port's no-code blueprint model needs less of this expertise for routine catalog changes, so the gap is most visible for custom scaffolder actions and plugins. Estimate the people you would need to assign, the hours they would spend on each area, and how that compares with the Port seats you would otherwise pay for.
How much platform team time Backstage needs to stay current
Backstage has no fixed upgrade calendar you can ignore. Its 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. Each release can touch core packages, and your installed plugins depend on those packages, so a portal that skips several cycles accumulates merge work. The policy also says high and critical severity vulnerabilities will be backported to releases from the last 6 months if feasible, which means a portal that falls further behind may need a larger jump to receive fixes at all.
Node.js is a 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, per the same policy. Your runtime image, CI build agents and local developer setup must follow that window, so a Node.js change in your base image can force a Backstage bump even when no portal feature is needed. Confirm the currently supported pair in the policy before you schedule an upgrade window.
The recurring cost is platform engineer time, not licensing. Estimate hours by listing every installed plugin, custom plugin and forked package, then noting which ones you have patched in-house or which depend on a community plugin that may lag behind core releases. Each one adds review and test time per upgrade. Confirm with your own team how many engineers can own upgrades without pulling them from self-service work, and ask any implementation partner to price upgrades as a retainer tied to a written plugin inventory.
How to build the Port and Backstage cost model with your own numbers
This sequence turns Port's seat and plan pricing and Backstage's infrastructure, build and staffing needs into one cost model you can compare over the same period.
Confirm Port seats and plan features
Start by listing every person who will need a Port seat, grouped by role: developers who only browse, platform engineers who manage blueprints, and admins. Then note which features your workflows depend on, such as self-service actions, SSO, RBAC and audit controls, and check which plan tier includes each one on Port's pricing page. Ask Port's sales team in writing to confirm seat pricing, the plan that includes each feature, and whether Ocean integrations are billed separately. The step is done when you have a seat count per role and a written list of required features mapped to plan tiers.
Count catalog entities and integrations
Count the services, APIs, resources, teams and users you expect in the catalog, and list every source system that feeds it, such as Git hosting, cloud accounts, Kubernetes clusters and incident tools. Record how often each source must resync, since Port's hosted integrations offer a configurable resync interval and self-hosted integrations run in your infrastructure. Ask Port to confirm any entity or integration limits that apply to your plan. The step is done when you have an entity count, an integration list and a resync requirement for each source.
Price cloud and database infrastructure
Price the Backstage hosting from your own cloud or data center provider, covering the Kubernetes or VM capacity for the backend and frontend, a PostgreSQL database for production, caching if you add it, storage for TechDocs builds, and backups. Keep separate lines for staging and production if you run both. Backstage uses PostgreSQL in production and SQLite only for development, so do not budget SQLite for the live portal. The step is done when each infrastructure line has a provider quote or price sheet attached and is tagged as recurring.
Scope the build and migration work
Define the Backstage work as a fixed scope before you estimate it: the catalog model, descriptor files for each entity kind, Software Templates for your most-used self-service actions, TechDocs setup, authentication with one sign-in resolver so every provider resolves to the same identity, and the cutover plan from Port. Ask any implementation partner for a written, fixed-scope proposal with deliverables and timelines, and ask your internal team to estimate the same list separately. The step is done when both estimates cover identical deliverables and the difference is explained line by line.
Assign platform team hours to upgrades and plugins
Backstage is open source under Apache-2.0, so there is no license fee, but the platform team carries the ongoing work. Backstage's main release line ships monthly and the next release line ships weekly, and high and critical vulnerabilities are backported to releases from the last six months where feasible, so plan recurring upgrade time to stay within that window. Add time for plugin maintenance, Node.js version changes (Backstage supports two adjacent even-numbered Node.js releases) and any custom plugins that replace Port integrations. The step is done when you have a monthly hour estimate per role, agreed by the team lead, for upgrades and plugin work.
Add support and separate one-time from recurring costs
Decide whether you need a support retainer for upgrades, continuous testing or on-call help, and request a quote with the scope, response expectations and what is excluded. Then build two totals on the same sheet: one-time costs such as migration and initial build, and recurring costs such as seats, infrastructure, staffing and support. Compare Port and Backstage over the same number of years, using identical assumptions for headcount growth and entity counts. The step is done when you have one-time and recurring totals for each option over the same period, with every assumption written next to its figure.
What to ask for in a Port quote and a Backstage implementation quote
Ask Port for a written quote that states seat counts by role, since the price follows from how many people edit blueprints, run self-service actions and only view the catalog. Request the plan name for each feature you depend on, because features such as advanced access controls, audit and some integrations are tied to Standard and Enterprise tiers, and a feature that appears in a sales deck may not be in the plan you are offered. Confirm the data integration hosting model in writing: whether Ocean-based integrations run hosted by Port with a resync interval you can configure, or self-hosted with Helm or Docker in your own infrastructure, and who operates each. Finally, get renewal terms, the notice period for changes, and any price cap in the contract, not in a verbal assurance. Port does not publish these terms for us to quote, so the document you receive is the only reliable source.
A Backstage quote is a different kind of document. Backstage is Apache-2.0 licensed and has no paid edition from the project, so the quote buys work, not a license. Ask for a fixed written scope that lists each plugin to be installed, configured or built, the identity integration and sign-in resolver design, the hosting assumptions (cluster, PostgreSQL, caching, and where the instance is reachable), and how the catalog data will be loaded. Require a named upgrade handover that covers the monthly main release line, the weekly next line, the Node.js versions the release supports at the time of handover, and who applies security backports. Specify what support is included after go-live and whether it is a separate retainer. DeployOpen works to a written scope and publishes no price list, so the quote follows from that scope, and we recommend comparing the two quotes line by line against the same catalog, users and integrations.
Questions buyers ask about Port and Backstage cost
Is Backstage free to license?
Yes, Backstage is open source under the Apache License 2.0, and the project itself offers no paid edition. Your cost is what you pay for infrastructure, the people who build and run the portal, and any commercial plugins or support contracts you choose to add. The license cost is zero, but the total cost of ownership is not. Ask any vendor you evaluate alongside it to separate their license fee from the engineering time, hosting and upgrade work that a self-hosted portal requires.
How long does a migration from Port to Backstage take?
The duration depends on how many blueprints, entities, integrations and self-service actions you need to rebuild, how many teams depend on them, and whether you run both portals during cutover. Catalog data maps to Backstage kinds and catalog-info.yaml files fairly directly, while custom actions and approval flows usually take the most time. No duration is set in this page's sources, so ask any implementation partner for a timeline built from a written scope, and confirm the inventory of Port objects with your own team first.
What does the work need from our staff?
Expect to need platform engineers who can write TypeScript or JavaScript plugins, operate Kubernetes or your chosen hosting target, run PostgreSQL, and manage identity integration. Backstage also needs ongoing attention to its release cadence. The main release line ships monthly and the next line ships weekly, so someone must own upgrades. Developers will still need to maintain catalog-info.yaml files in their repositories, which is a recurring habit rather than a one-time task.
Can our own team do the Backstage implementation without a partner?
A capable platform team can do it alone if it has time to learn the framework, owns the plugin roadmap and accepts the upgrade load. Many organizations choose a fixed-scope engagement for the initial build, hardening and documentation, then keep internal ownership for daily operation. The deciding factors are your team's current capacity, the number of custom plugins needed and whether you need documented evidence for an internal or external assessment. Ask any partner to show how knowledge transfer and handover are written into the scope.
How do we handle Port's self-hosted integrations during a move?
Port's documentation describes data integrations, most built on its Ocean framework, that can be hosted by Port with a configurable resync interval or self-hosted in your infrastructure with Helm or Docker. If you already run Ocean integrations in your own cluster, you can keep those data pipelines while you move the portal itself, or you can replace them with Backstage catalog providers and processors. Confirm with Port which integrations you run, which credentials they use and how they write data, before deciding which pieces to rebuild.
Does self-hosting Cortex or OpsLevel remove the subscription?
No. Cortex and OpsLevel both document self-managed or self-hosted editions that still require a vendor license. Cortex's self-managed deployment needs a JWT license key and access token from its account team, and OpsLevel's self-hosted edition requires a license file. Self-hosting changes where the software runs and who operates it, but it does not remove the commercial license. If your goal is to stop paying a vendor for licensing, Backstage is the option that carries no license fee.
What recurring costs should we budget for after go-live?
Recurring costs fall into four groups: infrastructure for the portal, its PostgreSQL database and caching, and the search and integration services you enable; platform team time for upgrades, plugin maintenance and security patches; any paid plugins, support or hosting you adopt; and developer time spent keeping catalog metadata current. Backstage's security policy says high and critical vulnerabilities are backported to releases from the last six months where feasible, but your team still has to apply those fixes. Ask any quote to itemize each of these groups separately.
How DeployOpen scopes a fixed-price Backstage implementation
DeployOpen plans, implements, hardens and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Port cost vs self-hosted Backstage evaluation, we start from a written scope that separates one-time build work from the recurring platform, plugin and support work that follows it.
How we scope
- Written scope lists the Port entities, integrations and self-service actions that move to Backstage.
- Scope names the plugins, identity providers and hosting components the portal will need.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We deploy Backstage in your infrastructure with PostgreSQL, caching and your chosen identity provider.
- We build catalog-info.yaml descriptors and Software Templates for the mapped Port blueprints and actions.
- We test sign-in resolvers, access rules and catalog imports before any team uses the portal.
How we hand over
- You receive documentation covering deployment, configuration, plugin choices and the upgrade procedure.
- We run knowledge transfer with the platform team on the components your staff will own after handover.
- Cost records list which components are one-time and which recur, so your quote comparison stays traceable.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover routine Backstage release upgrades, plugin maintenance and security patch review.
- Confirm response expectations and any service levels in the retainer agreement before you sign it.
