Self-hosted Qlik alternative for air-gapped networks

Qlik's signed license key needs a path to its license backend, so isolated networks need a deliberate activation plan. Apache Superset and Metabase can run offline, with different license and plan conditions.

Book a callTalk to us
On this page

Why an air-gapped network changes the Qlik decision

If your Qlik Sense Enterprise on Windows deployment sits on a network with no route to the internet, the first question is whether activation, installation and upgrades can finish without one. Qlik's signed license key depends on internet access to Qlik's license backend. The License Enabler File is the alternative path for isolated networks, so ask Qlik whether it applies to your contract and to the client-managed release you run. Get that answer in writing before any other planning, because an install you cannot activate is an install you cannot use.

That leaves two options. The first is to keep Qlik on its activation path, using the License Enabler File if Qlik confirms it fits your deployment, and to plan offline installs and release upgrades around Qlik's own media and documentation. The second is to run Apache Superset or Metabase entirely offline. Superset is licensed under Apache-2.0 and has no paid edition, so its cost sits in infrastructure and people. Metabase's free Open Source edition is AGPL-3.0, but its pricing page places air-gapped deployment on the Enterprise plan, which starts at $20,000 per year. Confirm with Metabase what the open-source image may be used for in a disconnected environment before you choose it.

Whichever path you take, the offline work follows the same pattern. Every package, container image, installer and upgrade file that crosses into the isolated network needs a documented check of integrity and origin. If you are subject to NERC CIP-013-2, that check is the supply chain control the standard addresses for vendor software and patches. Superset also needs a metadata database on PostgreSQL or MySQL, a user-specified SECRET_KEY and a staged upgrade with a backup first, all of which must be prepared inside the boundary. Before any purchase, name the person who owns the transfer process and confirm which upgrade windows your offline network can actually support.

What an air-gapped deployment requires from the BI layer

An isolated network changes what a BI platform must do on its own: start without calling home, install from verified media, and upgrade across a boundary. The cards below set those requirements for a Qlik replacement. Compliance leads in regulated sectors should confirm which control obligations apply to their environment.

No outbound license or update dependency

A Qlik client-managed install activates through a signed license key that needs access to Qlik's license backend, with the License Enabler File as the documented alternative. For an isolated network, list every activation, telemetry, plugin and update call the BI platform makes at startup and during use, then confirm with each vendor how that call is disabled. Superset and Metabase run from local artifacts, so the check is whether any feature you need depends on an online service. Ask vendors to confirm this in writing.

Verified offline install media

Every package, container image and dependency crossing the boundary becomes part of your supply chain. NERC CIP-013-2 addresses procurement processes that verify software integrity and authenticity for vendor software and patches, and many organizations apply the same discipline to open-source artifacts. Record the source, version and checksum of each item, and keep a signed manifest with the transfer. Confirm the applicable obligations with your compliance lead, since CIP standards apply only to specific electric sector entities.

Controlled upgrades across the boundary

An isolated BI stack needs a repeatable way to bring new releases in. Superset's upgrade guidance calls for a metadata database backup, running database upgrade and init commands, staged testing, and a review of breaking changes in UPDATING.md before moving to a new version. Metabase runs application database migrations automatically, so take a backup first and plan a single node for major upgrades. Keep a documented rollback path and a staging environment inside the isolated network.

Offline dependencies for the full stack

A BI platform rarely runs alone. Superset uses a metadata database, and optionally Redis and Celery for alerts, reports and async queries, while Kubernetes installs need images pulled ahead of time. Inventory every component and driver, including database drivers for your warehouse, and confirm each can be sourced offline. Metabase's application database should move off embedded H2 to PostgreSQL or MySQL before production, so plan that migration inside the enclave as well.

Access control that matches the enclave

Authentication should work against the directory the isolated network already runs, typically LDAP or an internal OAuth2 or OIDC provider. Superset supports LDAP and custom OAuth2 servers and maps groups to roles with AUTH_ROLES_MAPPING. Metabase's Open Source and Starter plans support Google sign-in and LDAP, while SSO through SAML or OIDC and LDAP group sync require Pro or Enterprise. Row-level permissions also sit in paid Metabase plans, so confirm which tier your access model needs.

Remote access and vendor sessions

Where administrators or vendors reach the BI platform from outside the enclave, the path needs controls. NERC CIP-005-7 requires interactive remote access to high and medium impact BES Cyber Systems to pass through an Intermediate System with encryption and multi-factor authentication, and to include methods to detect and disable active vendor sessions. Treat BI servers as in scope only if your asset classification places them there. Confirm the classification and the remote access design with your compliance lead before deployment.

How Qlik, Superset and Metabase handle offline operation

