Port vs Backstage: when each option fits
If you are facing a Port renewal, a data residency requirement, or a wish to own the portal code, the short answer is this: Port fits teams that want a hosted, no-code blueprint model with vendor-run upkeep, while a self-hosted Backstage portal fits teams that want an open-source framework they control end to end and can staff. Port's portal runs in Port's SaaS, but its data integrations, most built on its Ocean framework, can be self-hosted in your own infrastructure with Helm or Docker, according to Port's documentation. That split matters for isolated networks: a self-hosted integration does not make the portal itself run inside your network, so an air-gapped requirement needs a different answer.
Port fits when a small number of people must model services quickly without writing code, and when a vendor-operated portal and its upgrades are acceptable. Backstage fits when you need the catalog schema, Software Templates, TechDocs and plugins to follow your own architecture, when the portal must run fully on internal Git, identity and registries, and when a platform team can own its build, upgrades and plugin maintenance. Backstage is Apache-2.0 licensed with no paid edition from the project itself, so its license cost is zero, but the engineering effort it demands is real and recurring.
The decision turns on four questions: where catalog data may reside, which identity provider and sign-in resolvers you must support, which plugins your tooling needs and whether they already exist, and whether your organization can staff a platform team to run Backstage. Before you compare quotes, confirm in writing with Port which parts of your deployment would run in its SaaS, and confirm with your security team which of those paths your residency policy allows.
Port vs Backstage: which scenario fits which option
This table maps common buyer scenarios to the option that fits best and the condition under which the other option would win. Read each row against your team's engineering capacity, data residency rules and existing investments. Port's no-code blueprints are a clear advantage for small teams without platform engineers, while Backstage suits organizations that want to own the portal code, plugins and data.
| Scenario | Better fit | Why | The other option wins when |
|---|---|---|---|
| Small team needs a catalog within weeks | Port | Blueprints and a hosted interface avoid building and hosting a portal application. | Backstage wins if engineers already run Node and React and can staff the build. |
| Regulated firm with data residency rules | Backstage | The portal, catalog and PostgreSQL database run in your own cloud or data center. | Port wins if its hosting region and contract terms meet your residency rules. Confirm in writing. |
| Existing Backstage plugin investment | Backstage | Existing plugins, catalog-info.yaml files and Software Templates carry over directly. | Port wins if those plugins are being retired and the team prefers no-code blueprint modeling. |
| No dedicated platform engineers | Port | The vendor operates the hosted service, so no one patches or upgrades the portal. | Backstage fits only with a named owner for upgrades, plugin maintenance and auth configuration. |
| Team needs offline operation | Backstage | Internal Git, identity provider and image registry can all sit inside an isolated network. | Port wins only if it confirms an offline option for your deployment. Ask Port directly. |
| Strict SSO and role-based access by plan | Backstage | Nineteen built-in authentication providers, with sign-in resolvers mapping each to one identity. | Port wins if its plan includes the SSO and access controls you need. Confirm plan features first. |
| Self-service actions that need approvals | Port | No-code action setup covers common developer requests without writing templates. | Backstage wins when approvals and execution must run in your own pipelines, often with custom plugins. |
How the data models differ: blueprints versus descriptor files
Port models software through blueprints that it defines inside its platform. A team lead or platform engineer can add a property, change a relation or adjust a schema in the Port interface without shipping a code change, and the catalog updates to match. Backstage takes the opposite approach. Each entity is described in a YAML descriptor, conventionally named catalog-info.yaml, that lives in the repository it describes. The kinds are fixed by the framework: Component, API, Resource, System, Domain, Group, User, Template and Location. Your engineers work with these kinds directly, and the model you get on day one is the model the framework defines.
The trade-off is real but it cuts both ways. Port lets you reshape the model quickly, which suits a team still deciding what a service is. Backstage asks for more discipline up front, but every change to an entity is a commit that goes through review, can be rolled back and is visible in Git history. API entities can carry OpenAPI, AsyncAPI, GraphQL or gRPC definitions alongside ownership and lifecycle metadata, so the contract and the owner sit in one record. Confirm which of these you need on day one, because a model that changes weekly is harder to version in files than one that changes quarterly.
Plan for the moment a custom model does not fit the built-in kinds. In Backstage this usually means a new kind or a custom entity processor, which is a code change and a plugin to build, test and maintain, not a settings toggle. Check how each of your Port blueprints maps to the eight Backstage kinds before you commit to a migration: export a sample of blueprints and list every property, relation and computed value, then decide whether it becomes a field in an existing kind, an annotation, or a custom entity. Ask Port to confirm how its current blueprint model maps to your entities, and document any blueprint that has no clean equivalent as a known gap.
Port vs Backstage side by side on capabilities
This table compares Port's hosted, blueprint-driven portal with Backstage's open-source framework across catalog, actions, docs, search, authentication, licensing and hosting. Read each row as a question to answer for your own organization, and treat Port plan entitlements as items to confirm with Port before deciding. The main takeaway is that Backstage trades no-code setup for code and platform engineering ownership.
| Capability | Port | Backstage |
|---|---|---|
| Catalog and data model | Blueprints define entity types and properties in the portal, configured through the UI or API | Entities are YAML descriptors, conventionally catalog-info.yaml, with kinds such as Component, API, Resource, System, Domain, Group, User and Template |
| Self-service actions | Self-service actions let developers request environments, services and changes from the portal | Software Templates with scaffolder actions, which teams write and maintain as code |
| API and spec documentation | Confirm current support for importing API definitions with Port's documentation | API entities can carry OpenAPI, AsyncAPI, GraphQL or gRPC definitions |
| Documentation | Confirm the current documentation features in Port's docs for your use case | TechDocs builds MkDocs sites from Markdown kept next to the code, with MkDocs plugins supported |
| Plugins and integrations | Integrations, mostly built on the Ocean framework, can be hosted by Port or self-hosted with Helm or Docker | Plugin ecosystem; Kubernetes and search are listed as core plugins, and your team builds or maintains any others |
| Search | Confirm search scope and behavior with Port for your catalog size | Search is a core plugin; the search backend and index are operated by your team |
| Authentication and SSO | Confirm SSO options for your plan with Port before deciding | 19 built-in authentication providers, including GitHub, GitLab, Google, Azure, Okta, Auth0 and generic OIDC |
| RBAC | Confirm role-based access controls available on your plan with Port | Permissions are configured by your team; sign-in resolvers should map every provider to one identity |
| Licensing | Commercial SaaS subscription | Apache-2.0 with no paid edition from the project itself; costs are infrastructure and staff |
| Governance | Operated by Port as a vendor | CNCF accepted September 8, 2020; Incubating since March 15, 2022 |
| Hosting | Portal hosted by Port; some integrations can be self-hosted | Runs in your infrastructure, with PostgreSQL in production and SQLite for development |
| Team required | Platform team configures blueprints and actions in the vendor product | Engineers who build, upgrade and maintain a TypeScript-based portal and its plugins |
Who controls the data, hosting and identity
Port and Backstage differ most in where the catalog lives, who operates the portal, and how people sign in. These four to six decision areas show what each choice means for data residency, air-gapped operation, audit evidence and upgrades, and what your team must verify before committing.
Where catalog data lives
Port stores blueprints, entities and scorecards in its hosted service, so your catalog sits in Port's infrastructure under Port's terms. Backstage keeps its catalog in your own PostgreSQL database, with entity definitions usually stored as catalog-info.yaml files in your Git repositories. Check where Port hosts your tenant and whether your data residency rules accept that location, and decide which team owns the Git repositories that would become the source of truth.
Self-hosted Port integrations
Port lets you run its data integrations, most built on the Ocean framework, inside your own infrastructure with Helm or Docker, while the portal itself stays in Port's SaaS. This keeps source system credentials and raw data inside your network but does not move the portal. Ask Port which integrations support self-hosting, and confirm that the portal still needs outbound connectivity to Port's service.
Sign-in and identity resolvers
Backstage supports 19 built-in authentication providers, including GitHub, GitLab, Google, Azure, Okta and generic OIDC, so you choose the identity source. Configure sign-in resolvers so every provider resolves a person to one identity, which prevents duplicate user records and inconsistent ownership. Do not offer guest access in production, and confirm how your identity provider maps groups to Backstage roles before go-live.
Air-gap operation
A Backstage portal can run on a network with no internet access if its container images, npm packages, Git remotes, identity provider and TechDocs build tooling all come from internal mirrors. Port's portal runs in Port's SaaS, so it cannot operate inside an isolated network, and only its integrations can be self-hosted. Ask each vendor to confirm offline requirements in writing, and test a build from a disconnected environment before relying on it.
Compliance evidence you must gather
Whichever option you choose, your team must collect the evidence an assessor asks for: access reviews, sign-in configuration, change records, backup restore tests and vendor contracts. With Backstage, you produce this evidence yourselves from your own logs and repositories. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations.
Who holds the keys to upgrades
Port upgrades its hosted service on its own schedule, and self-hosted integrations follow Port's release process. Backstage ships a main release line monthly and a next line weekly, and you decide when to adopt each version, including backported security fixes. Plan a named owner for upgrades, tests against your plugins, and a rollback path. Ask Port what it will commit to for notice periods and deprecations.
Self-service actions and plugins: what carries over
In Port, developers request environments, services or changes from actions defined on blueprints in the portal UI. A request is a form the developer fills in, and Port's hosted control plane records the run, applies the action's configured permissions and passes the work to the execution target the action points at, typically a CI pipeline, a webhook or an external API. Approvals are configured in the portal, so the approval step and its audit record live in Port's SaaS. Execution usually happens in your own pipelines and infrastructure, not inside Port.
- Request path: developers use a form generated from the action's input schema on a blueprint.
- Approvals: approval steps are defined in Port and tied to the action's permissions.
- Execution: the action triggers a pipeline or webhook you already operate.
- Custom work: new integrations beyond the supported destinations usually mean webhook or API glue code that your team owns.
- Plan gating: confirm with Port which approval and RBAC features your plan includes before you map workflows.
Check which of your current actions depend on Port-side approvals, because those steps must be rebuilt in your own pipeline or portal logic when you move.
In Backstage, a Software Template is a YAML definition that the scaffolder executes. Developers pick a template in the portal, fill in parameters, and the scaffolder runs a sequence of steps such as creating a repository, rendering files from a skeleton, and registering the new component in the Software Catalog. Scaffolder actions are the reusable steps. Approvals and execution happen where you host Backstage: approvals are usually handled by the pipeline, a pull request review or a custom plugin, and the scaffolder runs on your Backstage backend.
- Request path: a template is a catalog entity of kind Template, so it appears in the portal like any other entity.
- Approvals: Backstage has no built-in multi-step approval workflow, so teams add it through pull request gates or a custom plugin.
- Execution: the scaffolder runs on your backend and calls the Git, cloud and registry APIs your templates use.
- Plugins: community and in-house plugins add cards, pages and actions, and each one needs an owner to upgrade it.
- Cost owner: your platform team builds, tests and maintains templates and plugins, and that effort is not billed by any vendor.
Confirm which approval and audit requirements your organization must meet, then decide whether pipelines or custom plugins will enforce them.
Backstage's core features are the Software Catalog, Software Templates and TechDocs, and its architecture also includes Kubernetes and search plugins. Beyond those, the plugin ecosystem covers many integrations, but each plugin is code you adopt, configure and keep working through Backstage upgrades. Backstage releases ship monthly on its main line and weekly on the next line, and the project backports high and critical vulnerability fixes to releases from the last 6 months where feasible, so your team needs a regular upgrade cadence.
- Built-in core: the Software Catalog, Software Templates and TechDocs ship with the framework.
- Community plugins: check maintenance activity, license and compatibility with your Backstage version before adoption.
- Upgrades: plan a recurring upgrade cycle, since plugin APIs can change between releases.
- Port equivalents: integrations that Port provides through hosted connectors often map to plugins or scheduled ingestion jobs you build.
- Ownership: every custom plugin needs a named maintainer, tests and a deployment path.
Before committing, list every action and integration you use in Port, then mark each as covered by a stock plugin, a custom plugin or a pipeline. For the field-by-field mapping, see the separate page on Port self-service actions.
What each option costs to run, by component
The main cost difference is that Port bills you for a subscription and charges recur, while Backstage has no license fee but moves the cost into infrastructure, build work and people. On the Port side, budget for the subscription and any per-seat or plan-based charges, which recur every term and depend on the plan features you need. Data integrations are the second line: Port can host them with a configurable resync interval, or you can self-host them with Helm or Docker according to Port's installation documentation, which moves compute and operations cost onto your team. Internal time to model blueprints is one-time at the start but recurs whenever your service model changes. Ask Port for the plan that includes the SSO, RBAC and self-service action features you require, and for any charges tied to integrations or seats.
Backstage has no software license cost, since Apache-2.0 means the project itself sells no paid edition. Your costs are the PostgreSQL database and backend hosting, CI pipelines that build and test the portal, and plugin development and maintenance, which is usually the largest recurring item. Upgrades recur as well: the main release line ships monthly and the next line ships weekly, and the versioning policy says high and critical vulnerabilities are backported to releases from the last six months when feasible, so plan a regular upgrade cycle. Confirm the Node.js runtime your version needs, which is Node.js 22 and 24 as of Backstage 1.46.0 per the versioning policy. The one-time cost is the initial build and migration; platform team time is the recurring cost that drives the rest.
Several factors move these numbers in either direction: the number of catalog entities and integrations, how many custom plugins you write, how often you upgrade, and whether a partner or your own staff runs on-call. For a written quote from any vendor or partner, ask for the one-time items (initial build, migration, blueprint or template design, and training) separated from the recurring items (subscription or support, hosting, plugin maintenance and upgrades). Ask for the named roles and their time, what is excluded, and how price changes when your entity count or user count grows. For Backstage engagements, ask whether the scope covers SSO and RBAC configuration, sign-in resolvers that map each identity provider to one user, and how upgrades and security patches are handled after handover.
What a move from Port to Backstage involves
The sequence turns a Port catalog, its blueprints and its self-service actions into a Backstage portal that runs in your own infrastructure, with both portals live for a period before Port is retired. Each phase ends with a check that the team can verify before moving on.
Inventory blueprints, entities, scorecards and actions
Platform engineering lists every blueprint, its properties and relations, the entities that depend on it, each scorecard and each self-service action in Port. Identity owners confirm which teams use each item and which integrations write data into the catalog, including any Ocean integrations that run in your infrastructure. The output is a written inventory with an owner for each item and a decision on what must migrate, what can be retired and what needs a replacement. The step is done when the platform lead and the main service owners have signed off on that list.
Export catalog data through Port's API
Engineers pull blueprints and entities from Port through its REST API and keep the raw exports in version control or a secure store with restricted access. They record which regional endpoint the tenant uses, how long access tokens last and which request limits apply, so the export can be repeated during cutover. The detailed export procedure is covered on the dedicated data export page. The step is done when a fresh export can be reproduced and the record count per blueprint matches what Port shows in its interface.
Map blueprints to Backstage kinds and catalog-info files
Architects translate each blueprint into a Backstage kind such as Component, API, Resource, System, Domain or Group, and define the owner, lifecycle and relationship fields that the catalog needs. Each service repository receives a catalog-info.yaml descriptor, and API entities reference their OpenAPI, AsyncAPI, GraphQL or gRPC definitions where those exist. Properties with no direct equivalent are either moved into annotations or dropped by decision. The step is done when a sample set of entities loads into a test Backstage catalog and the owners confirm that the relationships display correctly.
Rebuild self-service actions as Software Templates
Developers and platform engineers rebuild each Port self-service action as a Backstage Software Template, using scaffolder actions for repository creation, file generation and pipeline triggers. Approval steps, backend runners and any calls to internal systems may need custom plugins or actions, which the team scopes during this phase. The output is a set of templates tested against a non-production repository and target environment. The step is done when each template completes end to end in a test environment and the approval path has been exercised by a reviewer.
Stand up Backstage with PostgreSQL and identity
The platform team deploys the Backstage application in the organization's infrastructure with PostgreSQL as its production database, since the architecture overview lists PostgreSQL for production and SQLite for development. They configure one of the built-in authentication providers that matches the corporate identity system, set sign-in resolvers so every provider resolves to the same identity, and leave guest access disabled in production. Upgrade cadence and the Node.js versions the release line supports are set during this phase. The step is done when staff can sign in through the corporate identity provider and the catalog, templates and TechDocs load without errors.
Run both portals in parallel during cutover
Teams keep Port and Backstage running side by side while service owners move their daily catalog lookups and template runs to Backstage. Integrations are repointed in stages, and each change is checked against the exported inventory so that no entity or action goes missing. Discrepancies are logged with an owner and a fix date agreed by the platform lead. The step is done when the catalog counts, ownership data and template results in Backstage match Port for every item in the inventory, and no team reports a dependency still pointing at Port.
Retire Port after validation
Once validation is complete, the team removes Port integrations, revokes API tokens, confirms with the vendor how data is deleted under the contract, and archives the final export with the inventory and mapping documents. Stakeholders confirm that no compliance evidence or audit trail depended on Port data that was not carried over. The step is done when access is revoked, the archive is stored under the organization's retention policy and the platform lead records the decommission in the change log.
Port vs Backstage questions buyers ask before hiring help
What drives the cost of moving from Port to a self-hosted Backstage portal?
The biggest cost drivers are the size of your catalog, how many integrations Port currently feeds, how many self-service actions need rebuilding as Software Templates, and how much custom plugin work your scope includes. Backstage itself has no license fee, so the spend falls on people and infrastructure: an implementation partner or internal engineers for the build, cloud or data center capacity to run it, and ongoing platform team time for upgrades and plugin maintenance. Ask for each of these as a separate line item in a written scope, with one-time costs (migration, initial build, hardening) listed apart from recurring ones (hosting, upgrades, support).
How long does a Port to Backstage migration take?
The duration depends mainly on how much of your Port setup needs to be rebuilt rather than exported. A catalog of a few well-defined services with simple blueprints is far quicker to map than one with many custom relations, scorecards and actions that depend on external systems. Running both portals during cutover also adds time, because teams need to validate that entities, ownership and actions behave the same in each. Most engagements are fixed-scope, so ask for a timeline tied to specific deliverables, the number of blueprints and actions in scope, and the review points where your team signs off before the next phase starts.
What does our team need to provide during the engagement?
You will need named owners who can make decisions about the catalog model, a source of truth for service ownership, and access to the systems the portal reads from, such as Git hosting, identity, CI/CD and cloud accounts. Engineers who currently build and maintain Port blueprints and actions should take part in mapping them to Backstage kinds and Software Templates, because they know which data matters and why. Security or identity staff should be involved early to agree on sign-in resolvers and role mapping. Write these responsibilities into the scope so that delays on your side are visible and do not get charged as vendor overruns.
Can our own engineers migrate from Port to Backstage without a partner?
Yes, a capable platform team can build a Backstage portal in-house, since the project is open source and its documentation covers the catalog descriptor format, Software Templates and TechDocs. The harder part is operational: keeping pace with the monthly main release line, handling security backports, managing the Node.js versions that Backstage supports, and maintaining plugins over time. Before deciding, estimate how many engineers can spend sustained time on the portal, what skills they already have in TypeScript, Kubernetes and identity, and who will be on call when the portal breaks. A partner can take on part of the build while your team keeps the knowledge in-house.
Does Backstage have a license fee?
No, Backstage is licensed under the Apache License 2.0 and the project itself offers no paid edition. Your costs come from the infrastructure that runs it, the engineering time to build and maintain it, and any third-party plugins, hosting or support you choose to buy. Be careful with the word free in a quote: Port's hosted plans carry subscription fees, while a Backstage portal moves that spend into people and operations. Ask any vendor, including DeployOpen, to separate the license question from the implementation and support costs in the written proposal.
Can Port run inside an air-gapped network?
Port's portal itself is hosted in Port's SaaS, and only its data integrations can be self-hosted in your infrastructure with Helm or Docker, so the portal cannot run fully inside an isolated network. If offline operation is a requirement, a self-hosted Backstage portal can run with internal Git, identity and container registries. Confirm the exact requirements with your security team and the vendor, including which Backstage plugins call external services, how documentation and dependencies are mirrored, and how updates are delivered into the isolated environment.
How do we choose an implementation partner for Backstage?
Start by asking for a written scope that lists deliverables, responsibilities, assumptions and timelines before any work begins, since most engagements are fixed-scope. Check whether the partner can plan, customize, integrate, harden, back up, upgrade and document the portal inside your own cloud accounts or data centers, and whether it offers ongoing support or retainers for upgrades. Ask how they handle identity and RBAC, security testing of the portal, and handover to your team. Request references you can verify, and ask who will do the work. DeployOpen plans, implements and supports self-hosted open-source platforms, but it does not issue audit reports or certifications, so confirm which compliance evidence will come from your own auditors.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Port vs Backstage, we start with a written scope that settles which Port features you actually depend on and what a Backstage portal must replace before any build work begins.
How we scope
- Inventory your Port blueprints, self-service actions, integrations and the SSO and RBAC settings your plan currently uses.
- Map each blueprint to a proposed Backstage kind, such as Component, API, Resource or System, and flag where a custom model is needed.
- Agree deliverables, timelines and responsibilities in writing before work starts, since most engagements are fixed-scope.
How we build
- Set up a Backstage instance in your infrastructure with PostgreSQL, sign-in resolvers and the catalog sources you need.
- Build Software Templates for the self-service actions in scope and wire up the plugins your teams require, documenting any custom code.
- Test authentication, catalog ingestion, template runs and access rules against the scope before anything reaches production users.
How we hand over
- Document the catalog-info.yaml conventions, template structure, plugin inventory and the upgrade path for your chosen release line.
- Run knowledge transfer with your platform engineers so they can own catalog changes, template edits and routine maintenance.
- Provide a runbook covering backups, the Node.js version in use and the steps to keep the portal current with security fixes.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer if your team wants a partner for Backstage release cycles.
- Repeat security testing of the portal, its templates and its APIs on a schedule agreed in the retainer scope.
- Confirm with us during scoping which parts of the work your internal team keeps, so ownership of the platform is clear from day one.
