Should your team or a partner run the Backstage implementation?
For most platform leaders, the answer depends less on Backstage itself and more on whether the team has spare capacity for a multi-quarter build and a permanent run commitment. Your team should own the implementation when it already operates Kubernetes, CI/CD and identity services well, has at least one engineer who can own the catalog model and plugin choices, and can absorb an ongoing upgrade habit. A partner makes more sense when the team needs the portal sooner than its own roadmap allows, lacks TypeScript and React depth for the plugin layer, or wants a fixed-scope delivery with written deliverables before committing headcount. The usual triggers are recognizable. Teams start looking at a developer portal when there is no shared service catalog, so nobody can answer who owns a service or which API it exposes. Onboarding work is duplicated, with each squad rebuilding repositories, pipelines and access requests by hand. Documentation is scattered across wikis, repositories and chat threads, so engineers search several places before they find a runbook. Each of these symptoms points to a catalog, templates and TechDocs, which are the core features Backstage ships with.
Backstage is an open source framework released under the Apache License 2.0, and the project itself offers no paid edition. That changes the cost question. You do not buy a license from the project. You pay for labor to design and build the portal, for hosting and databases to run it, and for the continuing upkeep of plugins, upgrades and security fixes. Whether a partner or your team does the build, those three cost lines remain. Vendor-hosted Backstage products and other developer portals are a separate decision, covered elsewhere on this page's sibling topics.
Teams usually build in-house when they have an existing platform group, a clear owner for the catalog data and a tolerance for a slower first release. They usually bring in a partner when they need a dated first release with defined scope, when identity and hosting must be done correctly on the first attempt, or when internal engineers would otherwise be pulled from product work for the whole build. A hybrid model is common: a partner delivers the first phases and documents the catalog model, and the internal team takes over plugin work and routine upgrades. Whichever path you choose, ask the same questions before deciding. Who will own the catalog and ownership data after go-live? Who will run the monthly main release line and the weekly next line, and who applies high and critical security backports? Which identity provider will sign users in, and who writes the sign-in resolvers? Ask a partner to show how these answers appear in its written scope, and ask your own team to name the people for each one. If those names do not exist yet, the partner option usually costs less in delay than an unstaffed in-house build.
What a Backstage implementation includes and delivers
A fixed-scope Backstage engagement usually breaks into a small set of work packages that build on each other, from catalog design through to a hosted instance and handover. Each card below names the deliverable the client keeps at the end, so the scope can be checked against a written quote.
Discovery and catalog model design
This package agrees which entities the portal will hold, such as components, systems, APIs, resources, groups and users, and how they relate to each other. The output is a catalog model document with entity kinds, required annotations, ownership rules and naming conventions. Check that the model names a single owner for each entity and states how ownership is kept accurate over time.
First set of software templates
The team builds the first Software Templates, which create a repository, a pipeline and any initial infrastructure from a form in the portal. The client receives working templates, each with a documented parameter set and a review step where a human approves the output before it goes live. Confirm which template actions are custom and who maintains them after handover.
TechDocs setup
This package connects documentation stored alongside source repositories to the portal, configures the documentation build and defines where the generated sites are published. The deliverable is a working documentation pipeline and a short guide for authors on structure and build checks. Ask where generated documentation is stored in production and who restores it if storage fails.
Authentication and sign-in resolvers
Backstage ships 19 built-in authentication providers, so the work is choosing the providers the organization already trusts and writing sign-in resolvers that map each one to the same identity. The client receives configured providers, a resolver specification and guest access removed for production. Confirm which identity source owns group membership, since that drives catalog ownership.
Production database, caching and hosting
This package moves the instance from development storage to PostgreSQL, sets up a cache such as Redis and deploys the application into the client's own cloud account, data center or air-gapped network. The deliverables are a deployed instance, infrastructure definitions, backup and restore settings and runbooks for routine operations. Confirm who holds the database credentials and where backups are kept.
Plugin selection, integration and handover
The team evaluates which plugins fit the catalog and templates, integrates them with existing source control, CI and cloud systems, and documents the upgrade path. The client receives a plugin inventory with owners and versions, operating runbooks and a handover session with the teams who will run the portal. Ask how each plugin is kept on current Backstage releases after the engagement ends.
What drives Backstage implementation cost and duration up or down
This table lists the factors that most change the effort of a Backstage build, why each one matters, and how to keep it contained. Read it before you request a quote, because the same scope can cost very differently depending on these choices. The main takeaway is that a narrow first release with one golden path and a small catalog pilot is the most reliable way to control both cost and schedule.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Teams and owners to model | Each team needs ownership data, group mapping and catalog entries that match its real structure. Ownership disputes often take longer than the code. | Start with the teams that will use the portal first. Confirm an owner model with them before modeling the rest. |
| Catalog entity types and ingestion sources | Components, systems, APIs, resources and users each add modeling work. Each ingestion source (repositories, cloud accounts, registries) adds a provider to build, test and maintain. | Limit the first release to components and owners. Add APIs and resources once the first pass is stable. |
| Software templates and custom scaffolder actions | Every template needs form design, repository and pipeline output, review steps and testing. Custom scaffolder actions add code that must survive upgrades. | Ship one golden path first. Reuse existing scaffolder actions before writing custom ones. |
| Identity provider and group mapping | Sign-in resolvers must map each provider to one identity. Group data from the identity provider needs to match catalog ownership, which often exposes data quality issues. | Pick one identity provider for the pilot. Confirm group naming and the sign-in resolver design with the identity team early. |
| Plugins and integrations (CI, cloud, Kubernetes, search) | Each integration needs credentials, configuration, access scopes and testing. Plugins from the community may need extra work to match your version of Backstage. | Select integrations by the decisions they support. Defer plugins that no pilot user needs. |
| TechDocs volume | Document builds, publishing and storage grow with the number of sites and their size. Storage and build pipelines are part of the operating model. | Start with docs from the pilot teams. Confirm the storage location and publishing pipeline before scaling. |
| Environments (dev, staging, production) | Each environment needs its own configuration, secrets, database and authentication setup. Promotion and testing add routine work. | Agree on a minimum set of environments for the pilot. Add more only when a release process requires them. |
| Compliance evidence needs | Assessors may ask for records of access control, change history, backups and ownership data. Collecting this evidence adds design and documentation work. | Ask the auditor or compliance lead which evidence is required before design starts, then build collection into the plan. |
| Kubernetes or VM hosting | Kubernetes adds cluster, ingress, secrets and scaling configuration. A virtual machine is simpler to start with but needs its own process management, patching and recovery steps. | Use the hosting model your platform team already runs and supports. Confirm which model the quote assumes. |
How a Backstage implementation runs in phases
The sequence moves from agreed scope to a catalog, sign-in and first templates that a few teams use in real work, then to a production cutover and a handover your team can operate. Each phase closes with a named output, so you can check progress before the next phase starts.
Agree scope and inventory the current state
The partner reviews your existing service inventory, source control layout, identity provider, CI/CD tooling, cloud accounts and any internal portals or wikis that Backstage must replace or link to. Your platform lead and a few representative product teams take part. The output is a written scope document listing included features, excluded features, named owners on both sides and the success criteria for the pilot. Ask the partner for a phase plan with dates as part of that written scope, since no fixed timeline applies to every organization.
Design the catalog model and ingestion
Decide which entity kinds you will model, such as components, systems, APIs, resources and groups, and who owns each one. Choose between committed catalog-info.yaml files and entity providers that read from your source control or identity directory, and define the rules for keeping ownership data current. The output is a catalog model document with examples for each entity kind and a tested ingestion configuration running in a non-production instance.
Set up environments and hosting
The partner provisions separate development, staging and production environments inside your cloud accounts or data center, with PostgreSQL for backend plugin storage, a caching layer, object storage for TechDocs and the container pipeline that builds the portal. Your team reviews network paths, secrets storage and access to the infrastructure code. The output is a running staging environment deployed from code, with documented runbooks for deploying and rolling back.
Configure authentication and permissions
The partner connects your identity provider through the built-in authentication provider that matches it, writes sign-in resolvers so each login maps to one consistent identity, and sets up user and group ingestion from the directory. Guest access is removed for any shared environment. Permission policies are defined for catalog, templates and sensitive actions. The output is a tested sign-in flow for each provider in use, with a list of who can read, edit and run each protected capability.
Build the first templates and TechDocs
The partner builds a small set of Software Templates for the most common service types your teams create, with review steps where approval is required, and sets up TechDocs so documentation is built from repositories and published to the portal. The first templates are tested with your platform team before any product team sees them. The output is a set of approved templates and a TechDocs publishing pipeline that renders documentation for at least the pilot components.
Integrate plugins for your toolchain
Plugins are selected against the tools you actually run, such as source control, CI/CD, cloud or Kubernetes views and search, and each one is checked for compatibility with the Backstage version in use. Plugin choices are recorded with the reason and the upkeep each one adds. The output is a plugin inventory with configuration that has been tested against your real data sources, plus a list of any gaps where custom development is needed.
Run a pilot with a few teams
A small group of teams uses the portal for real services during an agreed period. The partner and your platform team watch for catalog errors, wrong ownership, template failures and slow pages, and fix them in the same release train. Feedback is logged against the success criteria from the scope document. The output is a pilot report with resolved issues, open issues with owners, and a go or no-go recommendation for production.
Cut over to production and hand over
The partner moves the approved configuration to production, opens access to the wider organization in stages, and confirms backups, monitoring and alerts work. Handover covers runbooks, configuration ownership, the upgrade process and the support model you choose, whether that is your own team, a retainer or both. The output is a production portal, signed-off runbooks and a trained internal team that can deploy and maintain it.
Which parts of a Backstage build your team keeps and which it outsources
This table compares Backstage work that usually stays with your team against work that is often outsourced, and names the skills each one needs. Use it to decide where to hire, where to buy a fixed-scope piece, and where to set up internal review before a quote is signed. The main takeaway is that catalog decisions, identity mapping sign-off and day-to-day ownership depend on your organization's knowledge, while scaffolding and wiring benefit from specialist build experience.
| Work area | Usually kept in-house | Usually outsourced |
|---|---|---|
| Catalog ownership decisions | Deciding which components, systems, APIs and owners are modeled, and who maintains each entry. Skills: domain knowledge and service ownership practice. | Modeling options and proposing a catalog structure as a draft for your review. Skills: software catalog design and ingestion experience. |
| Template content for your stacks | Writing the templates that match your languages, pipelines and approved base images. Skills: TypeScript and YAML, plus knowledge of your build and deployment standards. | Scaffolder action code and template plumbing so the templates run reliably. Skills: TypeScript and Node.js. |
| Sign-in resolver code and identity mapping | Final sign-off on how each provider maps to one user identity and which groups are imported. Skills: identity administration for your IdP. | Writing the sign-in resolver code and testing it against your provider configuration. Skills: TypeScript and Node.js, OIDC or SAML integration. |
| Architecture and hosting setup | Approving the hosting target, network placement and data residency rules. Skills: Kubernetes and PostgreSQL operations, cloud account administration. | Designing the deployment, database layout and caching approach, then building the initial hosting configuration. Skills: Kubernetes, PostgreSQL and CI/CD. |
| Initial scaffolding and plugin wiring | Reviewing the generated app and deciding which plugins are in scope. Skills: enough TypeScript and React to read the code and approve changes. | Creating the initial Backstage app, wiring the selected plugins and fixing integration issues. Skills: TypeScript, React for frontend plugins, Node.js for backend plugins. |
| Day-to-day platform ownership | Triage, plugin upgrades, catalog hygiene, user support and monthly release review. Skills: Node.js, Kubernetes and PostgreSQL operations, identity administration. | Optional retainer for upgrade work and incident support, scoped in writing. Confirm what the agreement covers before signing. |
| Handover documentation | Accepting the documentation, running the handover walkthrough and updating runbooks after go-live. Skills: technical writing and platform operations. | Drafting the architecture notes, setup guides and operating procedures from the delivered build. Confirm the format and depth in the written scope. |
What usually goes wrong in a Backstage implementation and how to prevent it
Most Backstage portals that stall do so for predictable reasons: the catalog drifts, identities split, shortcuts reach production, and the platform falls behind its upgrade line. Each card below names one failure mode, the step that prevents it, and the item to confirm in a fixed-scope quote before work starts.
Stale and unowned catalog entities
A catalog filled with components that have no owner, no current description, or a repository that no longer exists makes search results and ownership views unreliable within months. Prevention starts with a required owner field, a rule for who removes retired entities, and a periodic report of entities missing owners. In the quote, confirm who builds and maintains that report and whether catalog cleanup is in scope or left to your teams.
Sign-in resolvers that split identities
When GitHub, Okta or Google sign-in each create a separate user entity for the same person, group membership and ownership stop matching across providers. The Backstage authentication documentation advises configuring resolvers so every provider resolves to the same identity. Confirm in the quote which identity provider is the source of truth, who tests resolver behavior with real accounts, and whether user and group ingestion is included.
Guest access left on in production
Guest sign-in is convenient during setup and easy to forget. The Backstage authentication documentation advises against offering guest access in production, yet a leftover guest provider lets anyone who reaches the URL see catalog and documentation content. Prevention means removing the guest provider from production configuration, verifying it in the deployed environment rather than only in local files, and adding that check to release review. Confirm in the quote that removal and verification are named deliverables.
Portal lagging behind the main release line
Backstage ships a main release line monthly and a next line weekly, and high and critical security fixes are backported to releases from the last six months where feasible. A portal that stays on an old version loses that coverage and accumulates template and plugin drift that makes later upgrades expensive. Prevention is a named owner for monthly version bumps using the Backstage upgrade tooling. Confirm whether the quote includes upgrades or whether they are a separate retainer.
Plugins adopted before owners exist
Each plugin adds configuration, a backend, credentials and upgrade work. Adopting many at once, before a team has agreed to operate them, leaves broken integrations that no one is accountable for. Prevention is a short list of launch plugins tied to named owners, with a rule that a new plugin needs an owner and a support path before it is installed. In the quote, confirm the exact plugin list, which ones are custom, and who maintains each after handover.
Templates that skip review steps
A Software Template that creates repositories, pipelines or cloud resources from a form can produce non-compliant assets at scale if it runs without approval gates, naming standards or security defaults. Prevention is a review step for each template before publication, a named template owner, and scaffolder action limits that match your policies. Confirm in the quote how many templates are in scope, who approves them, and whether custom scaffolder actions are included.
Hosting not sized for TechDocs and search
TechDocs builds and storage, and the search index, grow with the number of documented components and catalog entities, and they load differently from the rest of the portal. A deployment sized only for the web app can slow builds, exhaust storage or fail during indexing. Prevention is to size PostgreSQL, object storage for TechDocs output, and the search backend from a catalog and documentation estimate, then test indexing time. Confirm in the quote which environments are provisioned, what load testing is included, and who pays for ongoing cloud capacity.
What a Backstage portal costs to run after go-live
Apache-2.0 Backstage has no license fee from the project, and there is no paid edition from the project itself. After go-live, the recurring cost of a Backstage portal is therefore labor and infrastructure. The infrastructure side includes hosting for the Backstage backend application, hosting for the PostgreSQL databases that Backstage uses in production (each backend plugin gets its own logical database), and storage for TechDocs output. Ask who owns each of these accounts and who pays the cloud bill, because the answer determines whether the cost sits in your budget, the partner's, or both.
The largest recurring labor item is upgrade work. Backstage ships a main release line monthly and a next release line weekly, so you must decide which line you follow and how much platform engineer time each cycle needs. Plugin upkeep is the second item. Each third-party or custom plugin must track the same @backstage package versions as the core app, and a plugin that falls behind can block an upgrade. Security work sits on top of this. The versioning policy says high and critical severity vulnerabilities will always be backported to releases from the last 6 months if feasible, and other security fixes may be backported. Your team needs a standing process to pick up those fixes quickly, whether in-house or through a partner.
Optional support or a retainer covers work that does not fit your internal rota: scheduled upgrades, plugin maintenance, security patch cycles, incident response and recovery testing. Keep these separate from the build. A fixed-scope build quote should list one-time fees for discovery, catalog design, first templates, TechDocs, authentication and go-live. A recurring support quote should list what is covered each month or year, the upgrade cadence, the plugins in scope, how security fixes are handled, response expectations and what is excluded. Ask for both in writing, with the recurring part stated as its own figure rather than folded into the build total.
Before you approve a plan, confirm a few things with the partner and inside your organization. Ask which Node.js versions the proposed upgrade process supports and who tests them. Ask how plugin upkeep is counted and whether custom plugins are included. Ask what happens to pricing if the upgrade cadence changes or if a critical fix arrives outside the planned cycle. Finally, confirm your own internal cost: the hours your platform team can give each month, the cloud accounts and budget owners for hosting and storage, and the escalation path when a security fix lands. A quote that answers these questions makes the recurring cost comparable with building the capacity in-house.
How the Backstage build changes by starting point and environment
A greenfield build starts with no existing catalog, templates or sign-in setup, so the work centers on design decisions made early and written down. The team agrees on the catalog model, the first software templates and the identity provider, then builds a small working portal that tests those choices before wider rollout. Nothing is inherited, so scope is easier to bound, but the first phases usually take the most decision time from the client's side.
- Catalog model: agree on conventions for components, systems, APIs, resources and owners before ingesting any data.
- Authentication: select one of the 19 built-in authentication providers and write sign-in resolvers so every provider resolves to the same identity.
- First templates: limit the first release to two or three golden paths the platform team can maintain after handover.
- Documentation: decide where TechDocs builds run and how the published output is stored and served.
- Database: plan PostgreSQL for production, and use SQLite only for local development.
Confirm with your identity team which provider is authoritative for staff, and confirm with your platform team who will own templates and plugins after the build closes.
Migrating from a commercial developer portal, a wiki or a service registry is mainly data movement and cutover. Scope depends on how many sources feed the portal, how complete the ownership data is, and how long the old system must run in parallel. Most of the effort sits in reconciling records that were never kept consistent, not in writing the Backstage configuration itself.
- Source inventory: list every system that holds services, owners, APIs and documentation, and note which ones are authoritative.
- Export paths: confirm what each current system can export and in which format, with the vendor or the internal team that administers it.
- Ownership reconciliation: map old team names and service records to catalog owners, and agree who resolves conflicts.
- Parallel run: decide how long both systems stay live, which system is the write source during that period, and how links and bookmarks are redirected.
- Contract timing: confirm the notice period and end date in the current vendor agreement before the cutover date is set.
Confirm the export formats, the owner of each source record and the contract end date with the people who run the current systems, since these determine the migration sequence and the length of the parallel run.
An existing Backstage app on an older release needs an upgrade before new features are added. The work covers the gap between the current version and the target version, changes to custom code and plugins, and a test pass on the upgraded app. The size of the gap is the main driver, because Backstage ships a main release line monthly and a next release line weekly, so a long gap means more template changes to review.
- Version gap: measure how far the app is behind the target release and list every package that will change.
- Runtime check: confirm that the Node.js runtime is supported by the target version. The versioning policy lists Node.js 22 and 24 as supported as of Backstage 1.46.0, so check the policy for the release you choose.
- Plugin compatibility: review each community and custom plugin for changes in its API or peer dependencies.
- Template changes: use the Upgrade Helper to review template differences, then apply package moves with yarn backstage-cli versions:bump.
- Security window: the policy says high and critical vulnerabilities are backported to releases from the last 6 months where feasible, so an app far behind may fall outside that window.
Confirm the current and target versions, the Node.js runtime in use and the list of custom plugins with the team that owns the app, because these set how many upgrade steps the plan needs.
A Kubernetes deployment moves the work into container images, manifests, ingress, secrets and stateful services. The portal may run several backend replicas, and each replica depends on shared state, so decisions about the database and cache have to be made before the cluster layout is fixed. The Kubernetes plugin is optional and needs its own credential scope if it is used.
- Packaging: build container images and choose the deployment tooling that matches the client's platform standard, such as Helm or plain manifests.
- Database: Backstage uses PostgreSQL in production and gives each backend plugin its own logical database through Knex, so confirm how databases are provisioned and which account runs migrations.
- Shared cache: Redis, Memcache, Infinispan or in-memory caching are supported, and a shared cache is needed once more than one replica runs.
- Secrets and ingress: define how authentication secrets, integration tokens and TLS certificates are injected and rotated.
- Kubernetes plugin scope: if the plugin reads cluster state, limit its service account to the namespaces and resource types the catalog needs.
Confirm the cluster platform standard, the database and cache services your organization already runs, and who approves service account scopes, since these decide the deployment pattern and the operations handoff.
An air-gapped or restricted network changes how the build gets its dependencies and how the portal reaches the services it depends on. Package installs, container base images, documentation sources and identity providers may all need to be reachable from inside the network. Every upgrade then also requires moving new packages across the boundary, which makes the update cadence a planning input from the start.
- Dependency mirror: stage the required yarn packages, container images and the Node.js runtime inside the network, with a documented process for refreshing them.
- Build location: run the build and the container pipeline inside the restricted zone, so no step depends on public registries.
- Documentation builds: confirm that TechDocs can build from sources available inside the network and does not call external services.
- Identity provider: confirm that the chosen provider, such as an on-premises directory or self-hosted OIDC service, is reachable from the portal.
- External plugins: check whether any plugin fetches data from public APIs or hosted repositories, and replace or disable those integrations if the network policy requires it.
Confirm with your security and network teams whether a dependency mirror is permitted, how often packages can cross the boundary and which external services the portal may contact, because these answers set the upgrade schedule and the plugin list.
What the client must provide before a Backstage build starts
The fastest way to lose schedule on a Backstage build is to start before the client has decided who owns what. Eight inputs shape the quote and the timeline most directly, and each should be settled in writing before a fixed-scope proposal is priced. First, name an accountable owner for the catalog itself, plus a named owner for each team whose services will appear in it. Every catalog entity needs an owner reference, so a partner cannot model ownership for teams that have not been identified. Second, identify the source of truth for services and repositories. It might be a configuration management database, a service registry, a set of GitHub or GitLab organizations, or existing catalog-info.yaml files. The answer determines whether the work is a provider-based import or a manual seeding exercise, which is one of the largest drivers of effort.
Third, grant identity provider administrator access and agree a group structure. Backstage sign-in resolvers map each provider identity to a catalog user, and the Backstage authentication documentation advises configuring resolvers so every provider resolves to the same identity. That mapping depends on how your Okta, Microsoft, Google, GitHub or generic OIDC tenant organizes users and groups. Someone with administrator rights must export group membership and confirm which groups represent teams. Fourth, provide cloud or cluster accounts and network rules. The build needs a non-production environment where Backstage can run, a route from that environment to the source control, CI and cloud systems it reads, and firewall or ingress rules agreed with your network team. Each unresolved network dependency tends to add review cycles that the schedule must absorb.
Fifth, decide the PostgreSQL and object storage plan. Backstage uses PostgreSQL in production and SQLite for development, and it gives each backend plugin its own logical database through Knex. Confirm whether your database team will provision the instance, who holds backup and restore responsibility, and which object storage service will hold TechDocs output. These decisions set the hosting scope and determine whether your team or the partner operates the database after handover. Sixth, decide how guest access will be removed. The authentication documentation advises against offering guest access in production, so the pilot sign-in path must be retired on an agreed date with a named approver. Removing it touches sign-in configuration and user testing, so it should be planned from the start and priced as part of the build.
Seventh, name a sponsor who signs off on software templates. Templates create repositories, pipelines and infrastructure for developers, so each one needs an approver who accepts the naming rules, security settings and ownership defaults before it is published. Without a named sponsor, review becomes repeated rounds that the schedule does not have room to absorb. Eighth, commit developer time for pilot feedback. A pilot group needs to test catalog entries, search results and the first templates, then report what is wrong. Ask for named individuals and a booked window, and agree in writing how many feedback rounds the fixed scope includes. Finally, ask the partner to state which of these inputs its quote assumes and what changes to cost and dates if any of them arrive late.
Common questions about Backstage implementation cost, time and effort
Does Backstage have a license fee?
No. Backstage is an open source framework released under the Apache License 2.0 (SPDX: Apache-2.0), according to its GitHub repository, and the project itself has no paid edition. Your cost is therefore the work and the infrastructure, not a software license. Those costs fall into a few groups: planning and design, building the catalog model and first templates, configuring authentication and TechDocs, hosting and database operations, and plugin selection and integration. Some plugins or hosted services may carry their own terms, so check the license of each component you add. Ask any provider to separate license, labor and hosting in the quote.
What drives the cost of a Backstage implementation?
The main drivers are the number of systems to integrate, the number of identity providers and groups to map, how much of your catalog is already documented, and how many software templates you need on day one. Custom plugins, custom scaffolder actions and changes to your CI/CD or cloud accounts add effort. Hosting topology matters too: a single environment for evaluation is much smaller than a production deployment with PostgreSQL backups, shared caching and object storage for TechDocs. Costs that recur include hosting, staff time for upgrades and plugin upkeep, and support if you buy it. A quote should show which items are one-time and which recur.
How long does a Backstage implementation take?
This page does not quote a duration, because the answer depends on the scope and on your environment. The biggest factors are how many integrations are in scope, how quickly your identity and cloud access can be provisioned, the state of your existing service ownership data, and how many decision-makers must sign off on templates and naming. Phases typically include discovery, a catalog and template design, a build and integration phase, and a staged rollout. Ask for a timeline in the written scope, with each phase and the dependencies you must supply.
What does our team need to provide for the work?
Expect to provide named owners for the platform, access to your identity provider, source control, CI/CD, cloud accounts or clusters, and a place to host the database and TechDocs storage. You will also need subject-matter input on your service ownership model, naming conventions and the golden paths you want templates to create. Plan for reviewers who can approve templates and catalog data. The more of these inputs that are ready at kickoff, the fewer waiting periods the engagement will have. List each dependency in the scope so that delays are visible and attributable.
Can a small platform team implement Backstage alone?
Yes, a small team can deliver a first portal alone if it has engineers comfortable with TypeScript, Node.js, Kubernetes or your hosting platform, and the identity and cloud access to deploy. Effort grows when the team must also design the catalog model, configure sign-in resolvers, and keep up with monthly main releases and Node.js support windows. Many teams start with a narrow scope, such as catalog and TechDocs, and add templates later. Be honest about the time your team can give over the first months, and about who will own upgrades after go-live.
What should a fixed-scope Backstage quote include?
A fixed-scope quote should name the deliverables, the environments, the integrations and identity providers in scope, the number of catalog entities and templates, and the plugins to be installed or built. It should list the phases, the milestones, the client dependencies and the acceptance criteria for each deliverable. It should also state what is excluded, such as custom plugin development or ongoing support, and what handover documentation you will receive. DeployOpen issues quotes from a written scope, so the scope is the document to review before comparing prices.
Can the Backstage portal be upgraded after go-live?
Yes. Backstage upgrades use yarn backstage-cli versions:bump to move all @backstage packages together, and the Backstage Upgrade Helper shows template changes between versions, according to the project's keeping Backstage updated guide. The project ships a main release line monthly and a next line weekly, so upgrades are recurring work, not a one-off. Plan for staff time or a support arrangement for this, and confirm which Node.js versions your release supports before you schedule upgrades. Custom plugins are the usual source of extra effort, so design them with upgrades in mind.
How DeployOpen scopes, delivers and hands over a Backstage portal
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and Backstage is delivered the same way. Engagements are fixed-scope, so the phases, deliverables and timeline for the portal are agreed in writing before build work starts.
How we scope
- We confirm which catalog entities, templates and TechDocs sites are in the first release and which are deferred.
- The written scope names each identity provider and the sign-in resolver rules agreed for that provider.
- We list the plugins to be evaluated, with the decision criteria and the owner who signs off on each choice.
How we build
- We build the catalog model and ingestion first, then add software templates and TechDocs in agreed phases.
- Each phase is tested against the acceptance criteria written into the scope before the next phase begins.
- Hosting, PostgreSQL, caching and TechDocs storage are set up in your cloud account, data center or air-gapped network.
How we hand over
- You receive the source repository, deployment configuration, runbooks and the documented catalog ownership model.
- Operators are walked through upgrades with versions:bump and the Upgrade Helper, using your own environment.
- Handover is complete when the acceptance tests in the written scope pass and your team has run the core procedures.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover.
- Retainer scope, response expectations and the Backstage releases it covers are agreed in writing before work starts.
- Ask any provider to confirm which Node.js and Backstage versions their support plan covers before you sign.