Qlik Sense Enterprise on Windows is client-managed, so the software itself can be installed inside an isolated network. The licensing step is the constraint. A signed license key normally requires the server to reach Qlik's license backend. The License Enabler File is the alternative activation path for installations that cannot make that connection, so it is the first item to confirm before any isolated deployment is planned.

  • Activation path: Confirm with Qlik that your contract and product version support the License Enabler File for an offline site, and how a replacement file is issued when entitlements change.
  • Install and patch media: Client-managed releases are named by month, such as November 2025 and May 2026. Ask how each release and its patches reach an isolated network and how their integrity is verified.
  • Dependencies: Windows servers, databases and any connectors must be provisioned from approved media inside the boundary, and each component version needs to match the release Qlik supports.
  • Licensing reports: Ask whether usage and access counts still reach Qlik's systems, and what your team must export and report manually if they do not.
  • Support window: Each client-managed release is supported for a limited period, so an offline estate needs a planned upgrade cycle that includes new media and a new license file.

Before committing, get written answers from Qlik on the License Enabler File, offline patching and the support status of your exact release.

Deploying Superset or Metabase offline, step by step

This sequence takes an approved set of Apache Superset or Metabase packages and images from a connected staging network into an isolated network, where a working instance is verified against your identity groups and backups are in place before any upgrade. It is written so your team can confirm each gate before moving to the next.

  1. Build the offline media on staging

    On a connected staging network, your engineers or DeployOpen's team collect everything the platform needs: the Superset or Metabase release artifacts, the Python wheels or the Metabase JAR, container images for the application and metadata database, the database driver packages for your warehouses, and the OS packages. Record the exact versions in a bill of materials that names each file and its checksum. The step is done when a complete media set and its manifest exist in one controlled location. Confirm current version numbers and the image list against the official installation documentation for the release you choose, since these change between releases.

  2. Verify packages and images before transfer

    Verify every item on the manifest before it leaves staging. Check the checksums and signatures the project publishes, scan the container images and packages with the scanners your security team approves, and confirm the licenses match what your procurement records show. For Superset, the Apache-2.0 license applies to the whole project, while Metabase's enterprise directory is under a different license, so confirm which edition you are shipping. Store the signed verification record with the media. The step is done when the security owner signs the manifest and the record names any exceptions.

  3. Transfer media through the approved gate

    Move the verified media across the isolated boundary using the transfer process your security policy approves, such as a one-way data diode, a controlled removable media process or an internal artifact mirror. Re-hash every file on the inside and compare it with the manifest, and load the container images into your private registry. Keep the transfer record with the change ticket. Your boundary and change owners decide the method, and NERC CIP-013-2 is a useful reference if your environment is in the energy sector, since it addresses verifying the integrity and authenticity of software carried into a controlled environment. The step is done when every hash matches.

  4. Prepare offline Kubernetes if used

    If you run Superset or Metabase on Kubernetes, prepare the cluster while it still has access to the staging network. Use kubeadm's image list command to enumerate the control plane images, pull them in advance, and push them to your private registry. When you initialize the cluster inside the isolated network, point kubeadm init at that registry with its image repository flag. For Superset, check the current Kubernetes documentation first: the Helm chart is marked deprecated in development docs, and the Kubernetes Operator is the path those docs point new deployments to. The step is done when the cluster starts and pulls every image from the internal registry without outbound access.

  5. Install the metadata database and application

    Install PostgreSQL or MySQL as the metadata database, using a version the vendor lists as supported, and create a dedicated database with its own service account. Then install the application from your offline media, pointing its configuration at the internal database. For Metabase, avoid the embedded H2 database for anything beyond a demo and set a production application database from the start. For Superset, do not run the SQLite default or the Docker Compose PostgreSQL container in production. Confirm the install commands against the docs for your version. The step is done when the application loads its login page and writes its schema to the database.

  6. Set secrets and configure group mapping

    Set a unique SECRET_KEY in the Superset configuration before first start, since the application will not start without one, and store it in your secrets manager rather than in a file on the image. Plan a PREVIOUS_SECRET_KEY entry for future rotation. Then connect identity: for Superset, configure LDAP or an OAuth2 provider reachable from inside the network and map groups to roles with AUTH_ROLES_MAPPING. For Metabase, confirm which SSO and group sync options your plan includes, because SAML, JWT, OIDC and advanced LDAP group sync are limited to paid plans. The step is done when a test user from each group lands with exactly the intended role.

  7. Test connections, alerts and access

    Test the connections your reports depend on: query each internal warehouse through its driver, confirm dashboards render and filters work, and check that any alerts, scheduled reports or async queries run, since Superset needs its caching layer and workers for these features. Confirm that access controls block users who should not see certain data, and that the audit logs are written to your log platform. Record the results in a test report that your compliance owner can review. The step is done when the test report lists each check and the owner accepts it.

  8. Back up and stage every upgrade

    Before each upgrade, back up the metadata database and store the backup in the isolated network with its own access controls. Apply the upgrade first in a staging copy built from the same offline media process. For Superset, read the upgrade notes and the breaking changes file for each version between your current and target release, then run the documented database upgrade and init commands. For Metabase, back up the application database first, reduce the cluster to a single node for major upgrades, and move through releases in sequence. Confirm the exact commands for the target version before running them. The step is done when the staging upgrade passes the same tests as production and a restore from backup has been demonstrated.

