Self-hosted OpsLevel vs self-hosted Backstage

Can a developer portal run on an isolated network with OpsLevel or Backstage?

A security or platform lead whose network cannot reach the internet still needs a service catalog and ownership data inside that boundary. The short answer is that OpsLevel's self-hosted edition is not fully independent of outside connectivity. It requires a license file from OpsLevel, an installation through Replicated, and an instance that is reachable over the internet for push-based integrations. Backstage, by contrast, is Apache-2.0 software with no license key, so nothing about its installation depends on a vendor license check. Whether either platform can operate in your environment depends on which integrations you need, and that is a question to answer before any procurement step.

The constraint to define first is what crosses the boundary. In an isolated network, you need to know whether OpsLevel's license validation and Replicated's installation tooling can run with outbound access blocked, and whether the push-based integrations that OpsLevel documents can be replaced with pull-based collection from inside your network. Ask OpsLevel in writing which connections the self-hosted edition makes, whether license validation works offline, and how updates are delivered to a cluster with no internet route. The cluster itself needs at least 16 CPU and 16 GB of memory according to OpsLevel's self-hosted documentation, so confirm that your isolated environment has that capacity before you start.

For Backstage, the question shifts to packaging and supply chain. Its own code has no license gate, but you must pull container images, npm packages and plugins into your network in advance, and then keep them current. This page compares the two options in terms of that isolation, the hosting footprint, and the work each one leaves to your team. Use it alongside the sibling sections on cost, data export and hosting to decide which path matches your isolation requirements. Where a fact about either product's offline behavior is not documented in the sources reviewed here, confirm it with the vendor or in a proof of concept inside an environment that matches yours.

What an isolated network requires from a developer portal

A developer portal inside a tightly controlled network has to work without an outbound internet path, install from images you have vetted, and reach source systems inside the boundary. Each card below ties one of those constraints to a documented behavior of OpsLevel or Backstage that you should confirm before committing to either option.

Outbound internet access for the portal

OpsLevel's self-hosted documentation says the instance must be reachable over the internet for push-based integrations. That means the portal's network placement, ingress rules and any allowlisting need a formal review before deployment. Backstage has no equivalent requirement from the project itself, so its outbound paths are whatever your plugins and authentication providers demand. Ask OpsLevel exactly which endpoints and directions it needs, and whether a fully internal pull model covers your integrations.

Offline installation and image supply

OpsLevel installs through Replicated on a Kubernetes cluster or VM, which means you need to confirm how Replicated-delivered images and updates reach an air-gapped cluster. Backstage is published as open source code, so you build and host its container images yourself from your own registry. Kubernetes clusters can be prepared without internet access by pre-pulling control plane images and pointing installs at a private registry. Plan for the same pattern with every component the portal depends on.

License file and vendor check-in

OpsLevel's self-hosted edition requires a license file from OpsLevel, and commercial self-managed editions of this kind still depend on a vendor license. Ask whether the license is validated offline, how long it remains valid without contact, and what happens at renewal if the enclave cannot reach the vendor. Backstage is Apache-2.0 licensed and has no paid edition from the project, so no license check-in is part of its design. Record the license terms in your own compliance evidence either way.

Integrations that reach sources inside the boundary

A catalog is only as current as the systems it reads from, such as source code hosts, Kubernetes clusters and CI tools inside the enclave. Confirm whether OpsLevel's integrations can run from inside the network without the instance being exposed to the internet. For Backstage, the catalog reads descriptor files such as catalog-info.yaml from repositories you host, and plugins call internal APIs directly. Test each source connection from the isolated segment before you accept the design.

Authentication and sign-in resolution

Backstage ships 19 built-in authentication providers, and its authentication documentation advises configuring sign-in resolvers so every provider maps to the same identity and not offering guest access in production. In an isolated network, confirm that your identity provider is reachable from inside the boundary and that OpsLevel's SSO options work without external callbacks. Map identities consistently so ownership data stays tied to the right people. Treat any gap here as a blocker for audit trails.

Patch cadence and supply chain checks

Backstage ships a main release line monthly and a next release line weekly, and it backports high and critical vulnerability fixes to releases from the last 6 months where feasible. Every update must be carried across the isolated boundary, so you need a process to verify each package's integrity and authenticity. Confirm with OpsLevel how it delivers security patches and how often, and whether it supplies signed artifacts for offline verification. Document the cadence you can support, since a portal that falls behind becomes its own risk.

