Why a self-hosted vector database in air-gapped networks needs its own plan
A self-hosted vector database can run in an air-gapped network, but only if the install is planned for offline packaging from the start. Qdrant and Milvus are the dedicated engines to evaluate, and pgvector is the option when PostgreSQL is already run and approved in the enclave. The deciding factor is rarely search quality. It is whether every image, chart, package, model file and upgrade artifact can be carried across the boundary and verified on the other side. Your enclave team is the one that will be asked to explain why a given component entered the network, so the offline path belongs in the selection criteria, not in a later project phase.
Several assumptions in a normal install break inside an isolated network. The default path pulls container images and Helm charts from public registries, so you must mirror them into a private registry and record exact tags and digests. Embedding models are usually downloaded on first use, so the model weights, tokenizer files and their versions must be imported as controlled artifacts. Managed upgrades and cloud-hosted dependencies disappear, so the upgrade procedure is yours to test. Storage is the least obvious break: Qdrant needs block-level storage with a POSIX-compatible file system and cannot run on NFS or S3-style object storage, so confirm that your enclave platform provides SSD or NVMe-backed block volumes before anything else is scheduled. Also confirm that snapshots restore only into a matching Qdrant version, and plan a restore test in the enclave.
Treat security as a precondition, not a hardening step. By default, self-deployed Qdrant instances listen on all network interfaces and have no authentication configured, so an instance placed in the enclave unchanged is open to every host that can reach it. Before deployment, enable API keys, TLS for REST and gRPC, and per-collection access control, and confirm the audit logging you need for your assessors. Milvus provides authentication, TLS and role-based access control, and pgvector inherits the database's roles and permissions. Whichever engine you choose, ask your implementation partner to show the secured configuration in a test enclave and to document it, because an unsecured vector store holding internal documents is a data exposure, not an operational inconvenience.
Requirements the air gap imposes on the vector store
This table maps each requirement an isolated network places on a self-hosted vector store to the source that defines it, what it means for the build, and what an assessor will expect to see. Read each row as a build decision you must document before the first node is installed. The main takeaway is that offline installation, block storage, authentication and verified transfers are design inputs, not hardening steps added later.
| Requirement | What it means for the build | Evidence to keep |
|---|---|---|
| Offline installation of cluster and images | Mirror every container image and chart into a private registry, then point kubeadm init at it with --image-repository. Pre-pull control plane images with kubeadm config images list and pull. | Image manifest with digests, registry inventory, install logs showing no outbound pulls |
| Vector store deployment path | Choose the Helm chart or enterprise operator and confirm which features (zero-downtime upgrades, shard rebalancing) you need. Import the chart and images from the approved transfer set. | Chart version, values file under change control, list of images transferred |
| Block storage on nodes | Qdrant needs block-level storage with a POSIX-compatible file system and does not run on NFS or S3. Milvus separates object storage (MinIO, S3 or Azure Blob) from its write-ahead log, so plan both explicitly. | Storage class configuration, disk type (SSD or NVMe where recommended), mount and filesystem records |
| Default-insecure configuration | Qdrant instances listen on all interfaces with no authentication by default. Enable admin and read-only API keys, per-collection JWT permissions and TLS for REST and gRPC before loading data. | Configuration files, key rotation records, TLS certificate inventory, access test results |
| Audit logging of API operations | Enable JSON audit logging of authenticated Qdrant API operations and forward logs to storage inside the enclave. Confirm equivalent audit capture for Milvus RBAC events. | Log configuration, sample audit records, retention settings |
| Supply chain verification across the boundary | Under NERC CIP-013-2, verify integrity and authenticity of vendor software and patches before import. Use a signed transfer procedure with checksums for every image, chart and model file. | Signed transfer log, checksum verification records, approver sign-off for each import |
| Version-matched snapshot restores | Snapshots restore only into a matching engine version, so keep the server version, snapshot and chart versions recorded together and test restores on an isolated staging cluster. | Backup inventory tied to engine version, restore test reports, version compatibility matrix |
| Enclave in a BES Cyber System | Where the enclave is part of a BES Cyber System, NERC CIP-005-7 requires Interactive Remote Access through an Intermediate System with encryption and MFA, plus detection and disabling of active vendor sessions. | Electronic Security Perimeter diagrams, remote access logs, vendor session termination records |
Which vector engines fit an isolated network and why
Air-gapped vector search depends on three things: an engine that installs from images and charts you carry in, storage that behaves like local block devices, and a backup path that does not need the vendor's cloud. The options below differ on each, so the choice should follow your team's operating model as much as the feature list.
Qdrant on your own Kubernetes
Qdrant is Apache-2.0 licensed and free to self-host, and it can be deployed from a community Helm chart or, with a Qdrant Private Cloud agreement, an enterprise Kubernetes operator. The community chart lacks enterprise features such as zero-downtime upgrades and automatic shard rebalancing, so plan upgrades and rebalancing by hand if you take that path. Qdrant Hybrid Cloud is priced through Qdrant sales, so ask whether it can run with no outbound connection before you assume it fits. Confirm that any licence check or telemetry is disabled in your build.
Milvus in standalone or distributed mode
Milvus is Apache-2.0 licensed and offers Standalone and Distributed modes. Distributed mode depends on etcd for metadata and an object store such as MinIO for data, plus a write-ahead log such as Woodpecker, Kafka or Pulsar, so every one of those services must be mirrored and patched inside the boundary. It adds BM25 full-text search, hybrid dense and sparse search, and RBAC with TLS. Confirm the offline image list for each dependency before you commit to the design.
pgvector on an existing PostgreSQL
pgvector adds vector columns and indexes to PostgreSQL, so it fits where the database team already runs backups, replication and failover inside the isolated network. It avoids a second stateful system to certify, restore and patch. The trade-off is that filtering, index tuning and memory use then compete with transactional workloads. Ask the database team which vector index types and dimension limits your PostgreSQL version supports before you size the instance.
Managed Qdrant Cloud and Zilliz Cloud
Qdrant Cloud and Zilliz Cloud are hosted services that depend on the vendor's internet-reachable control plane, so neither fits a no-internet requirement. Zilliz offers Serverless, Dedicated and bring-your-own-cloud options, but each still depends on vendor-operated management. Use them only as a reference for sizing or as a comparison point, and document the reason for exclusion in your architecture decision record.
Confirm licences for each component
Some vendors gate offline deployment behind paid editions. Mattermost lists air-gapped deployment in Enterprise Advanced, and Metabase offers it only on its Enterprise plan. Vector engines and their dependencies may carry similar terms, so check the licence and edition for every image, chart and model you carry in, not just the core engine. Record the result, because a licence gap discovered after the boundary is sealed is expensive to fix.
How the offline rollout runs, phase by phase
The sequence moves a vector database from an agreed requirements document to a tested, handed-over system inside a network with no internet route. Each phase closes with a written artifact that the next phase depends on, so gaps surface before any user touches the platform.
Sign off scope and requirements
DeployOpen and the client agree in writing on the target vector engine, the Qdrant, Milvus or PostgreSQL with pgvector option, expected collection sizes and vector dimensions, the embedding model, authentication and RBAC rules, backup and restore targets, and the licence terms each component carries. The output is a signed requirements record and a scope document that sets out what is deployed, who operates it and what is excluded. Nothing is downloaded until both documents are approved.
Build the offline artifact manifest
On the connected side, DeployOpen lists every container image, Helm chart, operating system package, embedding model file and rule set the cluster will need, including transitive dependencies, and records version and source for each. The output is a bill of materials and a set of hash-verified artifacts. The client's security team reviews the manifest, and the transfer through the approved media or cross-domain process happens only against that signed list.
Mirror images and charts to a private registry
Inside the isolated network, the transferred images and charts are loaded into a private container registry and chart repository. For Kubernetes, the cluster is initialized with kubeadm pointed at that private registry rather than public image sources. The output is a registry catalog that matches the manifest one-to-one, with a check that every image pulls and every chart renders without outbound access. Any artifact that is missing or does not match its recorded hash is returned to the transfer step.
Import and verify the local embedding model
The embedding model weights, tokenizer files and inference runtime are loaded onto the platform and tested with a fixed set of sample documents. DeployOpen confirms that the output vector dimensions match the collection schema and that repeated runs on the same input return consistent vectors. The output is a model record with checksums, the dimension count and the test results, which later also serves as evidence of which model produced each stored vector.
Build storage and the cluster on block devices
Nodes are provisioned with local or block-level volumes with a POSIX-compatible file system, and the build avoids network file systems and object storage for vector data. Qdrant documents that it cannot run on NFS or S3, and Milvus uses object storage only as a separate backing layer that must also be local to the network. DeployOpen confirms the disk type, sizing against the agreed vector count and replication factor, and that every cluster component starts and reaches a healthy state. The output is a build record with storage class configuration and a health report.
Harden the platform before user access
Before any user or application connects, DeployOpen closes default exposure. Qdrant instances listen on all interfaces and ship without authentication by default, so API keys, TLS for REST and gRPC, per-collection permissions and audit logging are configured first. Milvus authentication, TLS and role-based access are set in the same way, and network policies restrict traffic to named services. The output is a hardening checklist with each setting verified by a test request that fails when unauthenticated.
Rehearse restore with a version-matched snapshot
A snapshot is taken from a loaded test collection, then restored into a clean cluster built from the same versioned artifacts from the manifest. DeployOpen compares point counts, payload samples and search results against the source to confirm the restore is complete. The output is a signed restore record that names the engine version, snapshot identifier, timings observed and any differences, and it becomes the basis for the operations runbook.
Hand over runbooks and evidence
DeployOpen transfers the bill of materials, hash records, configuration baselines, hardening results, restore record and runbooks for upgrades, re-embedding and artifact intake to the operations team. The client's staff run a supervised restore or upgrade rehearsal to confirm they can operate the platform alone. The output is a handover acceptance record. Any future update follows the same manifest, transfer and verification path, so the offline boundary stays documented.
How embeddings and artifacts get into the enclave
The embedding model must be imported into the enclave, pinned to one exact version, and recorded alongside the index it produced. Query vectors and document vectors are only comparable when both come from the same model and settings, so a silent model update at the vendor or a mirror that serves a different build can break retrieval without any error. Store the model file, its checksum and its configuration in your artifact repository, and make re-embedding the full collection a planned change, not a side effect of an upgrade. Ask the vendor or model publisher to confirm the license terms for commercial internal use, any restrictions on fine-tuning or redistribution, and whether the license requires notices in your deployment.
Everything else that crosses the boundary needs the same discipline. Mirror container images and Helm charts into an internal registry, then point the cluster at it. For a Kubernetes control plane, kubeadm config images list and kubeadm config images pull fetch the required images in advance, and kubeadm init accepts --image-repository to read from your private registry. Scan each image and chart, verify signatures or digests where the publisher provides them, and keep a record of what was approved. NERC CIP-013-2 describes the same expectation for vendor software and patches in its supply chain controls, so treat this as evidence you will need, not only a technical step.
Local model serving is a separate decision from the vector store. Open WebUI documents running entirely offline with Ollama or with OpenAI-compatible APIs, which is a useful reference for how a local model endpoint behaves in a disconnected setup. vLLM offers an --enable-offline-docs option for air-gapped environments, which the vLLM online serving documentation describes. Confirm with each vendor which features still call external services, such as telemetry, update checks or hosted model catalogs, and disable or block them at the network layer. Test the complete path, from model import through embedding to query, on a host with no route to the internet before go-live.
Integration points that must work without internet access
A disconnected vector database depends on a short list of links to the outside world, each replaced by a local equivalent. Most of these failures do not stop the cluster, which is why they are easy to miss until a restore, an upgrade or an audit exposes them.
Artifact transfer and verification
Every container image, Helm chart, model file and rule set crosses the isolated boundary on removable or diode-controlled media. Record a checksum and a signature for each artifact at the source, verify both again on the enclave side, and keep the manifest with the transfer record. If this step is skipped, a tampered or mismatched image can run silently, and no later check will tell you it came from outside. Ask your vendor which signatures they publish and how you should verify them offline.
Private registry and Helm mirror
Cluster installers and the vector database chart pull images by name at install time and at every pod restart. Mirror the required images and charts into a registry inside the enclave, then point the installer at it. Kubernetes supports this pattern through a list of required images and a private registry flag at initialization. A missing image usually surfaces only when a node is replaced, so test a fresh pull from the enclave registry before go-live.
Local embedding service
Embeddings are produced by a model, and that model must be loaded from local storage. If the embedding service is configured to call an external API or to download weights on first start, ingestion fails or stalls, and queries may be embedded with a different model than the one used to index the collection. Pin the model file, its version and its dimensions, and record them with every collection. Confirm with your model provider which licence terms apply to offline use.
Identity and TLS for clients
A self-deployed Qdrant instance listens on all interfaces with no authentication until you configure it, so the enclave must enforce API keys or token-based access, TLS on REST and gRPC, and certificates issued by an internal authority. Identity providers and certificate authorities usually sit inside the enclave, so confirm they are reachable and that clients trust the internal root. Without this, failures are quiet: clients connect over plain text, or they work only because someone disabled verification.
Audit logging export to the enclave SIEM
Audit logs on the vector database are only useful if they reach the security monitoring stack inside the enclave. Configure the database to write its JSON audit records to a file, then ship them with a local forwarder to your SIEM, which must also run offline. Check that the forwarder retries after outages and that timestamps match your other logs. If the export is skipped, the log file fills or rotates unseen, and queries against restricted collections leave no reviewable trail.
Snapshot storage and version-matched restore
Snapshots are the restore path, and they must be written to block storage inside the enclave, not to an external object store that the cluster cannot reach. Store each snapshot with the database version and embedding model version that produced it, because a restore into a different version can fail or return inconsistent results. Test a restore into a separate environment on a schedule. A backup job that reports success while writing to an unreachable target is one of the most common silent failures.
Evidence auditors and assessors ask for from an offline vector store
This table lists the evidence items an assessor usually requests for a vector store in an isolated network, the component that produces each item, and what the reader should confirm for their chosen engine. Read it as a checklist to agree before go-live, since gaps found late are costly to close in a sealed environment. DeployOpen prepares this evidence, but independent auditors or certification bodies issue any opinion on it.
| Evidence item | Component that produces it | What to confirm before go-live |
|---|---|---|
| Per-collection authentication and permission records | Qdrant JWT-based access control with per-collection read or write permissions, or Milvus role-based access control | Confirm the exact permission model in your engine version and export role and key assignments as dated records |
| API key inventory | Qdrant admin and read-only API keys, or Milvus user credentials | Confirm who holds admin keys, how they are rotated, and where the inventory is stored outside the cluster |
| TLS configuration evidence | Qdrant TLS for REST and gRPC, or Milvus TLS encryption | Capture certificate issuers, validity periods and the internal CA chain used inside the isolated network |
| JSON audit logs of authenticated API operations | Qdrant audit logging, available since v1.17.0, or the equivalent logging you configure for Milvus | Confirm the engine version that provides audit logs and forward logs off the cluster to tamper-evident storage |
| Artifact hash and transfer records | Your transfer process for container images, Helm charts and embedding model files across the boundary | Record checksums and signatures at export and import, plus the approver and the date of each transfer |
| Restore test results matched to the engine version | Snapshot restore runs documented against the Qdrant or Milvus release that created the snapshot | Confirm each restore test names the exact engine version on both sides and the collections and point counts verified |
| Network exposure and default-state review | Configuration baseline showing listeners bound to intended interfaces and authentication enabled | Qdrant instances listen on all interfaces and have no authentication by default, so confirm the hardened configuration was applied and tested |
| EU AI Act record-keeping logs, if the system is high-risk | Application and gateway logs of system events, kept for the lifetime the Act requires | Article 12(1) requires automatic event logging over the system lifetime and Article 19(1) requires keeping logs for at least six months unless other law provides otherwise; confirm whether your system is high-risk |
Questions teams ask before running vector search with no internet
How much more effort does an offline build add compared with a connected one?
An offline build adds work in proportion to how many artifacts must cross the boundary and how many of them must be verified. The main drivers are the number of container images and Helm charts to mirror into a private registry, the local embedding and reranking models to stage, and the packages and rules that need integrity checks before they enter. Kubernetes can be prepared this way: the kubeadm config images list and kubeadm config images pull commands fetch control plane images in advance, and --image-repository points kubeadm init at a private registry. Ask the partner to list every artifact in the bill of materials and state how each one is verified. The total effort depends on the size of that list and on how much of the stack your team already mirrors today.
What do air-gapped vector search costs include, and which ones recur?
The costs fall into four groups: hardware or cloud capacity inside your boundary, the vector database's memory and block storage, the engineering to build and document the offline bundle, and the operating effort that continues after go-live. Build and staging costs are mostly one-time, while capacity, backup storage, patch cycles and on-call support recur. Costs rise with vector count, embedding dimensions, replica count and how often you re-embed content. Some vendors restrict air-gapped deployment to paid editions, so confirm licence terms before you commit. Ask any quote to separate one-time work from recurring support and to name the hardware assumptions behind the memory and disk sizing.
Can an internal team run an air-gapped vector database alone?
A capable internal team can run a single-node or small cluster deployment if it already operates Kubernetes or PostgreSQL, has a tested offline update process and can restore from backups on its own schedule. The gap usually appears in the offline supply chain, in verifying each package before it enters the network, and in upgrade planning for distributed clusters. Qdrant's distributed mode recommends at least three nodes for production so that quorum survives a node failure, and it uses Raft for cluster topology. Assess your team against those tasks specifically, and decide whether a retainer for upgrades and testing would cover the gap. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms inside the client's own environment, under fixed-scope agreements.
How do upgrades cross the air gap without breaking the cluster?
Upgrades cross the boundary as a versioned bundle: container images, Helm charts, models and rules are downloaded on a connected side, checked for integrity and authenticity, transferred by approved media and then imported into a private registry. Only the artifacts in that bundle should be deployed, so the bundle must match the database version, the client libraries and the snapshot format. Qdrant's release history shows how often versions move, with v1.19.2 published on October 5, 2026 after v1.19.0 on August 5, 2026. Ask for a written upgrade runbook that covers rollback, compatibility checks and the test environment used before production. Control expectations around the NERC CIP-013-2 software integrity requirement if your organization falls under it.
Is pgvector enough for air-gapped semantic search?
pgvector is often enough for smaller collections when your team already runs PostgreSQL with tested backup, high availability and restore procedures. It keeps vectors beside relational data, which simplifies entitlement filters and deletion. Move to a dedicated vector database when collection size, dimension counts, filter complexity or query rate outgrow your PostgreSQL capacity, or when you need features such as sharding, per-collection permissions or hybrid search at scale. Test your own query latency and index build times on representative data before deciding. In an isolated network, dedicated engines add another stateful system to patch, back up and restore, so count that operating load in the comparison.
What does a Qdrant Hybrid Cloud or Private Cloud quote depend on?
Qdrant Hybrid Cloud and Qdrant Private Cloud are both priced through Qdrant sales, so there is no public list price to compare against. The quote depends on the deployment model, the cluster size, support expectations and the enterprise features you need, such as the enterprise Kubernetes operator that Qdrant offers as part of Private Cloud. Qdrant documents that its community Helm chart lacks enterprise features such as zero-downtime upgrades and automatic shard rebalancing. Ask the vendor to state which features are included, how upgrades are delivered into an isolated environment and what support terms apply. Separately, ask DeployOpen for a fixed-scope quote covering the installation, hardening and offline bundle work, which is priced from the written scope.
How do teams test that a vector database restore actually works offline?
A restore test proves that a snapshot can be loaded into a cluster of the same version, that the collections return the expected results and that the process can run with no network access. Qdrant snapshots should be restored into a matching version, so keep snapshot files, container images and configuration together in the offline bundle. Run the test on a separate environment at a set cadence, record the elapsed time and the checks performed, and keep the evidence for auditors. Also test deletion: confirm that removed source records do not reappear from older snapshots. Ask your partner to show a completed restore report and the steps used to verify query results after recovery.
What to ask an implementation partner before signing
Start with the offline artifact set, because it decides whether the air-gapped build is repeatable. Ask how the partner builds the bundle of container images, Helm charts, embedding model weights and rule or package files, who signs it, and how each item is checked for integrity and authenticity before it crosses the boundary. A good answer names a manifest with checksums, a documented import path into a private registry, and a written record of what was approved. Ask them to show the exact image tags and chart versions they pinned, not a folder of files. For the vector store itself, ask how Qdrant is secured before first start. The Qdrant security documentation states that self-deployed instances listen on all interfaces with no authentication by default, so a strong answer describes API keys set before the service is reachable, TLS for REST and gRPC, per-collection JWT permissions, and audit logging enabled from day one. Ask for the configuration file and the test that proves an unauthenticated request is refused.
Next, ask how they pin and re-embed when the model changes. Embeddings from different models are not comparable, so the partner should describe how the embedding model version, dimension and collection name are recorded together, and how a new model is loaded, benchmarked against a fixed test set and rolled out as a new collection with a cut-over plan. Ask how re-embedding is scheduled, how long the old collection is kept, and who approves the switch. Then ask for a restore test. Qdrant snapshots must be restored into a matching version, so ask which Qdrant release is pinned, how the partner tests a restore into an isolated copy of the environment, and how they record the time to restore and the number of points compared after restore. Finally, ask which licenses could block air-gapped use or distribution of the stack, such as paid-only air-gapped editions of adjacent tools, and who confirms the terms in writing. Ask who is on call after handover, what the response times are, and who applies security patches through the same offline path.
How DeployOpen scopes and builds an air-gapped vector database
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For vector search, that means agreeing in writing what the isolated environment must do, building it with every image, chart and model pre-staged, and handing over tested restore procedures.
How we scope
- Inventory the target engine, its deployment mode and the embedding models that must run without internet access.
- Confirm collection sizes, vector dimensions, filtering needs and the storage class available on the isolated network.
- Agree in writing which images, Helm charts, models and documentation are transferred across the boundary, and by whom.
How we build
- Stage container images, Kubernetes control plane images and Helm charts in an internal registry before cluster installation begins.
- Configure block-level persistent storage and confirm the file system is POSIX-compatible, avoiding network file systems and object storage for the index.
- Enable API keys, TLS and per-collection access control at install, since self-deployed instances ship without authentication configured.
How we hand over
- Document the transfer procedure, verification steps for each imported package, and the version manifest for every component.
- Test a version-matched snapshot restore in the isolated environment and record the results as evidence for your reviewers.
- Deliver runbooks covering upgrades, re-embedding workflows, audit log review and the operator tasks your team keeps.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, separate from the fixed-scope build.
- Repeat the offline transfer and upgrade process for each new release so the isolated environment stays current and supported.
- Re-run restore tests after changes to the cluster, storage or embedding model to confirm recovery still works.
