Why a Roadie alternative for on-premises and non-EU data is a hosting question
If a residency, sovereignty or network isolation rule rules out a SaaS portal that stores data in the EU, the question is where the portal runs, not which product has the best features. The short answer: self-hosted Backstage can run in your own data center, another region or an isolated network, because Backstage is an Apache-2.0 framework you deploy yourself. Roadie's constraint is that its hosted service keeps all data in the EU and runs as SaaS, so an organization that needs data in a specific country, a private network or no outside connectivity has to move the portal itself rather than only change a setting.
The data to place is mainly the software catalog. Backstage keeps entities described in catalog-info.yaml files alongside code, but your catalog also holds ingested entities, ownership records, scorecard results, templates and TechDocs output, and each of those lives in a PostgreSQL database and build pipeline you will own. Before you choose a host, list which of these contain data your rules classify as restricted, and which integrations (source control, identity, cloud accounts) must reach the portal over a permitted path.
The rest of this page covers the requirements you need to write down, the hosting options that fit them, and what a deployment in your environment involves. Ask your compliance and network teams to confirm which regulation or contract clause drives the constraint, because that decides whether an internet-facing identity provider, a remote update channel or a particular region is acceptable. Use that answer to set the deployment boundary before comparing options.
What a data location requirement asks of the portal
A data location requirement is less about where one server runs and more about every place portal data is written, indexed or authenticated. The cards below separate those locations, the operator of each, and the verification steps needed when software enters an isolated network.
Catalog and entity storage
The Software Catalog reads descriptor files from source control and stores processed entities in the Backstage database. Confirm that the PostgreSQL instance, its backups and any replicas sit in the approved region or facility. Also confirm where the source repositories are hosted, because a catalog that reads from an external Git provider still moves metadata across the boundary during every refresh.
TechDocs build output
TechDocs builds MkDocs sites from Markdown kept next to the code, so both the build step and the published site hold documentation that may describe internal systems. Decide whether the build runs inside the isolated network, where the generated static files are stored, and which MkDocs plugins are allowed, since a plugin that fetches remote assets can send requests outside the boundary.
Search indexes and caches
Search and caching are easy to overlook because they copy catalog content into a second store. Confirm which search engine indexes entities and documents, where that index is persisted, and which cache backend (Redis, Memcache, Infinispan or in-memory) holds session and catalog data. Each of these copies falls under the same residency decision as the primary database.
Authentication traffic
Every sign-in sends tokens and identity claims to the identity provider. If that provider is a SaaS service outside the approved region, portal access itself leaves the boundary even when the catalog stays local. Choose an identity source inside the environment, use one sign-in resolver so each provider maps to the same identity, and avoid guest access in production.
Who operates the hosting
Residency also depends on the operator. Self-hosting moves day-to-day administration to your staff or a partner working inside your accounts, so access logs, administrator rights and support sessions become part of the data location story. Ask any implementation partner where its engineers connect from and whether remote sessions are recorded.
Software entering an isolated network
Images, npm packages, plugins and Backstage releases must be fetched outside the boundary and carried in. Keep a verified copy of each artifact, record its checksum and source, and use an internal registry for container images. Where the reader works in regulated energy or critical infrastructure, NERC CIP-013-2 expects procurement processes that address verification of software integrity and authenticity, so confirm that control with your compliance team. Confirm CMMC or FedRAMP scope with the assessor before assuming either applies.
Where Roadie meets a residency rule and where it does not
Roadie is a SaaS product, and its documented data model keeps all customer data in the EU. That satisfies an EU-only residency requirement, but it does not satisfy a requirement to run the portal and its catalog on-premises, in a non-EU region, or on an isolated network with no path to Roadie's cloud. The first check is to write down the residency rule in precise terms: which data counts (the catalog entities, TechDocs output, scorecard results, audit logs, user and group records copied from your identity provider), where it may reside, and whether the rule also covers processing and support access from outside the region. Each of those answers changes whether a hosted service can meet the rule.
Ask Roadie directly whether any region other than the EU is offered, whether a dedicated or single-tenant deployment exists, and whether it can run inside a customer-controlled network or cloud account. Get the answers in writing, along with the subprocessors that touch customer data and the location of backups and logs. Do not assume a deployment option exists because the underlying framework is open source. The hosted service and the framework are separate decisions, and this page only covers what changes if you move the portal itself.
If the answer is no, the decision moves to self-hosting. Backstage is Apache-2.0 licensed, so you can deploy it in your own data center, a non-EU cloud region, or an isolated network, and the catalog stays with the catalog-info.yaml files and database you control. The trade-off is that you then operate the hosting, authentication, upgrades and backups yourself, which the sections on operating the portal and on costs cover in more detail.
Which open-source options keep the portal inside your boundary
This table compares Backstage, Port's self-hosted data integrations, Cortex self-managed and OpsLevel self-hosted against the on-premises and data location constraint. Read each row for how the option meets the constraint, what it needs to run, and where it may not fit an isolated network. The main takeaway is that Backstage is the only option here with no vendor license material, while the commercial self-managed editions still depend on a vendor key or file.
| Option | How it meets the constraint | What it requires | Trade-offs |
|---|---|---|---|
| Backstage (self-hosted) | Apache-2.0 framework you deploy in your own cluster, data center or isolated network, so the catalog and TechDocs stay with you | Kubernetes or VM hosting, PostgreSQL in production, and an authentication provider you configure | You own upgrades, sign-in resolvers, plugins and hardening; CNCF Incubating status supports long-term evaluation but does not replace your own testing |
| Port (self-hosted data integrations) | Port's data integrations can run in your infrastructure with Helm or Docker, while the portal itself is a separate Port product | Helm or Docker for each integration, and confirmation of how the Port platform component is handled in your setup | Confirm with Port whether the portal layer can stay fully inside your boundary; the hosted option is outside this comparison |
| Cortex (self-managed) | Deploys into your own Kubernetes cluster through a Helm chart, which keeps data inside your environment | A Kubernetes cluster (EKS, AKS, GKE or a local distribution), PostgreSQL, a JWT license key and an access token from the Cortex account team | The subscription continues because the self-managed edition still needs vendor license material; ask about key renewal and offline validation |
| OpsLevel (self-hosted) | Self-hosted edition installed through Replicated, so the catalog data can stay on your servers | A Kubernetes cluster (preferred) or VM, a license file from OpsLevel, and minimum sizing published in its documentation | Push-based integrations need the instance reachable over the internet, which may not fit an isolated network; the license file is still required |
| Isolated network install | Needs images, packages and plugin dependencies staged inside the boundary before install | A private container registry and a mirror of packages, with kubeadm-style offline image handling for the cluster | Confirm which integrations can run without outbound access for each option before you select one |
How self-hosted Backstage keeps catalog data in your infrastructure
The key point is that the catalog definitions live in your repositories, and the portal runs as services you deploy and operate. Each component's ownership and metadata is described in a catalog-info.yaml file that sits next to the code it describes, so the source of truth for entity definitions is your own Git hosting, not a vendor's tenant. The Software Catalog backend and TechDocs are deployed into the infrastructure you choose, whether that is your own data center, a cloud account in a region of your choice, or an isolated network. Confirm with your own environment and your data protection and sovereignty advisors which region, network segment and backup location meet your requirements, because placement is a decision you make and verify, not something the framework decides for you.
The operational data is held in PostgreSQL. Backstage uses PostgreSQL in production and gives each backend plugin its own logical database through Knex, so catalog, search and other plugin state are separated inside one database service you control. Your platform team should decide where that database runs, how it is encrypted at rest, who holds its credentials and how backups are restored and tested. Caching can use Redis, Memcache, Infinispan or in-memory options, so confirm which of these your design permits and where any cache data is written. TechDocs builds its sites from Markdown in your repositories with MkDocs, so documentation output stays where your build and hosting place it.
Identity is where data residency and access control meet. Backstage ships 19 built-in authentication providers, including GitHub, GitLab, Google, Azure, Okta and generic OIDC, so you can connect the identity provider you already run inside your boundary. The authentication documentation advises configuring sign-in resolvers so every provider resolves to the same identity, and it advises against offering guest access in production. Turn guest access off in your production configuration and verify that setting during your cutover review. Before go-live, ask your team to confirm which identity provider can be reached from the isolated network, which roles map to catalog ownership and who may edit entities.
Deploying Backstage under an on-premises or isolated network constraint
This sequence takes a Backstage portal from residency rules and an empty site to a running, isolated portal with its own database, sign-in, documentation and search, and with every artifact that crossed the boundary checked. Each step ends with a check that tells you whether the next one can start.
Confirm residency and network rules with compliance
Before any build work, the compliance lead, security team and platform owner agree in writing which data may sit in which location, whether the cluster may reach the internet at any point, and how software enters the isolated network. Ask whether the controls apply by analogy to NERC CIP-005-7 (electronic security perimeters and intermediate systems for remote access) or NERC CIP-013-2 (supply chain verification) if you operate under them, and confirm with your auditor which regimes actually bind you. Done when you hold a one-page boundary statement listing allowed data flows, the transfer method for artifacts and who approves each import.
Choose and prepare the cluster location
Select the data center, region or enclave that will host the cluster, and confirm that its storage, backups, logs and PostgreSQL volumes stay inside that boundary. Platform engineers size the nodes for the Backstage backend, the frontend and the database, and plan a separate network path for the portal's access. Done when the location, network ranges and node inventory are documented and approved by the same people who signed the boundary statement.
Build the cluster without internet access
Run kubeadm config images list on a connected staging host to list the control plane images, then kubeadm config images pull to fetch them in advance. Move those images across the boundary through your approved transfer path. On the isolated network, run kubeadm init with the --image-repository flag pointing at your private registry so the control plane never reaches a public registry. Done when kubeadm init completes and all nodes report Ready with no outbound pulls in the registry logs.
Mirror Backstage dependencies and images into a private registry
Build the Backstage application and its container images on the connected side from a pinned release, then mirror the container images, the Node.js base image and the npm packages into your private registry and internal package mirror. Record a checksum or signature for each artifact and the source it came from. Choose the release from the monthly main line described in the versioning policy and confirm that the Node.js version is one of the two supported even-numbered releases for that Backstage version. Done when a clean build on the isolated network installs and starts from mirrored content only.
Deploy PostgreSQL with one database per plugin
Deploy PostgreSQL inside the boundary with backups and encryption at rest handled by your storage team. Backstage gives each backend plugin its own logical database through Knex, so create the databases the catalog, scaffolder, auth and other enabled plugins require, and grant each plugin access only to its own database. Confirm the connection settings are supplied through secrets, not committed config. Done when the backend starts, runs its migrations and writes to each plugin database, and a restore test from backup returns the catalog to a known state.
Configure OIDC sign-in with one identity resolver
Connect Backstage to your internal OIDC identity provider, which must be reachable from the isolated network, and configure a sign-in resolver so every provider maps a user to the same identity. Do not enable guest access in production. If you use more than one provider, test that the same person resolves to one catalog User entity. Done when a test user signs in, the portal shows that user's group membership, and sign-in with guest access returns an error.
Set TechDocs and search for offline operation
Configure TechDocs to build MkDocs sites from Markdown in the repositories and serve the output from storage inside the boundary, using only MkDocs plugins and theme packages that are already in your mirror. Enable the search plugin against the database or a search engine you host internally, and confirm no feature calls an external service for indexing, analytics or assets. Done when a documentation site builds offline, renders in the portal and appears in search results.
Verify every package before upgrades
Treat each image, npm package and documentation plugin that crosses the boundary as a supply chain item: check its checksum or signature against the value recorded at the source, log who approved the transfer and keep the record with the boundary statement. Schedule upgrades on the monthly main release line, applying high and critical fixes that the versioning policy backports to recent releases, and rerun this verification and the clean build before each cutover. Done when a recorded upgrade passes the same checks and the portal runs on the new release in a test environment before production.
What you take on when the portal leaves SaaS
Moving from Roadie to a Backstage portal you host means the vendor's operations become yours. The four cards below cover the duties that most often surprise teams, and each one needs an owner, a runbook and a line in the platform team's plan before cutover.
Upgrades and security backports
Backstage ships a main release line monthly and a next release line weekly, so your team chooses which line to track and when to adopt it. The versioning policy says high and critical severity vulnerabilities will always be backported to releases from the last 6 months if feasible, but other fixes may not be. Confirm with your platform team how quickly they can apply a patch release in an isolated environment, and which Node.js versions your build pipeline supports.
PostgreSQL backups and recovery
Backstage uses PostgreSQL in production and gives each backend plugin its own logical database, so the catalog, search and auth data all sit in the database you run. Roadie handled this for you, so backups, point-in-time recovery and restore tests become your responsibility. Ask your database team who owns the backup schedule, where copies are kept inside your data location rules, and how long a restore into a clean environment takes.
Mirrored images and packages
A portal that runs inside a restricted network needs its container images, npm packages and Node.js runtime brought in from outside by a controlled process. Each artifact crossing the boundary should be scanned and recorded, which is the same supply chain control expected for regulated vendor software. Ask your security team which registry will hold the mirror, who approves imports, and how the mirror is refreshed when a security release ships.
Custom plugins and catalog providers
Roadie's own features, such as Scorecards, reach your portal through its managed plugin set, while a self-hosted Backstage portal relies on plugins your team installs, configures and rebuilds at each upgrade. Every custom plugin is code you must review, test and keep compatible with the Backstage release you run. Ask whether your engineers have capacity to maintain each plugin, and whether a plugin's source sits in a repository your organization controls.
What auditors and regulators ask to see for data location
Auditors and regulators rarely ask whether a portal is hosted in the right place. They ask you to show it. The core evidence set is an architecture diagram with explicit boundaries: which cluster, data center, region or isolated network runs the Backstage backend, where the PostgreSQL databases sit (Backstage gives each backend plugin its own logical database through Knex), which identity provider is trusted, and where every integration pulls data from. Mark the points where catalog data crosses a boundary, such as a discovery job reaching a source control system outside the enclosure. If nothing crosses, the diagram should say so, and the configuration should back that claim up.
The second category is configuration that proves placement. Keep the Kubernetes manifests, Helm values, and the app-config settings that point at databases, storage and caches under version control, and be able to show the cluster context and node pool where each workload runs. Pair this with the list of mirrored artifacts: container images, npm packages and the Node.js runtime, each with a recorded source, version and integrity check. Installing a clean cluster without internet access starts with pulling images in advance, so the mirror manifest is evidence in its own right. Ask your engineers to confirm which Backstage release line and Node.js version were approved, since the versioning policy ties supported Node.js releases to each Backstage version.
Last, collect access logs, authentication configuration, and backup and upgrade records. Auditors will want to see the sign-in resolvers that map every provider to one identity, evidence that guest access is off in production, and who can change them. Backup records should show where copies are stored and that restores were tested inside the same boundary. Upgrade records should show the monthly or weekly release applied, the review and the date. DeployOpen prepares this evidence and the controls behind it as part of implementation and handover. Independent auditors and certification bodies issue any attestation or report, so confirm early with your assessor which artifacts they accept and in what format.
Questions buyers ask before choosing a self-hosted Roadie alternative
What does a self-hosted Backstage portal cost to run compared with Roadie?
The software itself has no license fee, so the cost is the work and infrastructure around it. Expect recurring costs for the Kubernetes cluster that hosts Backstage, a managed or self-run PostgreSQL database, search and caching components, and the engineers who upgrade and maintain the portal. Plugin development and authentication setup are mostly one-time costs, though custom plugins also need upkeep. Roadie charges per developer and bills Scorecards and plan minimums separately, so compare both sides across the same three years. Ask any partner for a quote that lists each component, who pays for it, and which items recur.
How long does it take to move from Roadie to a self-hosted Backstage?
The duration depends on how many integrations, custom plugins, scorecards and authentication providers you need to rebuild, and on how your catalog is stored. Because Roadie follows the Backstage model, most entities already live as catalog-info.yaml files in your repositories, which shortens the catalog step. The reader must supply access to source repositories, identity provider settings, a target Kubernetes environment, a PostgreSQL instance and named owners who can approve the cutover. Ask for a fixed-scope written plan with milestones before work starts, so the timeline reflects your real inventory and not an assumption.
Can our platform team run a self-hosted Backstage without outside help?
Some teams can, if they already run Kubernetes, manage a database and have engineers comfortable with TypeScript and the Backstage plugin model. Plan for a monthly main release line and a weekly next line, so someone must own upgrades, and Backstage's versioning policy says high and critical vulnerabilities are backported to releases from the last 6 months if feasible. Supported Node.js versions also change with releases, as of Backstage 1.46.0 they are Node.js 22 and 24. Teams without these skills usually scope a partner for the initial build and hardening, then decide whether to keep a retainer for upgrades and support.
Is Backstage free to use, and is there a paid edition?
Yes, Backstage is an open source framework released under the Apache License 2.0, and the project itself does not sell a paid edition. Its core features include the Software Catalog, Software Templates and TechDocs, plus a plugin ecosystem. The costs appear elsewhere: infrastructure, database operations, engineering time, and any commercial services you buy to support it. Backstage was accepted to the CNCF on September 8, 2020 and moved to the Incubating maturity level on March 15, 2022. Confirm the license terms of any third-party plugin you plan to use, because plugins carry their own licenses.
Do Cortex or OpsLevel self-managed editions remove the subscription?
No. Self-hosting the commercial editions does not remove the subscription. Cortex documents a self-managed deployment into your own Kubernetes cluster with a Helm chart, but it requires a JWT license key and access token from its account team, plus a PostgreSQL database. OpsLevel's self-hosted edition is installed through Replicated and requires a license file from OpsLevel. In both cases you pay for the license, the infrastructure and the people who run it. Ask any vendor to confirm in writing what the license covers, how it renews, and whether data remains inside your environment.
Can Backstage run in an air-gapped network with no internet access?
Backstage can be deployed in a private environment, but the install needs planning. Kubernetes clusters can be built without internet access by pulling control plane images in advance with kubeadm and pointing kubeadm init at a private registry. Backstage and its plugin packages, container images, and build dependencies must also be mirrored into your internal registries and package repositories before cutover. Authentication must reach your internal identity provider, and TechDocs builds need their dependencies available offline. Ask for a written inventory of every package carried across the boundary, along with a process for verifying integrity and authenticity, which NERC CIP-013-2 addresses for vendor software and patches.
How DeployOpen deploys Backstage inside your boundary
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For a Roadie alternative on-premises or outside the EU, that means a Backstage portal, its database and its catalog built where your data is allowed to live, under a written scope agreed before work starts.
How we scope
- Confirm which environments may hold the catalog: your data center, another region, or an isolated network with no internet access.
- Inventory catalog-info.yaml files, entity kinds, API definitions, TechDocs sites and identity providers that Backstage must reach.
- Agree in writing the deliverables, boundary controls, image sources and acceptance tests before any build starts.
- Record which parts of the engagement are fixed scope and which ongoing upgrade or testing work would move to a retainer.
How we build
- Deploy Backstage on your Kubernetes or virtual machine platform, with PostgreSQL and caching placed inside your network boundary.
- Mirror container images, packages and Node.js runtimes into your private registries so the build needs no outside downloads.
- Configure authentication with sign-in resolvers that map every provider to one identity, and disable guest access in production.
- Test catalog discovery, templates, TechDocs builds and search against your boundary rules, and record the results.
How we hand over
- Document the architecture, network paths, data flows, backup and restore steps, and the monthly upgrade procedure for your team.
- Provide evidence packs that show configuration, access controls and software provenance for your compliance and assessment teams.
- Run a cutover rehearsal so ownership data and catalog entities are verified before users move from the previous portal.
- Train platform engineers on plugin changes, upgrade runbooks and the checks needed before carrying any package across the boundary.
How we support
- Offer ongoing upgrades, security patch review and continuous testing as a retainer after handover, scoped in writing.
- Plan monthly and weekly Backstage release adoption so your team can take security backports within your own change process.
- Keep a single named point of contact for incidents, plugin questions and boundary changes during the support period.
- Ask for a quote built from the written scope, with recurring retainer terms itemized separately from one-time deployment work.