How offline upgrades work for Superset and Metabase

Upgrading Superset offline is a manual, repeatable procedure, and the sequence matters. Before any change, take a backup of the metadata database, since it holds dashboards, datasets, roles and the users table. Then review UPDATING.md in the release you are moving to for breaking changes between your current version and the target. Run superset db upgrade followed by superset init against the metadata database, and test the whole sequence in a staging enclave that mirrors production first. The upgrade documentation sets this order out, so the offline team should follow it exactly rather than improvising from memory. Confirm the SECRET_KEY and any PREVIOUS_SECRET_KEY values are carried over unchanged before the first start.

Metabase handles its own schema migrations at startup, so the offline work centers on what you transfer and when. Back up the application database first, and if the upgrade is a major one, reduce the cluster to a single node because the migration takes a lock. If you are coming from a version older than 40, step through each release in order instead of jumping straight to the target. Metabase LTS releases are supported for 14 months, while non-LTS releases usually reach end of life after 2 months. Metabase 64 is an LTS release published on 16 September 2026 with end of life on 1 December 2027, and Metabase 65 followed on 12 October 2026. Each new release, and each security fix, must cross the boundary as a verified package, so set a transfer cadence that keeps you on a supported line and confirm the current dates on the version support page before you plan.

Questions buyers ask about air-gapped BI

Can Qlik Sense be activated on an offline network?

Qlik's signed license key depends on reaching Qlik's license backend, and the License Enabler File is the documented alternative for isolated networks. Whether it applies to your contract and release must be confirmed with Qlik in writing. Ask Qlik to confirm the activation steps for your client-managed release, how license changes and renewals reach a site with no outbound connection, and how a file is re-issued if the environment is rebuilt. Qlik Cloud is hosted and managed by Qlik, so it does not fit a network that has no outbound path. Budget time for these answers before you commit to a migration date.

Is Apache Superset free to run on an air-gapped network?

Yes, the software itself carries no license fee. Apache Superset is released under Apache-2.0 and the project has no paid edition. The recurring costs sit elsewhere: servers or Kubernetes capacity, a PostgreSQL or MySQL metadata database (PostgreSQL 10 to 17 and MySQL 5.7 and 8.x are the documented versions), an optional caching layer and Celery workers if you want alerts, reports and async queries, staff time, and any support contract you choose to buy. An offline install also needs every package, container image and database driver staged inside the boundary, which is internal work that someone must own.

What does Metabase air-gapped support cost and which plan includes it?

Only Metabase's Enterprise plan includes air-gapped deployment, and the pricing page lists it by quote starting at $20,000 per year. The free Open Source edition is self-hosted with unlimited users and dashboards, but air-gapped deployment is not part of it. Starter and Pro, which add SSO and row and column level permissions on Pro, do not carry that option. Ask Metabase in writing what the Enterprise quote covers, including offline upgrade packages, support response terms, the image delivery method and the contract length. Infrastructure, database administration and staff time are separate costs that continue regardless of the license.

How long does an offline BI deployment take and what drives the effort?

No duration is fixed by the supplied material, so the timeline depends on scope. The main drivers are the number of data sources to connect, the identity method (database, LDAP, OAuth or SAML), whether the platform runs on Kubernetes, the number of dashboards or questions to rebuild, and how many upgrade cycles the staging environment must test. Kubernetes clusters can be built without internet access by pulling control plane images in advance and pointing installs at a private registry. DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask each vendor for a phased plan with named milestones.

What must the client team provide for an air-gapped BI project?

The client team supplies the enclosed hosting capacity, the approved route for moving packages and container images across the boundary, database and source system access, the identity provider, named data owners and people who can test reports. The transfer route needs a verification step for software integrity and authenticity, which is the kind of control NERC CIP-013-2 asks utilities to address in their supply chain processes. Your change approval and security teams should agree the transfer procedure, the staging environment and the rollback plan before installation begins. Missing owners for data and access are the most common cause of delay, so assign them early.

How are offline upgrades handled for Superset and Metabase?

