§02 — Exo Control Plane

Air-gapped & private registries

Running Exo from a private registry, with no public-internet access, is supported. Mirror the images, point the operator at your registry, and nothing reaches out.

5 min read·Set by Exo Editorial·v0.3.0 Beta

Air-gapped and egress-restricted clusters are supported. Beyond its own image, the agentkube-manager launches pods from a set of published container images; for an offline install you mirror those images into your own registry and point the operator at it — no code changes, no public pulls.

Supported

There are two offline shapes, depending on what the cluster can reach:

  • Private registry, still managed. The cluster can reach your platform but not the public registry — mirror images locally and keep the operator connected to the control plane.
  • Fully offline. The cluster can't reach anything external — mirror images and run the operator unmanaged (see below).

Point at your registry

Set one variable on the manager Deployment and every default image reference is rewritten to your mirror — no need to override images one by one:

manager env· yaml
1 env:
2 - name: AGENTKUBE_IMAGE_REGISTRY
3 value: registry.example.com/exo-mirror

Individual images can also be overridden one at a time when a specific one lives elsewhere, and a single Agent or Tool can pin its own image — useful when only part of the fleet is mirrored.

Pull secrets

For a private mirror, add image pull secrets. Via Helm that's image.pullSecrets; for raw manifests, attach an imagePullSecrets to the operator's ServiceAccount so both the manager and the pods it creates can pull.

Fully offline

If the cluster can't reach the platform at all, run the operator unmanaged (AGENTKUBE_MANAGED=false, the default). Agents, Tools, and the rest still reconcile and run from your mirrored images; nothing is sent to a control plane. You lose the dashboard view and centralized audit, but the runtime is fully functional in-cluster.