Why an air-gapped rule rules out Atlan's SaaS catalog
If your network or residency rule says metadata must not leave your environment, Atlan's standard model does not meet it. Atlan describes itself as a cloud-first, single-tenant SaaS platform hosted on AWS, Azure or Google Cloud, and the catalog itself runs in Atlan's managed environment. The only component you can place in your own network is the Self-Deployed Runtime, which reaches on-premises or VPC-locked sources. OpenMetadata and DataHub, by contrast, can run entirely inside an on-premises or air-gapped environment, with the catalog, its database and its search index all under your control. The distinction matters because a Self-Deployed Runtime still sends metadata out of your network. Connector output, lineage and catalog content are processed by the Atlan-hosted platform, so the rule is only partly satisfied. Before you decide, read the rule closely. If it covers only source credentials and raw data, a hybrid arrangement with the Self-Deployed Runtime may be acceptable to your compliance owner. If it covers schema names, column descriptions, glossary terms or lineage, which are metadata in their own right, the SaaS catalog is likely out of scope. Ask Atlan in writing which metadata categories leave your network, where they are stored, and in which region.
Confirm three things with your data protection, security and architecture leads. First, list every metadata type your rule covers, including lineage and user activity. Second, ask your legal team whether a copy of the catalog in a cloud account you do not control counts as a transfer. Third, check whether your environment can run the open-source platforms you would deploy. OpenMetadata documents production deployments on on-premises Kubernetes and bare metal, and DataHub is deployed with Helm charts on Kubernetes, so both fit an isolated cluster if you can supply the dependencies. Your air-gapped network also determines how you pull software and container images in and how you handle upgrades, which the rest of this page covers in detail.
What an air-gapped metadata rule requires of the catalog
A rule that metadata must stay inside your network turns into concrete questions about where data is stored, where the catalog runs, who signs users in, and how updates arrive. Each card below is a point to settle before choosing between Atlan, OpenMetadata and DataHub.
Where metadata is stored
Atlan's architecture documentation places its metadata store, built on Apache Atlas with Cassandra and Elasticsearch, inside the platform it hosts on AWS, Azure or Google Cloud. Only the Self-Deployed Runtime runs in your network to reach on-premises or VPC-locked sources. Confirm with Atlan in writing which metadata, logs and backups leave your network. With OpenMetadata or DataHub, the metadata store and search index sit wherever you deploy them, so the storage question becomes an infrastructure decision you control.
Where the catalog runs
Atlan is single-tenant SaaS, so the catalog application itself runs outside your environment. A self-hosted catalog moves that runtime inside your perimeter. OpenMetadata documents production deployment on on-premises Kubernetes and on bare metal, and DataHub deploys on Kubernetes with Helm charts. Check that every container image, package and model your chosen catalog pulls can be mirrored into your registry before go-live.
Identity and SSO inside the network
Atlan uses Keycloak for SSO, OIDC and SAML, which Atlan operates on its side of the boundary. In a self-hosted catalog, the identity provider and the catalog's login path both need to resolve inside your network. DataHub supports OpenID Connect providers such as Okta and Azure AD, but on DataHub Core the frontend server must be configured by your operators. Confirm that your identity provider is reachable from the catalog and that group claims map to catalog roles.
Dependencies for disconnected upgrades
A self-hosted catalog depends on a database, a search engine and, for DataHub, Kafka. Each of these must be installed from media you can deliver into the network. OpenMetadata's bare metal path requires Java 21, PostgreSQL 15 or later or MySQL 8.0.42 or later, and Elasticsearch 9.x or OpenSearch 3.x. DataHub's Helm chart runs a system-update job on upgrades that can reindex search. Ask each vendor for a documented offline upgrade procedure and test it on a disconnected staging network.
Connector traffic and source access
Catalog ingestion must reach your warehouses, BI tools and pipelines from inside the network. Atlan's Self-Deployed Runtime is the component that does this for on-premises sources, which means a piece of Atlan software still runs on your side. With OpenMetadata or DataHub, ingestion jobs run where you schedule them, and the connectors pull metadata from sources you already control. List every source and confirm each connector can reach it without outbound internet access.
Vendor support model for isolated networks
Confirm who patches the catalog and how security fixes reach a disconnected environment. Atlan operates the platform, so patches arrive through its hosted service. For OpenMetadata, Collate offers commercial support and premium features on top of the Apache-2.0 project, and DataHub Cloud is a managed product outside the open-source edition. Ask whether any support contract requires outbound connectivity, and write down who in your organization owns the patch schedule for each component.
How OpenMetadata and DataHub meet the constraint
OpenMetadata is released under the Apache License 2.0 and can be deployed entirely inside your own network. The project documents production deployment on Kubernetes, including Helm charts on Amazon EKS, Azure AKS, Google GKE or on-premises Kubernetes clusters, and also documents a bare metal installation without Kubernetes. Docker Compose is provided for evaluation rather than production.
- Bare metal prerequisites: Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x.
- Minimum server sizing: 2 vCPUs, 4 GB RAM and 20 GB storage for the server, with the database and search services each needing at least 2 vCPUs, 2 GB RAM and 30 GB storage.
- Air-gapped fit: Connectors run where your sources are, so ingestion does not need outbound access to a vendor's cloud. Confirm how you will stage container images and Python packages inside the enclosed network.
- Upgrade care: The 2.0 line has breaking changes, including moving embedding credentials into an llmConfiguration block and migrating Great Expectations to 1.3 before upgrading.
- Commercial boundary: Collate offers managed OpenMetadata, commercial support and AI features, which are separate from the open-source install.
Confirm the exact sizing for your data volume with the project's deployment documentation and a test environment, since the minimums describe a starting point rather than a production estimate.
DataHub's open-source edition is Apache-2.0 licensed and can run on your own infrastructure. A Docker quickstart is available for trials, requiring Docker with 8 GB of RAM and Python 3.10 or later. For a production footprint, the project documents deployment on Kubernetes with Helm charts from the acryldata/datahub-helm repository, plus a separate prerequisites chart for dependencies.
- Core components: GMS, the MAE Consumer, the MCE Consumer and the Frontend, supported by Kafka for streaming metadata changes.
- Storage and search: A MySQL, PostgreSQL or MariaDB database, Elasticsearch for search, and a graph index on Neo4j or Elasticsearch.
- Local sizing: The Kubernetes guide says more than 7 GB of RAM is needed to run DataHub and its dependencies on Minikube, so plan a larger cluster for real workloads.
- Upgrades: The Helm chart runs a system-update job that applies schema changes and reindexes search when needed, which your change process must allow for.
- Not in open source: DataHub Cloud adds PrivateLink connectivity and a 99.5% uptime SLA. Those are managed-service features, so an air-gapped team must plan its own availability and network controls.
Before committing, confirm with the project which Kafka and graph index options your security team accepts inside the enclosed network.
Apache Atlas is an Apache-2.0 licensed data governance and metadata framework from the Apache Software Foundation, built for Hadoop. It offers lineage, classification and integration with Apache Ranger, which enforces classification-based access control. Atlas is a framework rather than a turnkey catalog, so it suits teams that already operate Hadoop-era data platforms and have engineers to build the user experience they need.
- Hadoop alignment: Lineage and classification are designed around Hadoop ecosystem sources.
- Ranger tie-in: Classification tags can drive access policies in Apache Ranger, which is a strength for teams already standardized on it.
- Build effort: Expect to assemble discovery, business glossary and user-facing workflows yourself or with a partner.
- Connector scope: Confirm coverage for your warehouses, BI tools and SaaS sources, since Atlas does not match the connector breadth of the two catalogs above.
- Deployment: Atlas runs on infrastructure you control, so it meets residency needs, but the operating burden is higher than a packaged catalog.
Check the Atlas project site and repository to confirm the current release and supported backends before scoping any build.
Atlan, OpenMetadata and DataHub against the constraint
This table compares Atlan with the two open-source options against a requirement that metadata stays inside your own network. Read the rows as a checklist: where data sits, what runs on site, and which points still need confirmation with the vendor or in a test install before you commit.
| Requirement | Atlan | OpenMetadata | DataHub Core |
|---|---|---|---|
| Where metadata is stored | Atlan-managed single-tenant SaaS on AWS, Azure or Google Cloud | Your infrastructure, on Kubernetes or bare metal | Your infrastructure, on your Kubernetes cluster |
| Where the runtime runs | Atlan's cloud VPC; only the Self-Deployed Runtime runs in your network | Entirely on your servers or cluster | Entirely on your servers or cluster |
| Air-gapped install, as documented | Not offered; the platform depends on Atlan's hosted service | Bare metal and on-premises Kubernetes are documented; confirm offline image and dependency handling | Helm-based deployment is documented; confirm offline image mirroring and chart sources |
| SSO approach | Keycloak-based SSO, OIDC and SAML, managed by Atlan | Security docs describe the options; confirm OIDC or SAML setup on your version | OIDC configured by the operator on Core; confirm your identity provider setup |
| Licensing | Commercial subscription | Apache License 2.0; commercial enterprise features from Collate | Apache License 2.0; DataHub Cloud is a separate product |
| Connector coverage | Atlan's connector catalog; confirm coverage for your on-premises sources | 130+ connectors, documented in the project README | 150+ integrations, documented in the project README |
| Managed vendor path | Atlan is the managed service itself | Collate offers managed OpenMetadata and commercial support | DataHub Cloud offers managed, SLA-backed hosting, which needs external network access |
Deploying a self-hosted catalog inside an air-gapped network
This sequence takes a team from a scoped data classification to a catalog running entirely inside its own network, with metadata that never leaves the environment. Each step ends with a check that the previous layer works before the next one depends on it.
Confirm the rule and data classes in scope
The governance or security owner writes down which metadata may enter the catalog, which networks it may reach and whether any source is outside the boundary. Engineering then lists the sources to connect, such as warehouses, BI tools and pipelines, and marks which ones are on-premises or inside a locked VPC. The step is done when the owner signs off on a written scope that says no metadata will be sent to a vendor-hosted service. Ask the catalog vendor or DeployOpen to confirm any telemetry or license checks that could reach outside the network.
Choose OpenMetadata or DataHub
The platform team compares the two Apache-2.0 options against the scope: connector coverage for the sources listed, lineage needs (OpenMetadata supports table, column, dashboard, pipeline and metric lineage with OpenLineage events, and DataHub supports column-level lineage), SSO requirements and the team's Kubernetes or bare metal skills. The step is done when a decision record names the platform, the deployment model and the people who will operate it. Confirm current connector and feature support against each project's documentation, since both release frequently.
Mirror images, charts and packages internally
Because the network has no route to public registries, the team copies the container images, Helm charts and language packages the chosen platform needs into the internal registry, along with the prerequisite charts for databases and search. Ingestion images must include the connector libraries for each source. The step is done when a test cluster can pull every artifact from internal sources only, and the list of mirrored versions is recorded with the change ticket. Keep the mirror manifest, since it becomes the input for every future upgrade.
Provision Kubernetes or bare metal to documented minimums
The infrastructure team provisions the cluster or servers in the approved environment. For OpenMetadata, the bare metal guide lists Java 21 and minimum sizing for the server, database and search services. For DataHub on Minikube, the Kubernetes guide says more than 7 GB of RAM is needed for DataHub and its dependencies. The step is done when the nodes meet or exceed those documented minimums and pass a basic health check. Production sizing should be planned from the source count and expected metadata volume, which the vendor or DeployOpen can help estimate.
Deploy databases and search services
The team deploys the relational database and the search layer inside the boundary. OpenMetadata's bare metal prerequisites are MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. DataHub needs Kafka, a MySQL, PostgreSQL or MariaDB database, Elasticsearch for search and a graph index. The step is done when each service accepts connections from the application tier, backups are scheduled and the services survive a restart without losing configuration.
Configure SSO against the internal identity provider
The identity team connects the catalog to the internal OpenID Connect or SAML provider. DataHub's OIDC guide says self-deployed DataHub Core requires the operator to configure the frontend server, and the operator should confirm which login methods and group mappings the chosen version supports. Admin accounts should be limited and documented. The step is done when a test user signs in through the internal provider, group membership maps to the intended roles, and local fallback accounts are locked down.
Ingest sources through connectors inside the network
Ingestion runs from inside the network, so connectors reach on-premises and VPC-locked sources directly, without a relay service. Teams schedule ingestion for each source, start with one warehouse and one BI tool, and then add pipelines and classifications. The step is done when metadata from the first sources appears with the expected owners, lineage and classifications, and the team confirms that no ingestion job makes a call to an external endpoint. A network egress review on the ingestion hosts is the evidence to keep.
Configure backups and plan upgrades
The operations team backs up the metadata database and search indices on a schedule and tests a restore into a separate environment. Upgrade planning reads the release notes first. OpenMetadata 2.0 lists breaking changes, including moving embedding credentials into an llmConfiguration block, a new Databricks auth format, rebuilding custom ingestion images for Python 3.12, and migrating Great Expectations to 1.3 before upgrading. The DataHub Helm chart runs a system-update job on upgrades to apply schema changes and reindex search when needed, so teams should allow for that job in their change window. The step is done when a restore test succeeds and the first upgrade runbook is written and rehearsed.
What moving curated metadata out of Atlan involves
The first thing to plan is how the data leaves Atlan. The supplied facts do not include a published OpenAPI specification for Atlan, and Atlan's own developer guidance points to its Python and Java SDKs as the way to read metadata programmatically. In practice, that means a script or small service, run from a machine that can reach Atlan, that pages through assets and writes glossary terms, descriptions, owners, tags and custom metadata to files you control. Confirm with Atlan which SDK version and API permissions your tenant supports, and confirm that the service account used for the export has read access to every domain and glossary you need. Because Atlan is a single-tenant SaaS, the export traffic leaves your network, so agree the data handling terms and the export path with your security team before the first run.
The assets that carry real value are the curated ones: glossary terms and their definitions, ownership assignments, tags and classifications, and any custom metadata your teams added by hand. Those rarely exist in the source systems, so they are the part you must carry across. Connector-derived metadata such as table and column structure, and most lineage, is usually cheaper to rebuild by re-ingesting sources with the new catalog's connectors than to export from Atlan. Run a short inventory first: count glossary terms, list custom metadata types and note which ones are used. The effort depends mainly on the size of the glossary and on how much custom metadata sits on assets, because each custom attribute needs a target field or a documented decision to drop it.
The migration details are covered in the sibling topics: Migrate from Atlan to OpenMetadata is not the right link for that, so refer readers to the migration pages for OpenMetadata and DataHub on this site for the step-by-step process, including glossary import, replacing Self-Deployed Runtime connectors and cutting over SSO. Ask your implementation partner or internal team to produce a written mapping from Atlan objects to target objects before any data moves, and to test the import against a copy of your metadata in your own network.
Evidence assessors and security teams ask for
Assessors and internal security teams rarely accept a claim that metadata stays on-site. They ask for artifacts that show where the trust boundary sits, how the platform is configured, and how it is operated over time. DeployOpen can prepare this evidence for a self-hosted OpenMetadata or DataHub deployment, but auditors and certification bodies issue any assessment.
Trust boundary network diagram
A diagram that shows every component inside the on-premises or air-gapped network, including the catalog services, databases, search index, message broker and any runtime that reaches a source. For a self-hosted catalog, the diagram should show that no metadata path crosses to a vendor-managed VPC. Ask the team to confirm egress rules for container image pulls and package mirrors, since those are the most common hidden outbound paths.
Deployment manifests and configuration
Helm values, Kubernetes manifests or the bare metal configuration files that define each component, version pins and resource limits. Store them in version control so the state at any date can be shown. For OpenMetadata, that includes the database and search service settings listed in its bare metal prerequisites. Reviewers will check that no configuration points to an external endpoint.
SSO and access configuration
The identity provider settings, OpenID Connect client registration, role mappings and admin account inventory. DataHub Core requires the operator to configure OIDC on the frontend server, so the evidence must show who set it up and when it was last reviewed. Export the list of users and roles, and confirm that local accounts are limited and documented.
Backup and restore records
Scheduled backup jobs for the metadata database and search index, retention settings, and dated restore tests with their results. A backup that has never been restored is weak evidence. Ask the team to record which components are rebuilt from source connectors and which must be restored from backup, since that determines the recovery steps an assessor will ask about.
Upgrade and patch records
A log of each version change, the change ticket, the test results and the rollback plan. Both projects ship frequent releases, and OpenMetadata 2.0 lists breaking changes that must be handled before upgrading. For DataHub, record that the Helm chart's system-update job ran and what it changed. Confirm the patch cadence the organization will commit to in its own policy.
Inventory of ingested sources
A list of every source system connected to the catalog, the connector type and version, the service account used, and the network path to each source. This shows assessors which sensitive systems the catalog reads metadata from and whether those credentials are stored in a secrets manager. Review it against the data classification policy before the assessment starts.
Questions buyers ask before moving off Atlan for an air-gapped network
Can Atlan meet an air-gapped rule by running only its Self-Deployed Runtime on site?
No, not for the metadata itself. Atlan describes its platform as cloud-first, single-tenant SaaS hosted on AWS, Azure or Google Cloud, and the customer-side component is only a Self-Deployed Runtime that reaches on-premises or VPC-locked sources. Metadata storage, search and the application still run in Atlan's hosted environment. If your rule requires catalog metadata to stay inside your network, confirm the exact data flows in writing with Atlan's team, including where metadata is stored, what the runtime sends out and how it authenticates. Atlan architecture is the primary source to review with your security team.
What drives the cost of a self-hosted catalog in an isolated network?
The cost has several components: infrastructure to host the catalog and its dependencies, the people who install and operate it, the one-time migration and integration work, and recurring upgrades and support. Infrastructure cost rises with the number of sources, the volume of metadata and how many search and graph services you run. OpenMetadata's bare metal documentation lists minimum sizing for the server, database and search services, while DataHub's Kubernetes guide notes the memory needed for a local trial. Ask any implementation partner for a fixed-scope written quote that separates one-time work from recurring operations.
How long does a move off Atlan to a self-hosted catalog usually take?
The duration depends on the number of connectors to rebuild, the size of your glossary and ownership data, how many teams need cutover and how much SSO and network work is required in an isolated environment. No timeline is fixed by the platforms themselves, so treat any number from a vendor or partner as an estimate until it appears in a written scope. Ask for phases, deliverables and acceptance criteria for each one, including a pilot source and a rollback path.
What does our internal team need to supply for an on-premises catalog?
Your team needs to provide the target infrastructure, typically Kubernetes or bare metal inside your network, along with database and search services, identity provider access for SSO, and owners for each source system and its credentials. Engineers also need to own connector configuration, scheduled ingestion and access policies. Someone must be accountable for the catalog after go-live, including backups and a patch process. List these responsibilities in the scope so gaps are visible before work starts.
Can our own engineers run a self-hosted catalog without outside help?
Yes, many teams can, provided they have Kubernetes or Linux operations skills, database administration experience and someone who understands the connectors to their sources. Both OpenMetadata and DataHub publish deployment guides, and both projects are Apache-2.0 licensed. The harder parts are usually the air-gapped logistics, SSO configuration, the migration of curated metadata and the upgrade routine. Outside help is most useful for a fixed-scope hardening and cutover, and for an ongoing retainer for upgrades and testing if your team does not want to carry those duties alone.
Should we choose OpenMetadata or DataHub for an air-gapped network?
Choose based on your sources, operating model and governance needs. OpenMetadata documents production deployments on Kubernetes and on bare metal, with prerequisites of Java 21, a supported relational database and Elasticsearch 9.x or OpenSearch 3.x. DataHub runs on Kubernetes with Helm charts and depends on Kafka, a relational database, search and a graph index. Compare the connectors for your specific systems, the lineage and quality features you need, and how much streaming infrastructure your team is willing to operate. Run a pilot with your own sources before deciding.
How are upgrades handled when the network has no internet access?
Upgrades in an air-gapped network mean building or mirroring container images, charts and packages inside your boundary, then testing them against a copy of your data. OpenMetadata 2.0 includes breaking changes, such as moving embedding credentials into a new configuration block and migrating Great Expectations to 1.3 before upgrading, so read release notes before each change. DataHub's Helm chart runs a system-update job that applies schema changes and reindexes search when needed. Ask for a written upgrade runbook covering offline artifact transfer, rehearsal and rollback.
When Atlan's managed service is still the better fit
Keep Atlan's managed service if your requirement is narrower than a full on-premises rule. If the policy only restricts where source connections run, the Self-Deployed Runtime may satisfy it, because Atlan's architecture documentation describes that component as the only part customers run in their own network to reach on-premises or VPC-locked sources. In that case the catalog itself, with its metadata store, search and SSO, lives in Atlan's cloud, and a self-hosted catalog would add platform work without changing the answer your auditors care about.
A managed SaaS also carries less operational load. Atlan runs the single-tenant platform, handles upgrades and keeps the underlying services running, so your team does not need Kubernetes, Kafka or search cluster skills to operate the catalog. Compare that against the staffing you would need for OpenMetadata or DataHub, including on-call coverage and upgrade testing. Ask Atlan for the hosting region, the list of subprocessors and the retention terms for metadata and logs, and confirm whether any metadata sent to Atlan's cloud ever leaves the cloud region you select.
Before you rule Atlan in or out, get the answer in writing. Ask Atlan which data and metadata leave your network under your contract, including sample values, query history, lineage details and AI features, and whether the Self-Deployed Runtime sends only results or also metadata. Map each answer against your data classification policy and the exact clause that triggered this review. If the written answer confirms that only connector traffic stays local and your policy accepts that, Atlan's managed service may remain the right choice.
How DeployOpen deploys a catalog inside your network
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including air-gapped networks. For a metadata catalog, that means OpenMetadata or DataHub runs entirely on your servers or Kubernetes cluster, with the connectors, identity provider and backup path agreed in writing before any build work starts.
How we scope
- Engagements are fixed-scope, with the catalog platform, sources and teams agreed in writing before work begins.
- The written scope lists which metadata sources stay on site and which connectors run inside your network.
- We confirm the identity provider, single sign-on requirements and whether your network allows any outbound traffic at all.
How we build
- We deploy the chosen platform on your Kubernetes or bare metal hosts, with its databases and search service inside your network.
- We configure single sign-on, role assignments and connectors for each source you approved, including sources only reachable on-premises.
- We test ingestion, lineage and access controls against your own sources and record the results for your review.
How we hand over
- You receive configuration documentation, runbooks for upgrades and restores, and a record of the controls we implemented.
- We walk your platform and security teams through daily operation, ingestion failures and the upgrade procedure.
- We prepare evidence of configuration for your compliance reviewers, while independent auditors remain responsible for any assessment.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
- Upgrade planning covers the breaking changes and prerequisite steps in each release before your teams apply it.
- Ask for a quote based on the written scope, and confirm which upgrade and backup responsibilities sit with your team.
