Most facility software vendors will tell you they are "cloud-first." Some will tell you they are "cloud-native." A few will admit they are "cloud-only." For a large segment of the customers we serve, every one of those statements is a non-starter.
Federal facilities, classified sites, certain healthcare environments, certain industrial control environments, and a growing number of risk-sensitive commercial customers cannot put their facility data on someone else's computer. The reasons range from regulatory (NIST 800-171, CMMC, HIPAA) to operational (the building has to keep working when the internet does not) to philosophical (we own this data and we are not handing it to a SaaS vendor we did not vet).
A·IQ was built air-gap capable from day one. This article is the architectural posture that follows from that decision.
What "air-gap capable" actually means.
It does not mean "we have an on-prem option." Most cloud-first products that bolt on an on-prem deployment have a quiet phone-home dependency, a license-validation server, a telemetry endpoint, or a software-update channel that requires outbound internet. In any genuinely air-gapped environment, all of those break.
Air-gap capable means the entire system runs without any outbound connectivity, ever. License validation, software updates, telemetry, weather data, AI inference all local. Updates arrive on physical media or via a one-way data diode. The system has no idea what year it is until you tell it.
Building software this way changes everything about how you architect.
What changes.
Identity has to be local. No SSO to Azure AD or Okta unless those run inside the air-gap. We bundle FusionAuth with the deployment so identity, MFA, and audit live inside the perimeter. SAML and OIDC federate to your local IdP if you have one.
Secrets have to be local. No HashiCorp Cloud, no AWS Secrets Manager. We run OpenBao (a fork of HashiCorp Vault) inside the deployment. Every service authenticates via cert-based AppRole. No plaintext secrets anywhere in the stack.
AI inference has to be local. Cloud LLM APIs leak data and require connectivity. For our Virtual Technician feature, we ship quantized open-weights models that run on a modest GPU inside the air-gap. The trade-off is model size we run smaller models than what is available in the cloud but the data never leaves.
Updates have to be airgap-friendly. We package the entire deployment as Docker images plus a Compose file. Everything required to run is in those artifacts. Updates ship as a tarball that can be transferred via approved media (USB, write-once optical, data diode) and applied with a single script.
Telemetry has to be opt-in. No silent phone-home. The default state is no outbound traffic. If a customer wants to share telemetry for support purposes, they explicitly enable an outbound endpoint and they choose what gets sent.
What does not change.
The user experience. The UI is the same as our cloud-deployable version, the API is the same, the data model is the same. Air-gap deployment does not mean a stripped-down version. It means the same product running in a more constrained network.
This matters because customer organizations frequently have a mix of sites: some that can use the cloud-deployable version, some that cannot. A consistent product experience across both means engineers and operators can move between sites without retraining.
The cost.
Air-gap deployment is harder. We absorb the engineering cost of supporting it because we made the architectural decision early.
If you tried to bolt air-gap support onto a product that was designed cloud-first, the cost would be enormous every component would need to be re-thought, every dependency audited, every external API replaced. We have seen vendors attempt this and fail to deliver a coherent product.
The decision to be air-gap capable from day one is not just about supporting air-gap customers. It is a constraint that forces certain architectural discipline:
- You cannot rely on managed cloud services to solve hard problems
- You cannot have hidden dependencies on third-party APIs
- You cannot let your data model drift toward "we'll just sync it to S3"
- You have to think hard about what really needs to be a microservice and what does not
The result is a product that is also better-suited to non-air-gap environments. A customer running A·IQ in a private cloud or in their own data center benefits from the same architectural discipline. They get a product that does what it says, runs predictably, and does not require them to trust an external vendor with their data.
Who this is for.
If you are a federal customer DoD, VA, GSA, NIH, any agency operating critical facilities air-gap deployment may be a hard requirement. We are an SDVOSB and we sell direct-award through that vehicle.
If you are a healthcare system or pharmaceutical manufacturer, air-gap deployment may be the simplest path to HIPAA or 21 CFR Part 11 compliance for your facility data.
If you are an industrial operator with OT segmentation requirements, air-gap deployment lets you keep the facility intelligence platform inside the OT network without straddling the IT/OT boundary.
If you are a commercial operator who is simply tired of SaaS vendors going down, getting acquired, or changing their terms air-gap deployment is also for you. We are not selling you a subscription that can disappear. We are selling you a system you control.
What to ask vendors.
Three questions to ask any facility software vendor pitching an "on-prem option":
- Does the system phone home for license validation? If yes, that is a connectivity dependency. Air-gap deployment is not real.
- Does the system require outbound internet for updates, telemetry, or AI features? If yes, those features will not work air-gapped.
- Has anyone actually deployed this in a fully air-gapped environment? Ask for a reference. Vague answers mean no.
The right answer is "yes we've deployed this air-gapped, here is the customer reference, and here is the documentation for the install procedure on a network with zero outbound connectivity." Anything less means you will be the test case.
Cloud-first is a fine choice for many customers. It is not a universal choice. The vendors who pretend it is are the vendors who will have nothing to sell when the customer's security team gets involved.
Kevin Fedor is the founder of Arcis FM and the engineering lead on A·IQ Analytics. Arcis FM is a Service-Disabled Veteran-Owned Small Business (SDVOSB) eligible for federal set-aside. Connect on LinkedIn.
