Self-hosted Port alternative for air-gapped networks

Why Port cannot run inside an air-gapped network

If your isolated network must still give developers a portal, the first thing to know is that Port's portal itself stays in Port's SaaS, and cannot be moved inside your network. Port's data integrations, most of them built on its Ocean framework, can be hosted by Port or self-hosted in your own infrastructure with Helm or Docker, according to Port's installation documentation. That means the collectors that pull data from your tools can run inside the network, but the catalog, the UI and the self-service actions still depend on a connection to Port's cloud. For a network with no route to the internet, the self-hosted integrations do not turn Port into an offline product. The option that can run fully offline is a self-hosted Backstage portal, which keeps the catalog, templates and docs in your own cluster.

The difference between the portal and the integrations is the core decision. Ask Port, in writing, which parts of your intended setup require outbound connectivity: the portal front end, the API that stores blueprints and entities, authentication callbacks, and any integration that pushes data to Port rather than letting you pull it. Then compare that list with the boundary your security policy draws. Isolation requirements come from your own policy, your accreditation or the rules for the network zone, not from the vendor. Confirm with your security team whether a pull-only integration that writes into a SaaS endpoint counts as an exception, because most isolation policies treat any outbound path as a finding.

A Backstage portal in an isolated network needs internal versions of the services it depends on: a Git server for catalog-info.yaml files and templates, an identity provider reachable from inside the network, a container registry for the images you build, and a PostgreSQL database. Backstage is Apache-2.0 licensed and has no paid edition from the project, so the software itself carries no subscription. Your recurring costs are the infrastructure, the platform team and the plugin maintenance. Before you commit, check that every plugin, template and documentation build you need works without fetching packages or assets from the public internet, and plan a process to mirror the Backstage release line you adopt, following the Backstage versioning policy.

What an air-gapped developer portal must support

An isolated network removes the internet from the portal's dependency chain, so every source, identity provider, registry and update path must be inside the boundary. Each requirement below is a decision the platform team makes before installation, and each one fails quietly if it is left to later.

No outbound internet access

The portal must start, build and serve pages with no call to a public host. Check every plugin, npm package, base image and TechDocs theme for hidden fetches, such as remote fonts, analytics scripts or package registry lookups during the build. Build the portal image in a connected staging zone, then move the artifacts across. Test the running portal with egress blocked at the network layer, not just at the firewall policy you intend to apply.

Internal Git and documentation sources

The software catalog reads catalog-info.yaml files and TechDocs builds Markdown next to code, so both depend on your internal Git server being reachable from the portal. Confirm that the catalog discovery settings point to internal repository URLs and that the TechDocs build step does not need to reach an external storage bucket unless you have deployed one inside the network. Decide early how documentation is published and rebuilt when a repository changes.

Internal identity and sign-in

Backstage ships 19 authentication providers, including GitHub, GitLab, Google, Azure, Okta, Auth0, OneLogin, Bitbucket, Cloudflare Access, AWS ALB, Google IAP and generic OIDC. Most of these are cloud or SaaS identity services, so an isolated network usually needs a generic OIDC provider or a self-hosted identity system that the portal can reach. Configure sign-in resolvers so every provider maps to the same identity, and leave guest access off in production.

Internal image and package registries

Portal plugins, the Backstage container image and the Node.js dependencies must come from registries inside the network, such as a private container registry and a package mirror. Mirror every dependency the build resolves, including transitive packages, and keep a signed record of what was imported. Confirm which Node.js release line your Backstage version supports, since the versioning policy limits support to two adjacent even-numbered releases.

Database and caching choices

Backstage uses PostgreSQL in production and SQLite for development, and gives each backend plugin its own logical database through Knex. Caching can use Redis, Memcache, Infinispan or in-memory storage. Keep PostgreSQL and any Redis instance inside the isolated zone with their own backup schedule, and confirm that the chosen cache is deployed inside the boundary rather than in a managed service outside it.

Offline updates and security patches

Backstage ships a monthly main release line and a weekly next line, and the versioning policy says high and critical vulnerabilities are backported to releases from the last six months where feasible. An isolated network must import each release and patch through a controlled path, so plan a recurring intake process with a named owner. Ask your team to confirm the upgrade process against the keeping-updated guide before the first install.

How each option handles isolation