How OpsLevel and Backstage compare under isolation

This table compares OpsLevel SaaS, self-hosted OpsLevel, self-hosted Backstage, and Port or Cortex self-managed against an isolated or tightly controlled network. Read each row for how the platform meets the isolation constraint, what it needs to run, what licensing it carries, and where it creates work for your team. The main takeaway is that a licensed self-hosted edition keeps the data in your network but still depends on a license file and an internet-reachable instance, so confirm those points before choosing.

Option	How it meets the isolation constraint	Minimum footprint from supplied facts	Licensing and subscription	Trade-offs
OpsLevel self-hosted	Installed in your Kubernetes cluster or VM through Replicated, but the instance must be reachable over the internet for push-based integrations	16 CPU, 16 GB memory, capacity for at least 20 pods, 24 Gi disk for pilots or 120 Gi for production	Requires a license file from OpsLevel, so the subscription continues	Confirm with OpsLevel whether push integrations can be restricted to an internal path, and which features need outbound access
OpsLevel SaaS	Data is hosted by the vendor, so it sits outside your isolated network and is out of scope for this constraint	None on your side, since the vendor runs the service	Per-developer subscription from the vendor	Not usable where data must stay inside the boundary; keep for teams with no isolation requirement
Self-hosted Backstage	Runs entirely in your environment, and the topic facts show Kubernetes clusters can be built and images pulled without internet access	Depends on your sizing, with PostgreSQL for production and a Node.js runtime; confirm the chosen release line supports your Node.js version	Apache-2.0 open source with no paid edition from the project itself	Your team owns builds, upgrades, plugin maintenance and any offline package mirroring
Port self-managed (reference)	Data integrations can run in your infrastructure with Helm or Docker, instead of hosted by Port	Ask Port for current sizing for your integration count and resync needs	Commercial subscription, which continues for the self-hosted option	Verify each integration's network calls, since the hosted and self-hosted paths differ
Cortex self-managed (reference)	Deployed into your own Kubernetes cluster via a Helm chart with a PostgreSQL database	Ask Cortex for current sizing; supported on EKS, AKS, GKE or a locally installed distribution	Requires a JWT license key and access token from the Cortex account team	Self-hosting does not remove the subscription; confirm whether licensing checks need outbound access

Where the OpsLevel self-hosted edition meets the constraint and where it does not

The OpsLevel self-hosted edition meets an isolated network only partly. Its install path is Replicated on a Kubernetes cluster (preferred) or a VM, and it needs a license file from OpsLevel before it runs. The documented minimums are 16 CPU, 16 GB of memory, capacity for at least 20 pods, and 24 Gi of disk for a pilot or 120 Gi for production. Check these against your cluster sizing and storage classes before you commit, because the 20-pod figure is a scheduling requirement that a small or heavily shared cluster may not have free. Confirm with OpsLevel whether the Replicated installer must reach the vendor's registries during install and upgrade, and whether those pulls can run from an internal mirror.

The harder constraint is connectivity. OpsLevel documents that the self-hosted instance must be reachable over the internet for push-based integrations, so any source that pushes data into the catalog needs an inbound path. A network that blocks inbound internet traffic to that instance cannot use push integrations as documented. Pull-based integrations may still work if the instance can reach your source systems, but that is a per-integration decision that needs a written answer from OpsLevel. Backstage has no such requirement, because its catalog runs inside your network and its data sources are reached by your own connectors.

Self-hosting does not remove the subscription. The license file is still issued by OpsLevel, so you pay for the edition whether it runs in your cloud, your data center or a restricted segment. Before you rely on it in a tightly controlled environment, ask OpsLevel three things in writing: whether license validation needs outbound contact and what happens when it cannot be reached, how and through which channel security patches and version updates are delivered to an offline instance, and whether the license can be renewed without network access. Those answers determine whether the edition fits your boundary, and they belong in your procurement file.

How self-hosted Backstage fits different isolation levels

In a fully air-gapped network, the Backstage instance has no route to the internet, so every dependency must be staged inside the boundary before deployment. The Software Catalog reads catalog-info.yaml descriptors from your internal Git server, and Software Templates run scaffolder actions against internal repositories and registries. TechDocs builds MkDocs sites from Markdown kept next to the code, so the build can run on internal infrastructure without a vendor cloud service. Backstage stores each backend plugin's data in its own logical PostgreSQL database through Knex, so PostgreSQL must be deployed inside the boundary too.

