What Air-Gap Infrastructure Requirements Actually Mean for Private Cloud Deployments

A solutions architect at a large IT services firm recently submitted a request that’s become increasingly common: a government agency client needed a data lakehouse deployed in an “air-gapped” setup. No internet connectivity to the workload environment. No cross-contamination from public networks. Audit-ready evidence of network isolation. The requirement came straight out of a procurement document.

What the client didn’t need was a SCIF-grade physical separation from all electronic signals. They needed their data processing workloads to have no public internet exposure, no way to exfiltrate data over a public connection, and a network architecture they could document for an auditor. That’s a well-defined infrastructure problem with a practical solution.

It’s worth being clear about what that solution is and what it isn’t, because confusing the two leads to requirements that can’t be met and vendors who quietly oversell what they actually deliver.

What True Air Gap Means

A true air-gapped system is physically disconnected from any network that connects to the internet. No wireless interfaces. No public network ports. Data moves in and out via physical media under strict controls. This is the standard used in SCIF environments, classified defense systems, and some industrial control systems where the cost of any internet exposure outweighs everything else.

Operating in a true air-gapped environment means the management plane is also offline. Software updates happen via verified media. Provisioning and configuration tools run locally. There is no hosted dashboard, no API accessible over the internet, no cloud-based automation.

That’s a specific, demanding operational model. Most organizations asking for “air-gapped” infrastructure don’t mean this. And hosted cloud providers, including OpenMetal, cannot deliver it, because the management plane requires internet connectivity for provisioning, monitoring, and deployment automation. Any provider claiming to offer true air-gap on hosted infrastructure should be questioned carefully.

What Most Compliance Requirements Actually Describe

When a compliance document, an internal security policy, or a procurement requirement asks for an “air-gapped” or “isolated” environment, the practical requirements are almost always:

• Workloads have no public IP addresses assigned
• No outbound internet access from the workload environment
• No inbound connections from public networks
• Network traffic is isolated from other tenants
• The architecture can be documented and audited

These are network isolation requirements. They describe how traffic flows, not the physical topology of the underlying hardware. And they are achievable on hosted private cloud infrastructure when the networking architecture is built correctly.

This distinction matters for procurement. A compliance team writing requirements in terms of “air-gap” may actually be satisfied with documented network isolation if someone walks them through what that means technically. That conversation is worth having before assuming you need facilities you may not actually require.

How OpenMetal’s Networking Architecture Enables Workload Isolation

OpenMetal assigns dedicated VLANs to each customer for both bare metal and private cloud deployments. Traffic on your VLAN does not share a broadcast domain with other customers. This is infrastructure-level isolation, not just a logical overlay on top of shared switching.

Within a private cloud deployment, OpenStack’s networking layer adds a second level of isolation through Virtual Private Clouds. Each VPC is a logically isolated virtual network with its own IP addressing, subnet configuration, firewall rules, and security groups. VPCs run over VXLAN overlays within your dedicated customer VLAN. You can create multiple VPCs within a single deployment at no additional cost.

For isolated deployments specifically, this architecture enables:

• No public IP assignment. Virtual machines can be deployed with no public IP attached. A VM with only a private IP address has no direct route to or from the public internet. Outbound internet access can be blocked at the virtual router or security group level. Combined, this means a workload that handles sensitive data can have zero public network exposure while still communicating with other VMs in the same private network.
• Firewall rules and security groups. OpenStack’s security groups function as stateful firewalls at the VM level. You can define explicit allow rules and deny everything else by default. For isolated workloads, a default-deny egress policy with no public IP assigned closes off external access without relying on network-level controls alone.
• VPN connectivity for controlled access. If operators or administrators need to access workloads in an isolated environment, OpenStack’s VPN-as-a-Service provides an encrypted tunnel from your organization’s network to the private cloud. This keeps management traffic off the public internet while avoiding the need to assign public IPs to workloads.
• Private-only server-to-server traffic. The 20 Gbps private network between servers is completely separate from the public uplink. Workloads communicating between nodes in your cluster can do so entirely over this private network, with no traffic traversing a public interface.

What the Management Plane Requires

OpenMetal Central, the dashboard used to provision and manage your infrastructure, runs as a hosted service and requires internet access. The 45-second private cloud deployment automation, OpenStack Horizon, and the OpenStack API endpoints are all accessible over the internet.

This means the operator managing the environment needs internet access. IPMI interfaces for bare metal servers are similarly network-accessible for remote management. These are standard operational requirements for any hosted infrastructure provider.

What this means practically: the management layer cannot be fully isolated. If your compliance requirement includes isolating the management plane from any internet-accessible network, hosted private cloud infrastructure does not satisfy that requirement. If the requirement applies only to workloads and data traffic, it is achievable.

For regulated deployments, this distinction is usually acceptable. A healthcare organization running PHI workloads, for example, can operate those workloads on a private network with no public exposure while administrators access management interfaces over a VPN or corporate network. The workload isolation is what the compliance framework cares about; the management plane is handled through normal administrative access controls.

A Practical Reference Architecture for Isolated Deployments

A team deploying a network-isolated workload environment on OpenMetal would typically configure it as follows:

