Air-Gapped Deployment
Run the full nano SIEM inside a disconnected network — zero egress, offline content and AI, and licensing with no call-home.
Air-Gapped Deployment
nano runs completely inside the wire. Ingestion, storage, detection, search, and AI-assisted investigation all run on infrastructure you control, on networks that never touch the internet. The air-gapped deployment is the same product as the connected one — not a reduced "appliance" fork — with a small, well-understood set of capabilities re-pointed at on-prem equivalents.
Air-gapped operation is an Enterprise capability — it includes the offline content/license bundles, on-prem AI, and a signed offline update channel described below. There is no open-source air-gap edition. Reach out to sales@nano.rs to scope a deployment or an offline pilot.
What "air-gapped" means here
Four capabilities in the connected product reach external services — AI inference, threat-intel/enrichment feeds, license check-in, and image pulls. In an air-gapped install, every one of them has an offline path, and nano is configured to never initiate an outbound connection across the gap.
When you run nano with AIRGAP_MODE=true, the platform:
- Disables every egress background job — parser/rule/playbook/marketplace repo sync, IP-geo and IOC feed refresh, and the model-catalog sync all stop starting. Internal jobs (detection, search, alerting, enrichment dictionaries, cleanups) keep running normally.
- Never phones home for licensing. The periodic license check-in is not started; validity is established locally from a signed offline license file.
- Routes AI through your on-prem endpoint only — no hosted AI gateway.
Nothing degrades silently. If a feature would have reached the internet, it either uses its offline equivalent or is cleanly disabled.
Reference architecture
Everything below lives inside your trust boundary. Nothing crosses the air gap except offline bundles you bring in on your own schedule.
All components run on customer-controlled Kubernetes:
| Component | Role | Air-gap note |
|---|---|---|
| Vector | Log collection + VRL parsing/normalization to the Unified Data Model | Fully local; parsers delivered in the offline content bundle |
| ClickHouse | Time-series event store (designed for 50–100 GB/day, scales up) | Local cluster, no external dependencies |
| PostgreSQL | Metadata: rules, alerts, users, dashboards, audit | Local |
| nano-api | Detection engine, alerting, ingestion control, settings | Local |
| nano-search | Query execution (nPL pipe language → ClickHouse SQL), field stats | Local |
| nano web | Analyst UI — hunting, triage, detection authoring, dashboards | Served internally |
| On-prem inference (optional) | LLM + embeddings for AI assist and RAG | Bring-your-own endpoint — see AI on your terms |
AI on your terms
meloD — nano's AI layer — powers detection generation, rule tuning, query assist, alert triage, and the autonomous shadow investigation that runs on new cases. In the connected product this routes through a hosted AI gateway. In an air-gapped install it points at an OpenAI-compatible model endpoint you stand up inside the boundary (for example a self-hosted vLLM, Ollama, or LocalAI server running an open-weights model, plus a local embedding model for RAG).
Stand up an inference server inside the enclave that exposes an
OpenAI-compatible /chat/completions API. Note its internal URL (e.g.
http://vllm.internal:8000/v1).
In nano, go to Settings → AI providers. The On-prem inference endpoint card is at the top of the page.
Enter the endpoint URL, the model name your server serves, and an API key if your server requires one (many on-prem servers run open behind the network boundary — the key is optional). Click Test connection, then Save.
nano talks to this endpoint over the internal network only. AI requests never leave the boundary, and the connectivity health-check honors the same on-prem endpoint — so a healthy on-prem model never reports as "down."
The core SIEM — ingestion, detection, search, alerting, dashboards — is fully functional with no LLM at all. Teams that don't want any model in the enclave can simply leave AI features unconfigured.
Offline content and enrichment
Connected, nano refreshes its detection content and enrichment data from upstream repositories and feeds. Air-gapped, those arrive as signed offline bundles you carry across the gap.
| Bundle | Contents | Lands in |
|---|---|---|
| Parsers | VRL log parsers for supported sources | Log-source / parser library |
| Rules | Detection rule packs | Detection rules library |
| Playbooks | Response playbooks | Playbook library |
| IP enrichment | IP geolocation + ASN database (IPinfo Lite-style) | ip_enrichment dictionary |
| IOC | Threat-intel indicators (ThreatFox, Tor exit nodes, reputation) | IOC dictionaries |
| License | Signed offline license (see Licensing) | License store |
Every bundle is signed; nano verifies the signature and per-file digests before importing and refuses anything that doesn't validate.
Importing a content bundle behaves like an offline repository sync: it populates the repositories page with the available items, and you choose what to import and activate — rather than auto-deploying everything. Detection still runs in real time against whatever intel is loaded; freshness becomes a function of how often you choose to bring a bundle in.
Most teams refresh enrichment/IOC bundles on a fixed schedule (sneakernet, or a one-way data diode if you have one) and pull content bundles only when they want new detections. nano runs autonomously between refreshes.
Licensing
Air-gapped licensing uses a signed offline license file, issued for your term and validated entirely on-prem with no network call. Import it under Settings when you first stand up the instance; renewal is a new file brought across the gap. There is no phone-home, ever.
Enterprise features require a valid offline license. If the license is missing, expired, or fails signature validation, those features fail closed rather than running unlicensed.
Product updates
Each release ships as a signed offline upgrade bundle: a pinned,
digest-verified set of container images plus the database migrations for that
version. nano maintains an images.lock
manifest of verified image digests, and the stack refuses to start on any
digest mismatch. You mirror the bundle into your internal registry and roll
forward on your own change-control cadence — integrity verified by digest before
anything runs.
Deployment lifecycle
A clean four-step loop, none of which opens egress:
Bring in — transfer the offline bundle (container images + offline license + initial enrichment/content bundles) across the gap to an internal staging host.
Install — load the images into your internal registry, apply the Kubernetes
manifests, and set AIRGAP_MODE=true. nano boots against its local ClickHouse +
PostgreSQL. Optional TLS via the bring-your-own-certificate overlay (see
Self-Hosting → Enabling HTTPS).
Operate — ingest, detect, hunt, and investigate. Fully autonomous inside the boundary. Configure your on-prem AI endpoint and import content bundles as needed.
Update — on your cadence, bring in a new signed product bundle and refreshed feed bundles. Roll forward; nano verifies every image by digest before starting.
Pilot
The fastest way to validate the model is a time-boxed offline pilot: install in a representative enclave, ingest a sample of real log sources, and validate detection, search, and (optionally) on-prem AI assist end-to-end with no egress. The deliverable is a documented, reproducible air-gapped install your own team can stand up.
Reach out to sales@nano.rs with your target Kubernetes footprint, log-source inventory, whether on-prem inference is in scope, and your bring-in mechanism (sneakernet vs. diode) so we can shape the bundle format to your environment.