Catalog and templates: Point the catalog at internal Git hosts and keep template skeletons in an internal repository.
TechDocs: Pre-stage MkDocs and any plugins in an internal package mirror so builds never reach public indexes.
Database layout: Provision PostgreSQL inside the boundary and confirm that Knex creates one database per backend plugin.
Authentication: Use one of the built-in providers that your internal identity system supports, such as OIDC, and configure sign-in resolvers so every provider maps to the same identity. Disable guest access in production.
Cluster bootstrap: If Kubernetes hosts the portal, pull control plane images ahead of time and point the installer at a private registry.

Before approving this design, confirm with your network team which Backstage plugins call external endpoints at runtime and which update paths your change process allows.",

How to deploy Backstage inside an isolated network

This sequence takes a Backstage portal from an empty isolated network to a supervised, upgradeable deployment with its own cluster, images, database, identity and catalog sources. Each step closes with a check you can run before moving on.

Confirm the air-gapped Kubernetes baseline
Your platform team decides whether to build a new Kubernetes cluster or use one that already runs inside the boundary. For a new cluster, the team prepares the control plane images in advance with kubeadm config images list and kubeadm config images pull on a staging host that has access to the upstream registries, then copies them across the boundary. Done means every control plane image is present in the internal registry and the cluster bootstraps with kubeadm init pointed at that registry through the --image-repository flag. Confirm with your own security team how the image transfer is logged and approved, because this is the first point where software enters the isolated network.
Mirror Backstage dependencies and container images
Your build engineers mirror everything Backstage needs: the Backstage container images you plan to run, the npm packages and plugins your portal depends on, and base images for MkDocs used by TechDocs. Packages are pulled on the connected side, verified against the checksums and signatures your procurement process requires, and transferred into an internal package and container registry. Done means a clean build of your Backstage app succeeds with the network egress blocked, and a scan of the mirrored set is recorded. This addresses the software integrity and authenticity expectations in NERC CIP-013-2 where that standard applies to you, and you should confirm the exact verification steps with your compliance lead.
Provision PostgreSQL and the caching layer
The database team deploys PostgreSQL inside the boundary for Backstage's production data. The Backstage architecture overview states that PostgreSQL is used in production and that each backend plugin gets its own logical database through Knex, so the team grants the Backstage service account the rights to create and manage those databases. A cache is then configured from the supported options, which include Redis, Memcache, Infinispan or in-memory caching. Done means the Backstage backend starts, connects to PostgreSQL, creates its plugin databases, and reads and writes through the cache after a restart. Confirm the backup and restore procedure for these databases with the team that owns your database platform before go-live.
Configure authentication with one identity per user
Your identity team connects Backstage to your internal identity provider using one of the 19 built-in authentication providers, or a generic OIDC provider if yours is not listed. The Backstage authentication documentation advises configuring sign-in resolvers so every provider resolves to the same identity, and not offering guest access in production. Done means a test user signs in, is mapped to the expected User entity, and a guest sign-in attempt is rejected in the production configuration. Record the resolver logic in your change log, since reviewers will ask how identities are matched across providers.
Ingest catalog entities from internal sources
Platform engineers configure catalog ingestion from repositories that live inside your network, such as your internal Git forge. Each service repository carries a catalog-info.yaml descriptor with the entity kinds the Backstage descriptor format defines, including Component, API, System, Group and User. API entities can reference OpenAPI, AsyncAPI, GraphQL or gRPC definitions stored alongside the code. Done means the catalog shows the expected owners and components, every Location points to an internal address, and no entity depends on an external URL. Confirm which of your repositories already hold ownership data before you write new descriptors, because OpsLevel ownership will need to be reconciled against it.
Publish TechDocs from internal sources
Documentation teams keep Markdown files next to the code and configure TechDocs to build sites with MkDocs, using only MkDocs plugins that your build image already contains. The site is generated inside the boundary and served from internal storage. Done means a sample service's documentation renders in the portal, and a build with no outbound network access succeeds. If your plugins fetch assets at build time, the team must vendor those assets before the build is allowed to run.
Set an upgrade cadence against the release lines
The platform owner sets a recurring upgrade review that follows the two release lines in the Backstage versioning policy: the main line ships monthly on the Tuesday before the third Wednesday, and the next line ships weekly on Tuesdays. The policy states that high and critical severity vulnerabilities are always backported to releases from the last 6 months where feasible, and other security fixes may be backported. Confirm the Node.js versions that the current release supports, since the policy names two adjacent even-numbered releases, and keep your runtime aligned with them. Done means a staging environment is upgraded from the mirror, tested, and promoted, and the upgrade record names the release tested. Your staffing and change windows determine how quickly you can respond, so agree on them with your operations leads.

