By the Onsites AI team · Last updated · 5-minute read
An air-gapped help desk is what you build when the rule is absolute: no conversation, customer record or attachment may cross the network boundary, ever — because the work touches defense procurement, clinical records, legal strategy, sovereign infrastructure, or a board that simply refuses to let another vendor's cloud see anything. The engineering is genuinely hard and mostly solved; the operating discipline is what teams underestimate. This guide walks the honest architecture, what the software can and cannot do without an internet line, and the habits that keep such a deployment running for years without heroics.
Strip the marketing and it is three sentences. The help desk runs inside your perimeter — on your LAN or your own cloud tenancy — shipped as a Docker deployment you pull once and then never talk to a vendor registry again. Every channel that needs the public internet (WhatsApp, Messenger, the public website widget) either reaches your front-end through your own reverse proxy, or is switched off entirely; email can run through your internal mail relay, and the widget can serve an intranet portal as easily as a public site. And the AI is yours by contract: Onsites never processes your data, because the model lives where you put it — your own API endpoint, an internal LLM service, or fully offline weights on a machine inside the gap.
The crucial property is not secrecy theater; it is the absence of channels. No telemetry, no license phoning home, no usage dashboards in someone else's cloud, no vendor-side feature flag turning something on without a deployment you control. If a byte leaves the perimeter, it left because one of your people moved it — which is an auditable, disciplinary matter, not an architecture question.
The core operation is complete inside the gap: the multi-channel inbox for internal channels, the CRM and its pipeline, quotes, orders, invoices, contracts, the product catalog, team chat, tags, SLAs, assignments, exports, audit trails. The AI copilots work when you provide a model — draft, polish, translate, summarize at the same credit-free economics (your model's compute is your cost, not a meter). What genuinely changes: outbound messaging channels end at your boundary (a helpdesk inside an air gap answers people inside the air gap, plus email you choose to bridge); automatic version updates become scheduled manual upgrades reviewed and applied by media; and the convenience of vendor-side backups is replaced by your own backup and restore regime — which you should have anyway.
Teams mean different things by the word, and it is worth naming which one you are building. The true gap: no route to the public internet at all; the desk serves internal staff on the intranet, email rides an internal relay, and every external transfer is physical and logged. The one-way bridge: inbound customer email passes through a gateway (mail sanitizer, DLP filter) into the perimeter while replies and files go out through the same chokepoint — the common regulated-enterprise shape, where the desk itself still touches nothing. The private tenancy: not air-gapped in the strict sense but sovereign in effect — the desk runs inside your own cloud account, in your chosen region, with no vendor-side access, and the network controls are yours to set. The cloud-versus-self-hosted checklist helps rank these by how much control each actually buys. Decide in writing before deployment, because the shape determines who runs the mail gateway, who signs the media ledger, and which of the habits below are yours.
The offline model is the one real engineering decision, and honesty about scale helps. A support copilot does narrow work — drafting from context, summarizing threads, translating a fixed set of language pairs, answering handbook questions with visible sources. That is a task profile modern mid-sized open-weight models handle well, and a single GPU server with modest VRAM serves a team of a hundred seats without breaking a sweat. The failure mode to design against is not model intelligence; it is model availability: put the endpoint behind the same care (restart policies, health checks, monitored disk) as the database, because half the desk's AI features degrade with it. Plan two paths from day one — an internal endpoint for daily use, and a smaller fallback model on the same VM — so a GPU maintenance window never snows the whole desk under.
Whether you run fully offline weights or point the desk at your internal API of a cloud provider's model is a policy decision, not a technical one; the BYO model guide covers the configuration of both. One practical note for the air-gap purist: translate-on-demand against a small local model consumes no bytes beyond your perimeter — the workflow survives intact, only the model's vocabulary limits your language pairs.
Air-gapped systems fail by neglect, not by attack, so the habits are calendar-shaped. A patch cadence and a change window: review release notes quarterly, test the upgrade on a staging copy of real data, and promote by media with a rollback snapshot taken the same hour. Backup drills, not backup jobs: the restore rehearsal — a quarterly, timed, documented restore to clean hardware — is the only proof your backups exist. A perimeter ledger: every physical medium that ever carried data across the gap (update images, model weights, restored exports) recorded with date, purpose and signer; auditors ask for exactly this and it costs a spreadsheet. Licensing arithmetic: the 10-seat annual license is the only commercial tie to the vendor, and nothing about it requires connectivity — which is the whole point.
Finally, staff the desk like the infrastructure it is. The organization that treats an air-gaped desk as "just a server" discovers, mid-incident, that nobody owns the model endpoint; the one that assigns named owners for deployment, model, backups and upgrade approval runs for years on a shrug. The software part of air-gapping is a solved problem — the deployment guide is a morning's work. The operating culture around it is the product you are actually buying, and every habit above is cheaper in calm than in incident.
Can a help desk run completely without internet access?
Yes — with self-hosted deployment the desk runs on your LAN or private cloud via Docker, all core features (inbox, CRM, quotes, invoices, contracts, team chat) work offline, and AI functions run against your own model endpoint or fully offline weights. Outbound messaging channels end at your network boundary by design.
How does AI work if there is no cloud connection?
You provide the model: an internal LLM service, your own API endpoint, or fully offline open weights on a server inside the air gap. Drafts, translations, summaries and handbook Q&A all run against it, and vendor AI fees disappear because compute is yours.
What happens to software updates in an air-gapped environment?
Updates are reviewed, staged and applied manually on your cadence — typically quarterly — by moving update images across the gap on media, testing against a staging copy, and keeping a rollback snapshot. Nothing updates itself; nothing phones home.
Where do backups live in an air-gapped deployment?
On infrastructure you own: NAS, tape or an offline copy, scheduled by your backup scripts from the deployment guide. The vendor holds nothing, so scheduled restore rehearsals — a timed quarterly restore to clean hardware — are the only proof the backups work.
Does the air-gapped version have fewer features than the cloud one?
No — the software is the same product. The differences are operational: channels that require the public internet are switched off or bridged by you, updates are manual, and backups are your responsibility instead of automated cloud ones.