Port's portal itself is delivered as a SaaS application that Port operates. The user interface, the catalog that users browse, and the self-service action pages all live in Port's environment, so the portal cannot run inside a network with no route to the internet. Users inside an isolated network would need outbound connectivity to reach the portal at all, which most air-gapped designs prohibit.

Portal location: the web interface and catalog data are hosted by Port, not inside your network.
Vendor calls: every user session and catalog read or write depends on a live connection to Port's service.
Data residency: entity metadata and integration data are stored in Port's hosted environment.
Offline operation: not available for the portal itself, regardless of how the surrounding tooling is configured.

Before assuming any hosted option is unsuitable, confirm with Port in writing which components, if any, would be permitted in your enclave and what network access they require.

How to deploy Backstage fully offline

This sequence takes a Backstage portal from packages mirrored into your network to a running, upgradeable portal that needs no outside connection. Each step ends with a check you can run inside the isolated network before moving on.

Mirror Backstage packages and plugins internally
The platform team, working with whoever controls your build network, copies the Backstage npm packages, the plugins you chose and their dependencies into an internal package registry. Build the portal once on a connected staging machine, then confirm that a clean install from the internal registry succeeds with no outbound requests. Confirm the Node.js runtime you use is one the versioning policy supports, which as of Backstage 1.46.0 is Node.js 22 or 24, and mirror the container base images the same way. The output is an internal artifact set that installs without internet access.
Host catalog and TechDocs sources in internal Git
Move the catalog-info.yaml descriptor files and the Markdown sources for TechDocs into your internal Git server, next to the code they describe. Backstage catalog kinds such as Component, API, System and Group are defined in these descriptors, and TechDocs builds MkDocs sites from Markdown kept beside the code. Point the catalog Location entries at internal Git URLs and confirm that a sync reads every descriptor and that a TechDocs build completes with the MkDocs plugins you installed. The output is a catalog that populates from internal repositories only.
Configure PostgreSQL and caching inside the network
Provision PostgreSQL in the isolated network for the production database, since Backstage uses PostgreSQL in production and gives each backend plugin its own logical database through Knex. Choose a cache backend from Redis, Memcache, Infinispan or in-memory, based on your sizing and whether you run more than one instance. Store database credentials in your internal secrets tooling rather than in the configuration file. The check is a successful backend start that creates the plugin databases and reads and writes the cache with no external endpoints.
Connect internal identity with a sign-in resolver
Configure one of the 19 built-in authentication providers against your internal identity system, such as an internal OIDC server, and set a sign-in resolver so every provider resolves to the same user identity. Without this, the same person can appear as two catalog users when they sign in through different routes. Test sign-in with at least two providers if you use more than one, and confirm that the resolved user matches the directory entry. The output is a single identity per person that your access rules can depend on.
Disable guest access and verify access rules
Turn off guest access in the production configuration, because the authentication documentation advises against it. Then confirm that an unauthenticated request to the catalog, TechDocs and templates is refused, and that a signed-in user sees only what your permission policy allows. Record the configuration change and the test results in the change record your auditors will read. The check is a failed unauthenticated request and an audit log entry for each sign-in.
Build the offline release and publish it internally
Build the backend and frontend bundles and the container image from the mirrored packages, then push the image to your internal registry such as Harbor. Deploy to your internal Kubernetes or VM target, referencing only internal image and package addresses. Run a network egress test from the portal host to confirm that it cannot reach public endpoints, while internal Git, PostgreSQL, identity and the registry remain reachable. The output is a running portal whose dependencies all resolve inside the enclave.
Plan offline upgrades on the versioning cadence
Track the main release line, which ships monthly on the Tuesday before the third Wednesday of each month, and the next release line, which ships weekly on Tuesdays. Your team downloads releases on a connected staging network, repeats the mirror and build steps, tests the upgrade in a non-production copy, and then moves it across your approved transfer process. Follow the policy's backport rule: high and critical vulnerabilities are backported to releases from the last 6 months where feasible, so keep your running version inside that window. Confirm the cadence and transfer process with your security team before the first upgrade.

Evidence assessors ask for in isolated environments

Assessors judging an isolated Backstage portal look for proof of what the boundary is, what software runs inside it, and how it recovers and gets patched. The four to six artifacts below connect those answers, so each claim about the offline setup can be traced to a record. Independent auditors decide what is sufficient for your assessment, and DeployOpen prepares these artifacts but does not issue audit reports.

