Factory Private
Airgapped Deployment
Air-gapped AI development that works offline
September 18, 2026 - 2 minute read
Air-gapped AI development fails when an apparently local workflow reaches for an unavailable service. A test runner may download a browser. A dependency resolver may query a public registry. A model gateway may forward requests outside the network.
The acceptance test must cover a complete development task, including its supporting tools. Starting the agent offline is only the beginning.
Air-gapped AI development needs an internal model
Factory provides a dedicated enterprise airgap build of Droid. Its deployment contract states that it skips sign-in, update checks, session synchronization, crash reporting, and Factory telemetry.
The build uses customer-configured models only. Factory-managed models and Factory Router are unavailable, and Droid refuses to start a turn without a custom model. Configure the approved internal endpoint and test it from the actual workstation or runner.
Use a representative repository with known tests. A successful chat response does not prove that the model endpoint handles tool calls, longer context, or repeated interactions correctly.
Enforce air-gapped AI development outside the model
Airgap Mode provides offline behavior. The network supplies the isolation boundary. Factory's published enforcement table makes that division explicit.
Screenshot of the linked airgap documentation, captured September 18, 2026.
Review every configured destination, including model endpoints, Git remotes, MCP servers, collectors, and plugin sources. Commands can create connections too. Use infrastructure and sandbox rules to constrain them independently of the model's instructions.
Test a harmless request to an unapproved destination and record the rejection. Also restrict local access. An isolated network may still contain credentials and sensitive files unrelated to the assigned task.
Import a usable development environment
Prepare the source, runtime, packages, build tools, and test fixtures through the approved artifact process. First reproduce the task without the agent. That separates environment problems from problems in a proposed patch.
Factory's BYOK reference describes custom-model configuration. Use the compatible provider interface and approved credential path. Include model-service failure and credential expiry in the acceptance test.
Distribute policy through system-managed settings or an approved internal endpoint. Check that the actual execution account receives it. A configuration file on an administrator's machine is insufficient evidence for a fleet.
Keep internal documentation and dependencies current together. Instructions that name unavailable package versions can make a disconnected workflow impossible even when the network configuration is correct.
Plan collaboration, evidence, and updates
The offline feature set changes the workflow. Slack integration, cloud session sharing, built-in web lookup, and Factory-hosted analytics are unavailable. Local capabilities such as Missions, hooks, installed skills, and configured MCP servers remain usable when their dependencies are available internally.
Factory's telemetry documentation specifies customer-only export in an airgap. Without a usable customer collector, the pipeline does not run. Use internal source-control and validation records to preserve the reviewed change.
Rehearse an update and rollback in a disposable environment. Record the approved artifacts, active policy, model configuration, and validation result. Then restore the previous setup and confirm that operators can repeat the task.
A useful pilot proves the offline lifecycle, not only an isolated demonstration. Expand after the team can reproduce the build, enforce the boundary, review the output, and recover from a failed dependency.
