DEPLOYMENT SCENARIO · VERIFIED 2026-08-05

Air-gapped AI coding: what isolation actually requires.

MonkeyCode’s public documentation describes private and offline deployment. Running it truly air-gapped — with no outbound path at all — is achievable but shifts every network dependency into your boundary: model inference, package sources, images, and updates. This page maps what is documented, what you must provide, and how to verify the isolation you are claiming.

Definition first

Air-gapped means zero egress, not just self-hosted.

A platform can sit entirely on your servers and still call out for model inference, dependency downloads, or telemetry. The useful test is not “where is it installed” but “does any byte leave the boundary while it works”.

Self-hosted

You control where the control plane and execution environments run. Outbound routes to model APIs, Git providers, and registries may still exist and must be mapped. See the self-hosted field guide.

Egress-controlled

Outbound traffic is restricted to an approved allowlist — model endpoints and mirrors you chose. Most regulated deployments land here. See egress control.

What you must provide

Isolation moves five responsibilities inside your boundary.

These are operational requirements of any air-gapped platform, not undocumented product claims.

01 · Model inference

A locally served model endpoint with the hardware to run it. Which families fit your quality and cost bar is an evaluation question — see supported models and local models.

02 · Package and image mirrors

Internal mirrors for every package registry and container image the platform and your builds pull from, kept current by a controlled process.

03 · Update path

A repeatable offline upgrade procedure — download, verify, transfer, apply, roll back — since nothing updates itself inside the boundary.

04 · Source control and credentials

Git hosting inside the boundary, with per-task credential scope. Isolation does not replace least privilege.

05 · Evidence

Egress monitoring at the boundary that can prove, per task run, that nothing left. “Air-gapped” is a measurement, not a label.

Verification sequence

Prove the isolation before trusting it.

  1. 01
    Install offline

    Perform the documented installation with the network boundary already closed; record every dependency that had to be provided manually.

  2. 02
    Run representative tasks

    Execute real build, test, and agent workflows with non-sensitive code while capturing all boundary traffic.

  3. 03
    Audit egress

    Zero outbound connections during install, task execution, and upgrade is the acceptance criterion — investigate anything else.

  4. 04
    Rehearse the update

    Apply one full offline upgrade cycle, including rollback, before the deployment carries production work.

Common questions

Air-gapped operation, answered.

Related: air-gapped platform guide, security boundaries, architecture and trust boundaries, capacity calculator.

Can MonkeyCode run air-gapped?
MonkeyCode’s public deployment documentation describes private and offline deployment. Air-gapped operation — no outbound internet path — is therefore a documented direction, but every dependency the platform normally reaches over the network (model endpoints, package sources, images, updates) must be provided inside your boundary and verified in the release you deploy.
What is the difference between self-hosted and air-gapped?
Self-hosted means the platform runs on infrastructure you control; it may still open outbound connections for model inference, packages, or updates. Air-gapped adds the stronger constraint that no traffic leaves the boundary at all, which shifts responsibility for models, mirrors, and updates entirely to your environment.
Which models can an air-gapped deployment use?
Only model endpoints reachable inside your network — typically locally hosted open-weight models. Public README materials list several model families; which of them you can serve locally, at what hardware cost, is an infrastructure decision to validate before committing to full isolation.
How do I verify a deployment is actually air-gapped?
Test it: run representative tasks while monitoring egress at the network boundary. A deployment is only air-gapped if the monitoring shows zero outbound connections during install, task execution, and upgrades — not because a diagram says so.
Does air-gapped operation make the deployment secure by itself?
No. Isolation removes exfiltration paths but does not remove prompt injection, over-permissioned credentials, or missing review gates. Those controls still have to be configured and tested inside the boundary.
PLAN THE DEPLOYMENT

Size the hosts, then verify the boundary.