Air-gapped DevSecOps for regulated teams

When SaaS is a non-starter

For most teams, a cloud-hosted platform is the easy default. For a specific and growing set of teams, it is simply not allowed.

Government agencies, defense, banks, healthcare, and critical infrastructure operate under rules that a SaaS pipeline cannot satisfy: data must not leave a controlled boundary, systems may run with no inbound internet at all, and every tool in the delivery chain has to run inside the perimeter. "Just use our cloud" is the end of the conversation.

That constraint does not remove the need for a modern platform. Regulated teams still want golden paths, policy gates, and audit trails. They just have to get them on their own infrastructure, sometimes fully air-gapped. This is one of the least-served corners of the platform market, and one of the most important to get right.

What "air-gapped" actually requires

Air-gapped is a stronger claim than "self-hosted." A lot of "on-prem" software still phones home for licensing, updates, telemetry, or AI features. In a true air gap, none of that is available. A platform that works here has to satisfy every one of these:

• No outbound dependency at runtime. No license check, no telemetry beacon, no "call the vendor's API to do X." If a feature needs the internet to function, it does not exist in the air gap.
• Offline updates. New versions arrive as a signed bundle you bring across the boundary and apply, not a pull from a public registry.
• No data egress, ever. Source, build metadata, secrets, and audit records stay inside the perimeter. This is the whole point.
• On-premises AI, or none. The coding and review assistants entering every pipeline cannot be a call to a public model. Either the model runs inside the boundary or the feature is off.

If any one of these leaks, it is not air-gapped. It is on-prem with an asterisk.

Governance without the cloud

The hard part is keeping strong governance when you cannot lean on a managed control plane. Two mechanisms carry most of the weight.

Tenant isolation enforced at the data layer. In a multi-team platform, "team A cannot see team B's data" should not depend on every query remembering to filter correctly. Enforcing isolation at the database layer, so a session with no tenant context returns nothing rather than everything, makes isolation fail closed. Defense in depth in the app is good, but the database being the backstop is what makes it trustworthy.

A tamper-evident record. In a regulated environment, the audit trail is the product. What shipped, who approved it, which scans ran, and what policy decided each gate all have to be recorded in a way that resists after-the-fact editing. When evidence is a byproduct of every pipeline run rather than something assembled before an audit, the audit stops being a fire drill.

Neither of these requires a cloud. Both require the platform to treat governance as a built-in property, not a hosted service.

Compliance bundles, not compliance theater

A quick note on language, because it matters in regulated buying. A platform does not make you compliant, and no honest vendor should claim it certifies you. What a good platform does is ship the controls and evidence that a given regime expects as reusable policy bundles: the gates, the required checks, and the record-keeping mapped to the framework you answer to. Your auditor still audits you. The platform makes the evidence real and the controls consistent instead of hand-assembled and self-attested.

Treat any "certified compliant out of the box" claim with suspicion. The useful claim is narrower and true: the controls and the evidence are built in.

A short checklist for regulated buyers

If you are evaluating a platform under a hard sovereignty or air-gap constraint, confirm these before anything else:

1. Does it run with zero outbound network at runtime? Ask them to prove it, not assert it.
2. Are updates offline and signed?
3. Is tenant isolation enforced at the data layer, fail-closed?
4. Is the audit trail tamper-evident, and is it produced automatically?
5. If it offers AI features, do they run inside your boundary?
6. Do the compliance controls ship as bundles mapped to your framework, described as controls and evidence rather than certification?

Where IntegraCI fits

IntegraCI is a control plane that can run entirely on your infrastructure, including air-gapped. It connects to the tools you already run inside the perimeter, generates golden-path pipelines, gates every change against policy, and records a tamper-evident trail, with tenant isolation enforced at the data layer so it fails closed. Its AI features run on your own model and infrastructure, so "governed AI" does not become "data egress." Compliance ships as policy bundles mapped to the frameworks you answer to, as controls and evidence, not a certification claim.

If sovereignty or an air gap is your hard constraint, that is exactly the case this is built for.

See the sovereign deployment model or review the security architecture.