Carrying packages and images across the isolation boundary

How do we verify packages and container images before importing them into an isolated network?

Verify each artifact against a checksum or signature published by its upstream source before it crosses the boundary, and record the result in a transfer log. Treat the transfer step as a control point: one person prepares the bundle, a second person checks the hashes against an independent record, and only then is the media released inside. Keep the verification tooling itself on the inside so that the check is not performed by the same path that delivered the file. The general pattern follows the supply chain expectation in NERC CIP-013-2, which asks registered entities to address verification of software integrity and authenticity in procurement. Confirm with your compliance lead which evidence format your auditor expects.

How do we mirror Node.js and npm dependencies for a Backstage build without internet access?

Build an internal npm registry or a complete offline package archive from the lockfile of the exact Backstage release you plan to run, then point every build at that mirror. The lockfile is the authoritative list, so resolve it on a connected build host, download every tarball, and transfer them as a single bundle. Backstage supports exactly two adjacent even-numbered Node.js releases, and the versioning policy identifies Node.js 22 and 24 for Backstage 1.46.0, so mirror the Node.js runtime for the supported version alongside the packages. Confirm with the Backstage versioning policy which Node.js releases apply to the line you select, because the list changes between release lines.

How do we track Backstage release lines and security backports from an isolated environment?

Subscribe to the Backstage GitHub releases page and the versioning policy from a connected workstation, and record each release line you depend on in a tracking document. The main release line ships monthly, on the Tuesday before the third Wednesday of each month, while the next release line ships weekly on Tuesdays. 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. Plan your upgrade cadence around that window, because a version that falls outside it may not receive the fix you need. Review the keeping-Backstage-updated guidance before each cycle.

How do we test a Backstage update in a staging enclave before production?

Mirror the production configuration, catalog data and identity provider settings into a staging enclave that has the same network boundary, then run the full update through the same transfer path used for production. Test the catalog ingestion, sign-in resolvers, TechDocs builds and any plugins your teams rely on, and confirm that the database migrations complete against a copy of the production PostgreSQL schema. Use the staging run to measure how long each step takes so your change window is based on evidence rather than estimate. Keep the staging enclave patched on the same schedule as production, or the test will not reflect the live system.

What should the change record show for each package and image brought across the boundary?

The change record should show what was imported, where it came from, how it was verified, who approved it and where it was installed. For each artifact, capture the name, version, source URL, checksum or signature result, the transfer media identifier, the approver and the deployment timestamp. Add the Backstage release line, the Node.js version, the lockfile hash and a reference to the staging test results. Auditors and assessors usually ask for a trail that connects a running version to a verified bundle, so store the record in a system that the isolated network can read but not alter. Confirm the exact format with your assessor before the first transfer.

Who does the transfer work, and what does an implementation partner handle?

Your team owns the approval decisions, the transfer media policy and the evidence retained for assessors, because those reflect your risk acceptance. An implementation partner can script the mirror creation, the verification steps, the staging runs and the change record templates as part of a fixed-scope engagement, with deliverables agreed in writing before work starts. DeployOpen plans, implements, hardens and documents self-hosted platforms inside the client's own infrastructure, and prepares evidence for compliance assessments, but it does not issue audit reports or certifications. Ask any provider to state which steps they run, which your staff run, and which ongoing tasks a retainer would cover.

What recurring cost comes with carrying packages across the boundary?

The recurring cost is staff time for each release cycle: tracking the release lines, rebuilding the package mirror, running the staging test, transferring the bundle and completing the change record. Cost rises with the number of plugins, because each plugin adds dependencies to mirror and verify, and with the frequency of your update cadence. Backstage itself carries no license fee because it is Apache-2.0 licensed, so the spend sits in people, media handling and any tooling you choose. Ask any provider to quote these cycles separately from the one-time setup of the mirror and transfer process.

Evidence a regulator or auditor will ask for

Whichever platform you run, an examiner will ask you to show how the system sits inside its boundary, what software it runs, who can sign in and how it recovers. DeployOpen prepares this evidence for your environment, but independent auditors and assessors issue any attestation or certification.