Network boundary diagram

A current diagram shows the isolated network, every ingress and egress point, and the internal Git, identity provider, image registry and package mirror that the portal depends on. It should state plainly that no egress path to the internet exists. Ask the network team to confirm the diagram against firewall rules and routing tables, not against the original design. Assessors often test this first, so mismatches between the diagram and the live configuration are costly.

Dependency and plugin inventory

List every npm package, Backstage plugin, container image and Node.js runtime the portal uses, with exact versions and the internal mirror or registry each came from. Backstage supports two adjacent even-numbered Node.js releases, so record which pair is in use. Keep the inventory generated from the lockfile and image digests so it stays accurate after each update.

Sign-in configuration records

Keep the authentication provider settings, the sign-in resolver logic that maps each provider to one identity, and a record showing guest access is disabled in production. Store the configuration in version control with change approvals. Assessors will ask who can change these settings and how changes are reviewed, so include the approval trail alongside the files.

Backup and restore test records

Document what the portal stores, including the PostgreSQL databases that each backend plugin uses, and the schedule and location of backups inside the enclave. A backup is only evidence once a restore has been tested, so record the date, scope and result of each restore exercise and any gaps found. Confirm that backups stay inside the isolated network and that their encryption keys are held separately.

Upgrade and backport log

Record each upgrade, the release line it came from, the staging test results and the production change date. Backstage backports high and critical severity fixes to releases from the last six months where feasible, so track which fixes reached your version and which were pending. Keep a list of vulnerabilities you reviewed and decided not to fix, with the reason and owner for each decision.

Questions buyers ask about offline Backstage and Port

Can Port run fully inside an air-gapped network?

No. Port's portal itself is delivered as a SaaS service, so it cannot run inside an isolated network. Port's integrations are the part that can be self-hosted: its data integrations, most built on the Ocean framework, can be hosted by Port or self-hosted in your infrastructure with Helm or Docker, according to Port's installation documentation. Confirm with Port exactly which components reach its cloud and what traffic they need before you rely on any offline design.

What does a self-hosted Backstage deployment cost in components?

Backstage itself is free to use. It is an Apache-2.0 framework with no paid edition from the project, so the cost sits in the components around it. Expect recurring costs for the infrastructure that runs the portal and its PostgreSQL database, the internal Git, identity and image registry services it depends on, and the plugin maintenance that follows each upgrade. The largest one-time cost is usually build work: catalog descriptors, templates, sign-in resolvers and offline documentation pipelines. Platform team time is the cost most teams underestimate. Ask any provider for a fixed-scope written quote that lists each component separately, with who pays for it and what recurs each year.

How long does an offline Backstage deployment take, and what drives it?

The duration depends on the scope agreed in writing, not on a standard timeline. The main drivers are the number of identity providers to connect, how many internal repositories and registries must be mirrored, how many catalog entities and templates exist, whether TechDocs builds need to run offline, and how many plugins are needed beyond the core features. Core built-in features are the Software Catalog, Software Templates and TechDocs. Each plugin adds configuration and testing. Ask for milestones, dependencies on your teams and the acceptance criteria for an offline test before you accept a timeline.

What must our team provide for an air-gapped Backstage portal?

Your team supplies the environment and the access decisions. You need the target infrastructure, internal Git hosting, an identity provider that can be reached inside the network, an internal container image registry, and a PostgreSQL database for production. Backstage supports a range of authentication providers, including GitHub, GitLab, Azure, Okta and generic OIDC, so the sign-in path must match what your network already runs. Name an owner for catalog data, for template approvals and for upgrade windows. Ask any provider to list these prerequisites in the written scope so that gaps are found before build starts.

Can our own engineers deploy and run Backstage without a partner?

Yes, in principle, if your team has Node.js, Kubernetes or container, and identity skills and time for the work. Backstage is open source, so there is no license to request. The effort lies in building and maintaining the portal, its plugins and its offline supply chain. The Backstage authentication documentation advises configuring sign-in resolvers so every provider resolves to the same identity and not offering guest access in production, which needs someone who understands both identity and the framework. Decide which parts stay in-house and which are bought as a fixed-scope engagement with a written deliverable list.

