What does "air-gapped" mean for SaaS deployment?

It means the deployment environment has no network connection to the public internet at all — no automatic updates, no live telemetry, and updates happen through a manual, controlled transfer process instead.

Is air-gapped the same as on-premises?

No. On-premises means the software runs on the customer's own infrastructure, but it can still have internet access. Air-gapped specifically means no external network connectivity at all.

Does FedRAMP require air-gapped deployment?

No. FedRAMP is a compliance authorization framework for cloud services sold to federal agencies. Some higher-sensitivity environments layered on top of federal requirements do require full network isolation, but FedRAMP itself doesn't mandate it.

How should we price an air-gapped deployment?

Price it to reflect ongoing maintenance of a separate release track, not just the initial build — a flat one-time custom-deployment fee typically undercharges for the multi-year sustaining cost.

Who should decide whether to support air-gapped deployments?

It should be a cross-functional roadmap decision involving product and engineering leadership, not a single account executive's deal concession, since it commits the company to an ongoing deployment track.

An air-gapped deployment request is a roadmap decision, not a deal concession

Guide · enterprise · 5 min read · last verified 2026-07-21

Reviewed before publication Editorial board — revision applied Independent commercial review

In shortAn air-gapped deployment means running fully disconnected from the internet — no auto-updates, no live telemetry — and agreeing to build one commits engineering to a second, permanently maintained deployment track, not a one-time contract l

An air-gapped deployment is a version of a product that runs fully disconnected from the public internet — no outbound calls to the vendor's SaaS backend, no automatic updates, no live telemetry — typically because the buyer operates in a classified, regulated, or high-security environment. When a sales team agrees to it to close one deal, they aren't making a one-time contract concession: they're committing engineering to build and maintain a separate deployment model indefinitely. That's a roadmap decision, and it should be made by the people who own the roadmap.

What "air-gapped" actually means — and what it doesn't

Air-gapped means the deployment environment has no network path to the public internet at all. Updates, patches, and license checks can't happen automatically; they require a manual, controlled transfer process — often a signed package moved across the gap via removable media or a mediated one-way transfer mechanism. There's no live connection back to the vendor for telemetry, error reporting, or remote support.

This is a different thing from adjacent terms that get used loosely in the same conversations:

Single-tenant or dedicated instance: a customer gets its own isolated infrastructure, but it's still internet-connected and can still receive continuous updates. See single-tenant vs. multi-tenant.
On-premises: the software runs on the customer's own hardware or private cloud, but on-prem systems frequently still have internet egress for updates and support — on-prem does not automatically mean air-gapped.
FedRAMP authorization: a compliance framework for cloud services sold to U.S. federal agencies. FedRAMP itself doesn't require air-gapping; some adjacent, higher-sensitivity environments (certain Department of Defense workloads) do require full network isolation, but that's a separate, stricter requirement layered on top. See what is FedRAMP.

Why sales treats it as a concession — and why that framing is wrong

On a term sheet or an order form, "customer requires air-gapped deployment" reads like a single line item, similar to a custom SLA or an extra support tier. That framing hides what actually has to exist behind it: a maintained, versioned release pipeline that produces signed offline packages; an authentication and licensing mechanism that works without a call back to the vendor's identity provider; documentation a customer's own team can follow to patch the system without vendor access; and a support model that doesn't assume remote log access or live debugging.

None of that is a one-time build. It's a second deployment target that has to stay compatible with the product going forward.

The real cost: what engineering has to build and sustain

A separate release process. Instead of continuous deployment to a SaaS backend, air-gapped customers need discrete, versioned, signed releases they can transfer and install manually.
Offline auth and licensing. Anything that assumes a live call to a central service — SSO against the vendor's IDP, a license check, a feature flag service — needs an offline-compatible equivalent.
Update lag by design. Because updates require a scheduled, manual transfer window rather than an automatic push, an air-gapped customer will typically run several releases behind the SaaS product at any given time, which has to be accounted for in the support and compatibility matrix.
A support and observability gap. Without remote log access, diagnosing an issue depends on the customer exporting and sharing logs manually, which is slower and requires its own documented process.

Why this is a roadmap decision, not a deal term

Once a vendor commits to one air-gapped customer, every future feature has to make an explicit decision: is it compatible with the offline deployment model, or is it deliberately excluded from that track? That constraint doesn't expire when the deal closes — it persists for the life of the contract, and once the precedent exists, it tends to resurface in the next enterprise or public-sector deal, because procurement teams talk to each other and reference what a vendor has already built for a peer organization.

Buyers who ask for air-gapped deployment are also, almost by definition, buyers with the strictest versions of the other enterprise-procurement gates: a formal change advisory board reviewing every update, and a vendor risk tier assignment at the highest level the buyer's program has. Treating the deployment model as a separate, isolated ask from those processes tends to underestimate the total operational commitment being made.

A hypothetical cost illustration

To make the trade-off concrete, take a simplified, hypothetical estimate: building the initial air-gapped release pipeline takes 6 engineer-weeks, and sustaining it — producing and qualifying each signed release for the offline track — takes roughly 1 engineer-week per quarter afterward. Over a 3-year contract, that's:

Initial build: 6 engineer-weeks
Ongoing: 12 quarters × 1 engineer-week = 12 engineer-weeks
Total: 6 + 12 = 18 engineer-weeks, or a bit over four months of one engineer's time, spent sustaining a deployment mode for a single customer segment.

These figures are illustrative only, not benchmarks from any real engagement — actual effort depends heavily on the product's architecture and how many air-gapped customers share the same release track. The point of the exercise is the shape of the cost: it's ongoing, not one-time, and it scales with time under contract rather than being absorbed in the initial deal.

How to decide instead of defaulting to yes or no

Treat it as a product and roadmap question, not a deal-desk exception:

Does the air-gapped segment (defense, critical infrastructure, classified environments) represent a durable, recurring market for the company, or is this a one-off logo?
If durable, assign a named owner for the offline release track and build the ongoing maintenance cost into pricing — not as a one-time "custom deployment fee" that doesn't reflect the multi-year sustaining cost.
Fold the CAB timeline and vendor risk tier requirements into the same evaluation, since these buyers will apply the strictest version of both — a single air-gapped deal is rarely just about air-gapping.

Sales can still say yes to the deal. What shouldn't happen is a yes that engineering leadership only learns about after signature — because at that point the roadmap decision has already been made for them.

General information about common air-gapped and offline deployment practices, not a description of any specific product architecture or contract, and not a substitute for legal or security review of a specific deal.