Trust boundary network diagrams

Draw the segment that holds the portal, the database, the cache and the Kubernetes or VM hosts, and mark every permitted flow across its edge. For self-hosted OpsLevel, the edition expects the instance to be reachable over the internet for push-based integrations, so the diagram must show exactly which inbound paths exist, who owns them and how they are filtered. For Backstage, show that no external calls are needed at runtime. Confirm the diagram against the live firewall rules, not the design intent.

Software bill of materials and mirror manifests

List every container image, Helm chart, npm package and OS package that enters the isolated network, with versions and hashes. Backstage builds from many npm packages, so keep a lockfile record and a manifest of what was mirrored from outside. Ask the OpsLevel vendor for the component list shipped in its Replicated bundle, since you cannot rebuild it yourself. Use this record to show that each artifact crossing the boundary was checked for integrity and authenticity before it was loaded.

Sign-in resolver and access configuration

Document which identity provider each sign-in path uses and the resolver logic that maps every provider to one user identity. Backstage ships 19 built-in authentication providers, and its authentication documentation advises a single resolved identity per user and no guest access in production. Export the role mappings, admin accounts and service tokens, then show who can change them. Record the test results that prove a user from one provider cannot take over another account.

Change and patch records

Keep a dated log of every upgrade, with the release line, the changelog reviewed and the approver. Backstage's main line ships monthly and its next line ships weekly, so define which line you run and how quickly you apply security releases. The versioning policy says high and critical vulnerabilities are backported to releases from the last six months where feasible. Show that each patch was tested in a staging copy before production, and that rollbacks were possible.

Backup and restore tests

Backstage keeps state in PostgreSQL with a separate logical database per backend plugin, so backups must cover every plugin database together. For the OpsLevel edition, confirm with the vendor what its Kubernetes deployment stores and how it is backed up. Auditors want evidence of a restore, not just a backup job. Record the date, the scope, the restored environment, the time taken and the check that the catalog matched the source before the test.

License and subscription records

Keep the OpsLevel license file, the subscription order, the seat count and the renewal terms in the same evidence set as the deployment record. Self-hosting the commercial edition does not remove the subscription, and the license file is needed to install and run it. For Backstage, record that the project is Apache-2.0 licensed with no paid edition from the project itself, and keep the license texts of each plugin you add. Track who is paid for support and for plugin maintenance, since those contracts are evidence too.

What does self-hosting Backstage on an isolated network cost and require?

What drives the cost of self-hosting Backstage on an isolated network?

Backstage itself is free under the Apache License 2.0, so the cost is the work and infrastructure around it. The main components are the hosting (Kubernetes or VM capacity, PostgreSQL, a private container registry and caching), the build pipeline that compiles and ships your Backstage app inside the boundary, plugin development and maintenance, and the people who keep the platform current. The cost goes up with the number of custom plugins, the number of integrations to source systems, and how strict the change approval process is. Ask any implementation partner for a written scope that separates one-time build work from recurring upkeep.

Can our team set up Backstage on an isolated network without a partner?

Yes, if you have engineers who already run Kubernetes, build TypeScript or Node.js applications and manage private registries. Plan for the offline steps early: mirroring container images and npm packages, packaging the build, and handling authentication without internet-based identity providers. Teams without that skill set often use an implementation partner for the first build and then keep the platform in-house. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms inside the client's own network, and most engagements are fixed-scope with the scope agreed in writing before work starts.

How long does setup take, and what changes the timeline?

No supplied source gives a reliable duration for an isolated Backstage setup, so ask for one in a written scope rather than relying on a general estimate. The timeline mostly depends on how many catalog sources you connect, whether you need custom plugins, how your identity provider is configured and how long your security review of the offline bundle takes. Backstage ships a main release line monthly and a next line weekly, so the team also needs time to plan upgrades into the isolated environment.

What does the work need from our side?

Expect to provide network and change approvals, a Kubernetes or VM environment, a PostgreSQL service, access to an internal registry and a named owner for the platform. You also need an agreed way to bring software into the boundary, including reviewing each package and image before it crosses. Your identity team should confirm how users sign in, because Backstage guidance advises resolving every provider to the same identity and not offering guest access in production. Engineering leads should identify the teams and repositories that will supply catalog data first.

What does OpsLevel's license and minimum footprint mean for the budget?