• Compute layer: Virtual machines deployed within a VPC with no public IPs. All inter-VM traffic stays within the private VLAN. Security groups set to default-deny for all inbound and outbound traffic, with explicit allow rules only for traffic between trusted internal addresses.
• Storage layer: Ceph-backed block storage and object storage accessible only within the private VPC. No public-facing Swift endpoints. For object storage accessed by multiple internal services, Swift can be configured to listen only on internal network addresses.
• Access layer: A VPN gateway at the VPC boundary. Administrators connect to workloads through the VPN tunnel. No bastion hosts with public IPs required. OpenStack’s VPN-as-a-Service handles the tunnel termination inside the private cloud, connecting to your on-premises VPN gateway.
• Management layer: OpenMetal Central and OpenStack Horizon accessed by administrators over your organization’s internet-connected network or VPN. IPMI management interfaces handled through normal operator access, separate from workload networks.
• Egress controls: Virtual routers configured to drop all outbound traffic by default. If workloads need access to specific external services (such as pulling software packages during initial setup), that access can be allowlisted and logged, then removed once the environment is in production operation.

This architecture provides auditable network isolation for workloads. A network diagram of the VPC configuration, combined with security group rule exports, gives compliance and audit teams documentation of how traffic is controlled.

Who This Fits

Government contractors running unclassified sensitive workloads

CUI (Controlled Unclassified Information) handling under NIST SP 800-171 includes network isolation and access control requirements that physical air-gap is not required to meet. A private VPC with no public IPs, default-deny firewall rules, and documented network architecture addresses the network boundary controls — though CUI compliance involves additional requirements across access management, incident response, and audit that the network layer alone does not cover.

Healthcare organizations processing PHI

HIPAA’s technical safeguards include access controls, audit controls, and transmission security requirements. Network-isolated workloads with no public IP exposure and default-deny security groups address the network access control side. Full HIPAA compliance also requires a Business Associate Agreement with your infrastructure provider, encryption at rest and in transit, and controls across several other domains. The network architecture is one piece of that, not the whole picture.

Financial services firms with data segregation requirements

Regulatory requirements in financial services commonly specify that certain systems must not be accessible from public networks. A private VPC with VPN-only administrative access meets this requirement without colocation-grade operational overhead.

Internal enterprise applications

ERP systems, internal data pipelines, and other applications that serve internal users only and should not be publicly accessible are a natural fit. No public IP means no public attack surface, and the private networking between servers handles internal traffic at line rate.

Who This Doesn’t Fit

Workloads requiring DoD IL4/IL5 or FedRAMP High

These frameworks require your infrastructure provider to hold specific authorizations earned through formal assessment and audit processes. Network isolation alone does not satisfy them, and a hosted provider without the relevant authorization cannot make your workload compliant regardless of how the network is configured. If your compliance requirement specifies one of these frameworks, verify your provider’s authorization status directly.

ITAR/EAR-controlled technical data

Export-controlled technical data requires specific handling requirements that go beyond network isolation, including personnel controls, facility certification, and access controls that a standard hosted provider cannot certify.

True classified computing

If your workload classification level requires physical separation from any internet-connected infrastructure, hosted private cloud is not the right answer. On-premises hardware in a certified facility is.

Environments where the management plane must also be isolated

If your requirement specifies that no management traffic can traverse internet-connected infrastructure, the design described above does not satisfy it. OpenMetal’s provisioning and management plane is internet-accessible by design.

Frequently Asked Questions

Can I deploy virtual machines with no public IP address on OpenMetal?

Yes. Virtual machines in an OpenStack VPC can be deployed with private IP addresses only. You control whether a floating IP (public IP) is assigned to a VM. A VM with only a private IP has no direct path to or from the public internet, regardless of the underlying server’s public uplink.

Does OpenMetal’s management plane require internet access?

Yes. OpenMetal Central, the provisioning dashboard, requires internet access for operators. The OpenStack API endpoints and Horizon dashboard are accessible over the internet. IPMI management interfaces for bare metal servers also require network access. If your compliance requirement isolates the management layer as well as workloads, hosted private cloud infrastructure does not satisfy that requirement.

How is my network traffic isolated from other customers?

Each OpenMetal customer is assigned dedicated VLANs. Your traffic does not share a broadcast domain with other customers at the infrastructure layer. Within your private cloud, OpenStack VPCs add a second level of logical isolation through VXLAN overlays running inside your dedicated VLAN.

Can I connect my on-premises environment to my OpenMetal private cloud without public internet exposure for workloads?

OpenStack’s VPN-as-a-Service creates an encrypted tunnel between your on-premises VPN gateway and the private cloud. Workloads inside the VPC can be accessible to your on-premises team through the tunnel without requiring public IP addresses on the workloads themselves.

Is this architecture suitable for FedRAMP or DoD classified workloads?

No. FedRAMP and DoD IL authorizations require your infrastructure provider to hold specific certifications earned through formal assessment processes. Network isolation addresses one technical control area, but it does not substitute for provider-level authorization. If your requirement specifies one of these frameworks, verify your provider’s authorization status directly before proceeding.

Can I document the network architecture for compliance audits?

Yes. VPC configurations, security group rules, and network topology can be exported from OpenStack and documented for auditors. OpenMetal’s dedicated VLAN assignment provides a documented network isolation boundary at the infrastructure level. Most compliance frameworks that require network isolation accept this type of documentation.

What workloads are a good fit for network-isolated private cloud?

Unclassified but sensitive workloads are typically the right fit: government contractor data processing, healthcare PHI handling, financial data pipelines with regulatory segregation requirements, and internal enterprise applications that should not be publicly accessible. The common thread is a requirement to keep workloads off public networks combined with a need for documented, auditable network controls.

OpenMetal’s private cloud infrastructure isn’t a replacement for certified classified facilities. But for the large category of workloads that need documented network isolation without true physical air-gap, the combination of dedicated VLANs, OpenStack VPCs, and configurable security groups provides a practical and auditable solution. If you’re designing an isolated deployment and want to walk through the architecture, talk to our team or apply for a proof of concept.