How We Designed Geta.Team for Air-Gapped Deployments (and Why You Probably Shouldn't Need One)

Every few weeks somebody lands in our inbox asking whether Geta.Team can run air-gapped. The conversation usually opens with the word "DORA" or "HIPAA" or "EU AI Act" and continues with the buyer describing a deployment so isolated that even the typing of a password requires a court order. Two-thirds of these conversations end with the buyer realizing they don't actually need air-gapped — they need VPC, with strict outbound rules and an audit trail. Both can be done. They are very different operational commitments.

This is a piece about how we think about the three deployment tiers, what each one costs you in operational tax, and which one most regulated buyers actually need (versus the one they ask for first).

The three tiers

Self-hosted is not a single thing. There are three meaningfully different deployment modes that get lumped together under the same word, and the gap between them is the difference between a Tuesday rollout and a six-month procurement cycle.

Tier A — VPC / private cloud, vendor-managed control plane. The agent runtime, your data, and your credentials live inside your VPC. The vendor's control plane (deployment orchestration, software updates, observability hooks) lives on the vendor's infrastructure and reaches in over a tightly scoped private link or signed webhook bus. This is the default for most regulated buyers because it gives you data sovereignty without making you the operator of a complete platform. About 70% of the "self-hosted" conversations we have end here.

Tier B — fully customer-operated, vendor-supported. The vendor ships you the software (containers, license, support contract). You operate everything: the runtime, the upgrade cycle, the patches, the observability stack, the integration adapters, the on-call rotation. The vendor's role is software vendor, not service operator. This is the right mode for buyers who have a real platform team and a meaningful regulatory or contractual reason not to have any vendor reach-in. About 25% of our self-hosted conversations land here.

Tier C — air-gapped. No network connectivity to vendor infrastructure. No telemetry, no auto-update, no remote troubleshooting. Updates arrive on physical media or via an internal artifact mirror. The customer's security team owns every byte that crosses the network boundary, and the answer to "can the agent fetch this OpenAPI spec at runtime?" is "no, you pre-bundle it." About 5% of self-hosted conversations actually need this. Most of the buyers who ask for it are pricing it out for posterity, not for a real deployment.

The reason this matters is that the operational tax compounds. Tier A adds a few hours of network policy review at the customer's end. Tier B adds an upgrade cycle, a runbook, an on-call rotation, and a budget line for patch management. Tier C adds an offline artifact mirror, an internal CA, an internal signing key infrastructure, an isolated CI pipeline, and a custom integration story for every external API that the agent is allowed to call (which is approximately none of them by default).

How Geta.Team is built for each tier

Three architecture decisions made the multi-tier story actually work. We didn't bolt them on; they were the structure from the start, because retrofitting later is its own six-month project.

Decision one: containers as the deployment unit. Every virtual employee runs in its own container with its own scoped credentials, its own memory store, and its own task queue. That's a feature for security (blast radius is bounded to one agent if anything goes wrong), but it's a much bigger feature for portability. The same container runs identically on the vendor's managed VPC, on the customer's bare-metal kubernetes cluster, and on an air-gapped on-prem rack. The deployment tier changes; the unit of deployment doesn't.

Decision two: configuration as the only thing that varies between tiers. Tier A's "vendor reaches in to do X" is configured the same way as Tier B's "internal SRE does X" — both are just policy entries in the same control plane abstraction. The agent code doesn't know whether it's running in a VPC with a vendor-managed orchestrator or on an air-gapped rack with a manual update cron. It reads its config at startup and behaves accordingly. The number of code paths that depend on deployment tier is zero. We're proud of that and we audit for it on every release.

Decision three: BYOA is non-negotiable. Bring-your-own-API-key is the only model that survives all three tiers without a per-tier carve-out. The customer's tokens hit the customer's chosen model provider directly from the customer's network. The vendor (us) never sees the prompt or the completion. This gives Tier A buyers data residency, gives Tier B buyers vendor-decoupling, and gives Tier C buyers the only feasible answer to "where does the model run?" — wherever the customer chooses, including a private deployment on their own infrastructure if they want to put a Llama or a private OpenClaw fork inside the perimeter.

The combination is that "moving up a tier" is a procurement and operations question, not a software question. Tier A → Tier B is roughly a week of work for a competent platform team. Tier B → Tier C is several months — but it's several months of compliance, signing infrastructure, and procurement, not several months of waiting for the vendor to ship you a different product.

Why most regulated buyers don't actually need Tier C

Here's the part that saves most buyers the most money: read your actual regulation, not the LinkedIn version of your regulation.

DORA's "ICT third-party risk" requirements demand auditability, exit clauses, and operational resilience — they do not require zero network connectivity to your vendor. Tier A satisfies DORA cleanly with the right contract.

EU AI Act enforcement (starting August 2026 for high-risk systems) requires logging, transparency, and risk management. None of that requires air-gapped — it requires a vendor that gives you log access and a documented risk register.

HIPAA-equivalent regimes care about PHI handling, BAAs, and data residency. BYOA + VPC handles all three.

The actual regulatory case for Tier C is narrow: nation-state-grade IP protection (defense, certain pharma), classified data handling, or specific contractual obligations from a customer who themselves has Tier C requirements. If you're not in one of those buckets, Tier C is overspending against your real risk model.

The cost of overspending isn't just procurement budget. It's operational momentum. Tier C buyers ship agents in months. Tier A buyers ship them in weeks. The competitive advantage of agentic AI in 2026 is going to compound for the buyers who are running production faster, not for the buyers who built a perfectly air-gapped platform that nobody is using yet.

What to do if you're a buyer evaluating this

Three diagnostic questions before you spec your deployment tier:

• What does your actual regulatory text say about vendor connectivity, versus what your CISO's LinkedIn comments say?
• Does your security team have an existing VPC pattern with audited outbound rules that has handled SaaS vendors before? If yes, Tier A drops in. If no, you have a bigger problem than your AI vendor.
• How fast can you ship a Tier A pilot, watch how it actually behaves under your audit regime, and then decide whether you need to escalate to B or C? The answer is almost always "way faster than the procurement cycle for Tier C."

We're happy to scope any of the three. We just want you to pick the one your regulation requires, not the one that pattern-matches to the strictest comment in last week's compliance meeting.

Want to test the most advanced AI employees? Try it here: https://Geta.Team