Both platforms need a staged upgrade with a database backup first. For Superset, back up the metadata database, run superset db upgrade and superset init, test in staging, and check UPDATING.md for breaking changes between versions. For Metabase, back up the application database because migrations run automatically on upgrade, reduce a cluster to a single node for major upgrades because of a migration lock, and upgrade release by release from versions older than 40. Metabase LTS versions are supported for 14 months, which helps plan upgrade windows. Each upgrade package must go through the same transfer and verification route as the first install.

Can DeployOpen run the offline deployment and its upgrades?

DeployOpen plans, implements, customizes, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. Most engagements are fixed-scope, and ongoing support and upgrades are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification. Ask for a written scope that names which upgrades, backups and support hours are included.

Evidence assessors ask for under an isolated-network design

An isolated network is only as credible as the records behind it. The six items below are the evidence most often requested when a Qlik replacement or a self-hosted Superset or Metabase deployment runs without internet access. Assessors and certification bodies decide whether that evidence is sufficient. DeployOpen prepares the records and controls, but does not issue audit reports or attestations.

Offline package inventory and checksums

Keep a manifest of every package, container image, driver and rules file carried across the boundary, with its version and a cryptographic checksum taken on the source side. Record who approved each item and where it was staged. For Superset, that list includes the Python packages, database drivers and the chosen release such as 6.1.0. Assessors use this to confirm that what runs inside the boundary matches what was vetted outside it. Ask the vendor how they publish checksums and signatures for offline bundles.

Transfer records through the gate

Each media transfer or data diode crossing needs a log entry showing the request, the scan results, the approver, the time and the destination. Store scan outputs alongside the manifest so a reviewer can trace one file from source to deployment. Define what happens to rejected files and who may override a block. Confirm with your security team which transfer method and scanning tools your boundary policy allows before the first transfer.

License or activation documentation

Document how each product is licensed and activated without a live connection. For Qlik Sense Enterprise on Windows, this means the signed license key and the License Enabler File workflow, which needs Qlik's confirmation for your contract. For Metabase, air-gapped deployment is listed only on the Enterprise plan, so a quote and written entitlement belong in this file. Open-source components such as Superset need a record of their Apache-2.0 license, not an activation certificate.

Access and remote session records

Auditors expect records of who logged in, from which workstation, and which privileged sessions were opened for maintenance. Include the authentication source, such as LDAP or OAuth group mappings in Superset, and the role each group receives. Document how vendor or support sessions are initiated, monitored and terminated. For operational technology boundaries, NERC CIP-005-7 describes controls for interactive remote access and for detecting and disabling vendor sessions, which many assessors will compare against.

Upgrade and backup logs

Each upgrade needs a dated record: the backup taken before the change, the migration commands run, the staging test results and the rollback plan. Superset upgrades call for a metadata database backup, superset db upgrade and superset init, and a review of UPDATING.md. Metabase upgrades run application database migrations automatically, so its backup and single-node change must be recorded. Keep restore tests as evidence that backups are usable, not only created.

Vendor license terms for each component

List every component with its license and the terms that govern use inside a closed network. Apache-2.0 for Superset, AGPL-3.0 for the Metabase open source edition, and the Metabase Commercial License for enterprise code each carry different obligations, including source disclosure for network use under the AGPL. Record which edition or directory of each product is deployed. Ask counsel to confirm how those terms apply to your deployment before the design is approved.

How DeployOpen deploys BI inside 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 Qlik replacement, that means planning the offline install and upgrade path around Apache Superset or Metabase before any software crosses the boundary.

How we scope

  • Map which Qlik apps, data sources and users must keep working once the network is isolated
  • Agree in writing how packages, container images and rule sets enter the enclave
  • Confirm the metadata database, caching layer and authentication sources the target network already runs
  • Engagements are fixed-scope, with deliverables and timelines agreed before work starts

How we build

  • Stage offline installers and image bundles, checking each artifact's integrity before transfer
  • Configure the metadata database, SECRET_KEY handling and authentication mapping for the isolated network
  • Test the offline upgrade path in a staging enclave before any production change
  • Document build steps, dependency versions and any Metabase plan features your access model requires

How we hand over

  • Deliver runbooks for installs, upgrades, backups of the application database and restore tests
  • Provide the transfer procedure and evidence of how each imported package was verified
  • Walk through dashboard rebuilds and data access rules with the team that will own them
  • Hand over configuration records that support your own compliance assessment, without issuing any attestation

How we support

  • Ongoing support, upgrades and continuous testing are available as retainers
  • Retainers can cover staged release intake for each new offline bundle
  • Confirm response expectations and maintenance windows in the written scope, not in general terms
  • Independent auditors and certification bodies, not DeployOpen, issue any audit result

Sources and further reading

Related

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.
Book a callhello@deployopen.com