No internet. No cloud. No problem: deploying an API gateway in an air-gapped environment.

In 2026, a US Department of Defense directive requires AI vendors to be able to deploy within classified environments within 30 days of a model's public release. The message is clear: cloud-first vendors that cannot operate inside a boundary are no longer acceptable for this class of customer.

The same requirement has existed for API gateways in government, defence, and regulated healthcare for years. It is not new. What is new is that the market is finally catching up to it.

An air-gapped deployment is not a preference or a cost consideration. For organisations handling classified information, controlled unclassified information (CUI), protected health information (PHI), or national security data, it is a hard requirement. The question is not whether to support it — it is whether your current gateway vendor can.

What "air-gapped" actually means for an API gateway

An air-gapped API gateway operates in a network segment with no outbound internet connectivity. No external DNS resolution. No outbound HTTPS. No network path to any vendor infrastructure.

This has specific implications for every component of the gateway:

License validation. Cloud-first vendors often validate licenses by calling a vendor-hosted endpoint at startup or on a regular schedule. In an air-gapped environment, this call fails. The gateway does not start, or it enters a degraded mode. This is a hard blocker.

Policy enforcement. Some gateways download policy definitions, firewall rules, or access control lists from a cloud control plane at runtime. In an air-gapped environment, these downloads fail. Policy enforcement becomes undefined.

Telemetry and logging. Gateways that push metrics or logs to a vendor-hosted SaaS service cannot do so in an air-gapped environment. This is often presented as "observability" — but in practice it means your operational metrics go nowhere unless you have a fully self-hosted alternative.

Certificate validation. TLS certificate chains often include OCSP (Online Certificate Status Protocol) requests to external CAs. In an air-gapped environment, OCSP fails. Gateways that do not support OCSP stapling or offline certificate validation will have TLS validation issues.

Updates. Software updates must arrive via a mechanism that does not require internet access — signed artifacts delivered via physical media, internal artifact repositories, or a one-way data transfer channel.

A gateway that is described as "self-hosted" but requires internet connectivity for any of these functions is not genuinely air-gapped capable.

The deployment architecture for air-gapped environments

A genuine air-gapped API gateway deployment has these properties:

All components run inside the boundary. Gateway, admin UI, configuration store, audit log storage — everything that handles or protects data runs on infrastructure you control. No component makes outbound calls to infrastructure you do not control.

Configuration and state are fully local. Gateway configuration — collections, proxies, workflows, access policies, credentials — is stored in a database inside the boundary. No configuration is pulled from a vendor cloud at startup or runtime.

Authentication is from your IdP. OIDC and token validation uses your organisation's identity provider, deployed inside the boundary. The gateway validates tokens against your internal IdP, not a vendor-hosted service.

Metrics and logs go to your SIEM and monitoring stack. Prometheus metrics are scraped by your internal Prometheus instance. Structured logs are consumed by your internal log aggregator — Elastic, Splunk, or equivalent. Nothing leaves the boundary.

Updates are verifiable and offline-capable. Container images are signed and delivered to your internal registry. Updates do not require an outbound pull from a public container registry during the update process.

Docker Compose vs Kubernetes for air-gapped deployments

Both deployment patterns work in air-gapped environments, with different operational trade-offs.

Docker Compose is the right choice for:

Smaller-scale deployments (single-node or small clusters)
Environments where Kubernetes expertise is not available
Initial deployments where simplicity is more valuable than horizontal scalability
Classified environments where minimal software footprint reduces the attack surface

Kubernetes is the right choice for:

Production-scale deployments requiring horizontal scaling and high availability
Environments where Kubernetes is already the standard deployment platform
Workloads that need rolling updates, pod-level health checks, and readiness probes
Multi-replica gateway deployments for zero-downtime operations

Both can be operated without internet access. The key is that container images are loaded from an internal registry — not pulled from Docker Hub or a public registry at deploy time.

What the developer portal looks like inside the boundary

An API gateway in an air-gapped environment still needs to serve partners, contractors, and internal API consumers. The developer portal — where consumers discover APIs, obtain credentials, and test endpoints — must operate inside the boundary too.

This means:

No external CDN for portal assets — all static assets served from inside the boundary
No external identity provider for consumer sign-in — authentication flows against your internal IdP or the gateway's own credential system
No external email delivery for magic links or notifications — SMTP routed through your internal mail relay
No external try-it backend — API test calls routed through the gateway, inside the boundary

A developer portal that works inside an air-gapped network looks and operates identically to one running in a cloud environment — the traffic just never leaves the perimeter.

The compliance benefit of air-gapped operation

Beyond the security requirement, air-gapped deployment has a compliance benefit: it dramatically simplifies the data residency and data sovereignty story.

When every component runs inside your boundary and nothing leaves it, the answer to "where does your data go?" is "nowhere." That is a simpler answer than "to our cloud provider, which has data centres in these regions, which are covered by this data processing agreement."

For regulated industries and government entities, "nothing leaves the boundary" is the answer that eliminates a large category of compliance questions before they are asked.

Zerq runs entirely within your infrastructure — Docker Compose or Kubernetes, no outbound runtime dependencies, no vendor callbacks, no telemetry outside your boundary. See how it applies to government and public sector or request a demo to walk through your air-gapped deployment requirements.