The self-hosted OpsLevel edition still requires a license file from OpsLevel, so self-hosting does not remove the subscription. Its documented minimum is 16 CPU, 16 GB of memory, capacity for at least 20 pods and 24 Gi of disk for pilots or 120 Gi for production, and it is installed through Replicated. Those infrastructure needs recur alongside the license. Ask OpsLevel for the current subscription terms, and check with them whether the instance must be internet-reachable for push-based integrations, since that may conflict with an isolated network.

What should we ask for in a written quote for a Backstage project?

Ask for a scope that lists each deliverable: the target environment, the offline build and update process, the catalog sources, each custom plugin, the identity integration, backup and restore procedures, documentation and handover. Require the quote to separate one-time implementation from recurring support, upgrades and testing, and to state what the client must provide. Ask how the team will track Backstage releases and security backports, since the versioning policy backports high and critical fixes to releases from the last 6 months if feasible. Confirm acceptance criteria and who signs off.

Does running Backstage in our own network help with compliance obligations?

Hosting Backstage inside your boundary helps control where catalog data and access logs live, but it does not by itself satisfy any compliance regime. For example, NERC CIP-013-2 expects supply chain processes that verify the integrity and authenticity of software and patches, which applies to what you carry across an isolated boundary. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue audit reports and attestations. Confirm your specific obligations with your compliance lead before scoping the work.

When to keep OpsLevel and when to move to Backstage

Keep self-hosted OpsLevel when its license model, its integrations and its maturity features already fit how your teams work, and when your network can allow the connectivity the edition requires. OpsLevel's self-hosted edition is installed through Replicated, needs a license file from OpsLevel, and documents an instance that must be reachable over the internet for push-based integrations. Before you decide, confirm with OpsLevel which integrations depend on inbound traffic, whether an outbound-only or pull-based option exists for your sources, and how the license file is issued and renewed. A subscription stays in place either way, because the commercial self-hosted edition still requires a vendor license.

Move to Backstage when your boundary forbids internet-reachable integrations and you have, or can staff, the people who will own plugins and upgrades. Backstage is Apache-2.0 licensed with no paid edition from the project, so the recurring cost is the infrastructure and engineering time rather than a license fee. Its Software Catalog reads catalog-info.yaml descriptors that live in your own repositories, and its release line ships monthly, so someone must plan regular upgrades, watch for vulnerability backports and keep the Node.js runtime aligned with the versions Backstage supports. Confirm that your team can maintain the plugins your teams need, including authentication, where Backstage offers 19 built-in providers.

Run a short fit test before committing. Check your required integrations against your network rules, list the maturity checks your teams rely on, and estimate who will maintain the portal after launch. If the answer is that OpsLevel fits everywhere except the connectivity rule, the decision turns on how strict that rule is and whether an exception is possible. For the next steps, read the sibling pages on migrating from OpsLevel to Backstage only after you confirm the scope, and compare the total cost of each option in the OpsLevel cost versus self-hosted Backstage analysis before you request a quote.

How DeployOpen deploys Backstage under an isolation constraint

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For teams that cannot reach the internet from their developer portal, we scope a Backstage deployment around that boundary from the start, so the catalog, templates and docs stay within it.

How we scope

Written scope names which catalog sources, identity providers and build pipelines sit inside the isolated network
Fixed-scope engagements agree deliverables and timelines in writing before any build work starts
Scope lists how offline plugin packages, container images and documentation dependencies are sourced and approved
Ask us to confirm each external dependency Backstage needs and whether it can be mirrored internally

How we build

We install Backstage on your Kubernetes or virtual machine platform with PostgreSQL and caching configured for your network
Authentication uses your own identity provider, with sign-in resolvers mapping each provider to one identity and no guest access
Catalog descriptors in catalog-info.yaml files are built, validated and loaded from repositories your teams already control
We test the portal under the isolation rules, including upgrade paths for monthly and weekly Backstage release lines

How we hand over

Handover documents the architecture, network boundaries, configuration keys and the process for importing offline updates
Runbooks cover backup and restore of each plugin database, plus the steps to verify package integrity before crossing the boundary
Your team receives documentation on ownership of catalog data, templates and TechDocs builds after go-live
Evidence packs describe the controls implemented, prepared for review by your own auditors or certification bodies

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after handover
Retainers can cover backporting security fixes into your internal mirror when Backstage publishes them
Security testing of the portal, its plugins and its APIs can run on a schedule agreed in the retainer
Ask for the support scope, response expectations and upgrade cadence in writing before you commit