Key takeaways
- Air-gapped environments demand complete isolation: Defense, government, healthcare, and critical infrastructure cannot rely on AI platforms that require outbound cloud API calls.
- Self-hosted is not the same as offline-capable: Many self-hosted platforms lose AI functionality when disconnected because inference, telemetry, or licensing still depends on internet access.
- Megapodes runs entirely on your infrastructure: PostgreSQL + pgvector, Redis, MinIO, and Ollama operate locally, with a fail-closed architecture and no cloud fallback to accidentally leave enabled.
- Updates follow established secure procedures: Platform and model updates are validated on a connected staging environment, transferred using approved media, and deployed inside the air-gapped network.
Who actually needs an air gap
An air-gapped deployment — no route to the internet in either direction — is the extreme end of network isolation, and it is standard practice in a well-defined set of sectors:
- Defense and intelligence, where classified networks are physically or logically separated as a matter of accreditation, and software must be brought in through controlled cross-domain procedures.
- Government and public sector, where sovereignty requirements increasingly demand that citizen data and the systems processing it remain inside national or departmental boundaries.
- Healthcare, where clinical networks are often segmented aggressively — both for patient-data confidentiality and because medical devices are hard to patch and easier to isolate.
- Critical infrastructure — energy, water, transport — where operational-technology networks are isolated from IT precisely so that an internet-side compromise cannot reach control systems.
A larger group sits one step short of a literal air gap: organizations that permit egress only through explicit allow-lists and treat every new outbound destination as a security exception. For both groups the procurement question is identical: does this product still work — fully — when it cannot phone anything?
Why “self-hosted” so often fails offline
Self-hosting has come to mean “the application server runs on your machines.” That is necessary but nowhere near sufficient, because the interesting functionality frequently lives elsewhere. When an AI-featured platform is deployed into an isolated network, the common failure modes are:
The AI is a cloud API call
This is the big one. In most current platforms, every AI feature — generation, summarization, semantic search — is implemented as a request to a hosted model provider. The vendor’s containers run locally; the intelligence does not. Cut the uplink and the product degrades to a conventional CRUD tool, usually with error banners where the flagship features used to be. The marketing said self-hosted; the architecture said thin client.
Embeddings and search have a cloud dependency
Even when chat features are local, semantic search often depends on a hosted embedding API or a managed vector database. No egress means documents can no longer be indexed, and the knowledge-base features silently stop improving.
Licensing, telemetry, and updates assume connectivity
License activation servers, usage telemetry, and auto-update checks all assume a route out. In an enclave they either break the product or generate a stream of blocked-connection alerts your security team must chase.
None of these are dishonest engineering choices — hosted inference is the path of least resistance. But they mean an “offline evaluation” is the test that separates architectures: a platform either kept its intelligence inside the box, or it did not.
A stack with nothing outside the box
Megapodes was designed so that the answer to “what breaks offline?” is: nothing in the core platform. The deployment is a set of Docker containers, all inside your boundary:
- PostgreSQL with pgvector — the system of record and the vector store. RAG retrieval for knowledge bases is a database query, not an external search service.
- Redis — queues (BullMQ) and cache coordination across stateless server and worker replicas, so no request ever sees a half-applied app.
- MinIO — S3-compatible object storage for files, entirely local.
- Ollama — local inference for both the chat model and nomic-embed-text embeddings, typically on a GPU host (~8GB VRAM guidance; CPU-only possible but slower).
Because inference is local, both AI planes survive the air gap intact. The build-time agent still turns natural language into schema-validated metadata, still runs Zod schema validation, business rules, and migration dry-runs, and still stops at the human approval gate — the full pipeline on our How It Works page, unchanged. Runtime AI Employees still read, summarize, classify, and answer from pgvector knowledge bases with cited sources. The three-layer authorization stack and append-only audit log described on our Security page operate identically, because they were always database-enforced, never service-enforced.
Equally important is what is absent: there is no cloud fallback to disable, no telemetry endpoint to block, no license activation server to whitelist — licensing uses offline license files, with no phone-home. Megapodes is fail-closed by design — if a component you did expect to be reachable is not, the platform errors explicitly rather than routing around your boundary. What you give up offline is exactly what logic dictates: integrations that are outbound by definition (external SaaS APIs, webhooks to internet hosts, external SMTP). Integrations with systems inside the enclave — internal PostgreSQL and MySQL databases, internal REST APIs — remain first-class, still guarded by SSRF protections and outbound allow-lists.
A practical deployment checklist
Teams running disconnected environments have well-worn procedures; Megapodes is built to fit them rather than fight them.
- Stage connected. On a connected staging host, pull the Megapodes container images and the Ollama model files (chat model + nomic-embed-text). Record digests.
- Verify. Check image digests and model checksums, review the SBOM that ships with each build, and run your standard scanning. Supply-chain posture — locked dependencies, minimum release age for upstream packages — is part of the release process.
- Transfer. Move the verified artifacts across the boundary on approved media, per your cross-domain procedure.
- Load and deploy. Push images to the enclave’s internal registry, load models into Ollama, and bring the stack up with Docker. Confirm the GPU host serves the models.
- Prove the gap. Verify zero egress at the firewall — the strongest property of this architecture is that you can test it from outside the application. Then exercise an end-to-end build: describe an app, watch validation and dry-run, approve, and confirm the audit log recorded it.
- Promote with signatures. Use signed, versioned configuration bundles to move applications dev → test → prod — including across enclave boundaries — with diff, dry-run, and approval on import. Secrets are excluded from bundles and rekeyed at the destination.
Model updates without a network
Models are software artifacts, and disconnected environments already know how to update software: deliberately. New model versions follow the same stage-verify-transfer-load path as containers. That cadence — updates as scheduled, reviewed events rather than background downloads — is one many security teams prefer, because the inference stack only ever changes through a controlled, logged process. And because Megapodes’ guarantees are structural — validation gates, human approval, database-enforced authorization — a model version change alters draft quality, not the security posture. There is no moment where an unvetted model silently starts making decisions, because no model, of any version, applies changes without a human approving them.
Air-gap capability, in the end, is not a niche feature. It is the proof that a platform’s sovereignty claims are architectural rather than contractual. If your environment demands zero egress — or you simply want the option — the deployment models are covered on our Enterprise page, and the platform capabilities that survive the gap on Features.
Frequently asked questions
Do any Megapodes features stop working in an air-gapped deployment?
Core functionality — application building with the AI agent, runtime AI Employees, workflows, RAG knowledge bases, permissions, and audit — runs entirely on the local stack. What you naturally give up is anything that is outbound by definition: integrations with external SaaS APIs, outbound webhooks to internet hosts, and SMTP to external mail servers. Integrations with systems inside the enclave continue to work.
How do you update AI models without an internet connection?
The same way disconnected environments update any software: pull model files and container images on a connected staging system, verify checksums and scan them under your transfer procedure, move them across on approved media, and load them into the enclave’s registry and Ollama. Model updates are deliberate, scheduled events — which many security teams consider a feature, since the inference stack only changes through a controlled process.
How is an air-gapped install licensed and activated?
Megapodes is licensed commercially with offline license files — there is no activation server and no license phone-home, so nothing in the platform requires a connection to an external service. Evaluation licenses and enterprise support terms for disconnected environments are defined in your agreement; request an evaluation license to begin.
Is air-gapping overkill for organizations outside defense and government?
Often, yes — a standard self-hosted deployment with egress restricted to an explicit allow-list gives most organizations the assurance they need at far lower operational cost. The value of an air-gap-capable platform is that the same architecture serves both: you can start connected and tighten to zero egress later without losing AI functionality, because nothing in the stack ever depended on the internet.
Planning a restricted or disconnected deployment?
We will walk your security and platform teams through the full stack, the egress profile, and the update procedure for your environment.
Self-hosted — your data never leaves your network · Every change human-approved and audit-logged · SSO/OIDC available · We support your security review