How do Backstage updates reach an offline network?

Updates must be brought in by your own process, because an isolated network cannot pull them directly. Backstage ships a main release line monthly and a next release line weekly, according to its versioning policy. High and critical severity vulnerabilities are backported to releases from the last 6 months where feasible. Plan a regular intake: review release notes, mirror the packages and container images you need, test them in a staging environment, then promote them. Confirm the intake cadence and the patch window you can sustain, and whether the provider includes upgrades in a retainer.

Is Backstage licensed, and is there a paid edition?

Backstage is licensed under the Apache License 2.0, and the project itself offers no paid edition. The CNCF accepted it on September 8, 2020 and moved it to the Incubating maturity level on March 15, 2022. The licensing cost you still carry is for the surrounding services you choose, such as commercial Git hosting, identity or support contracts. Unlike Port's subscription, nothing in Backstage's license limits offline use. Confirm the license terms of any third-party plugin or service you add, since each one has its own terms.

What should we ask for in a fixed-scope written quote?

Ask for a quote that follows from a written scope listing deliverables, timelines and acceptance tests. DeployOpen does not publish a price list. Its engagements are usually fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and testing are available as retainers. Request a line for each component: infrastructure set-up, offline supply chain, identity integration, catalog and template build, documentation, testing, handover and any recurring retainer. Ask which items are one-time and which recur, and which of your teams' tasks are assumed in the price.

What to confirm with Port and your own environment

Start by getting Port's current position on fully offline use in writing. The supplied Port documentation describes its data integrations, most built on the Ocean framework, as either hosted by Port with a configurable resync interval or self-hosted in your infrastructure with Helm or Docker. Read the hosted by Port installation type page closely, then ask your Port account team to confirm whether the portal itself, its authentication flow, and its license validation can operate with no outbound route from your network. Do not assume the answer from the integration docs alone. Record the reply with the date and the named contact.

Build an egress map for every integration you plan to keep. For each Ocean or custom integration, list the source system it reads, whether the integration runs in your cluster or in Port's hosted runtime, and which destination hosts it must reach. Pay particular attention to the resync schedule, because a hosted integration needs a route from Port to your source system, while a self-hosted one needs a route from your cluster to Port. Your security team should confirm each rule against your firewall and proxy policy. Anything that cannot be explained by an internal address is a finding to resolve before the design is approved.

Test internal registry and identity compatibility against the components you will actually run. For Backstage, confirm that your internal Git server, container registry, and identity provider match a supported authentication provider or a generic OIDC path, and that the sign-in resolver maps every provider to the same identity. Check that your Node.js image mirror carries the Node.js releases Backstage supports for the version you select, and that your internal package mirror serves every npm dependency your build needs. Run a full build and deploy in a network with no internet route before you treat the design as proven. Keep a short register of what you verified, what you assumed, and who owns each open item.

How DeployOpen deploys Backstage in isolated networks

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For an isolated Backstage portal, that means scoping the internal Git, identity, image registry and documentation dependencies first, then building and handing over a portal that runs without outside connections.

How we scope

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
The written scope lists which catalog sources, templates, identity providers and registries the portal must reach inside the network
We map every package, container image, plugin and documentation dependency that must be mirrored into the isolated environment
We confirm which Node.js and Backstage release lines your teams will standardize on and how upgrades will be staged

How we build

We deploy Backstage into your own cluster or virtual machines, using PostgreSQL for the portal's backend databases
We connect the portal to your internal Git forge, identity provider and image registry, with sign-in resolvers that map each provider to one identity
We set up offline TechDocs builds and test that catalog-info.yaml files and software templates work with no external calls
We run security testing against the portal and its integrations, and document the findings and fixes

How we hand over

You receive architecture, configuration and runbooks covering the full offline build, mirror and update process
We document the procedure for importing new plugin versions and security fixes through your approved transfer channel
Your team is trained to operate the portal, manage catalog entities and run the upgrade steps without our involvement
We prepare control evidence and system documentation for your compliance team, while independent auditors issue any assessment

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover
Retainers can cover monitoring of Backstage release lines and staging of security backports into the isolated network
Ask any provider which backup, restore and disaster recovery steps they include for the portal database and catalog data
Confirm in writing who owns the mirrored artifacts, credentials and the transfer process after the engagement ends