# Choosing air-gapped

> The air-gapped option for agents on the organisation's own servers: what changes, what the stack contains, and how the site reports to LightHouse.

An air-gapped site is a deployment on the organisation’s own servers with no network path to LightHouse™. For such a site, LightHouse writes the stack in the engine’s offline mode, and the set-up mission counts the site as reporting once its first telemetry bundle has been imported.

## Requirements

| Requirement        | Detail                                                                                         |
| ------------------ | ---------------------------------------------------------------------------------------------- |
| Role               | `client_admin`                                                                                 |
| Where agents run   | **Your own machines**. A cloud deployment always has an outbound path and cannot be air-gapped |
| Deployment profile | Always-on. The offline relay keeps its spool on persistent disk                                |

## Selection

On **Where agents run**, choose **Your own machines**, then under **How it reaches LightHouse**:

| Option               | Meaning                                                                                                            |
| -------------------- | ------------------------------------------------------------------------------------------------------------------ |
| **Online** (default) | One outbound connection to LightHouse, direct or through the organisation’s proxy. Telemetry and commands are live |
| **Air-gapped**       | No network path to LightHouse. Data that would cross the network is transferred by hand as signed files            |

The choice is recorded in the tenant’s audit log. Through the API, `PUT /api/v1/run-targets` takes `connectivity`: `online` or `air_gapped`. A request for air-gapped with a cloud, or with a profile other than always-on, is refused.

## Differences from an online site

| Area                  | Air-gapped behaviour                                                                              |
| --------------------- | ------------------------------------------------------------------------------------------------- |
| **Telemetry**         | Written to signed bundle files, transferred and imported in LightHouse                            |
| **Commands**          | Exported from LightHouse as a signed command file; results return the same way                    |
| **Images and models** | Taken from Atlantic’s signed mirror and loaded into the organisation’s own registry and disk      |
| **Content**           | Not read in place. LightHouse shows records and metrics only, current to the last imported bundle |

[Air-gapped operation](/clouds/on-premises/#air-gapped-operation) describes how each file is signed and verified; the integrity of a transfer does not depend on the person who carries it.

## Stack contents

**Get my stack** for an air-gapped site writes the same Compose stack as for an online site, with these differences:

| Component                               | Air-gapped configuration                                                                                                            |
| --------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| Relay                                   | Offline mode: makes no outbound requests, seals signed bundles into its spool, has no proxy setting                                 |
| Content reader and live command channel | Not included                                                                                                                        |
| Command handler                         | File-based: applies a signed command file placed in `./carry/in` and writes signed results to `./carry/out`                         |
| `.env`                                  | Takes images from the organisation’s own registry through one setting, which the mirror tooling rewrites; every digest is unchanged |
| Guide                                   | `lighthouse-air-gapped.md`, with the round trip in the engine’s and the CLI’s commands, and the tenant and deployment filled in     |

## Procedure

1. **Once per release**: pack the images and models on a connected machine, transfer them, verify them on the site, and load them into the registry and model directory.

   Result: the release’s images and models are available on the site with their digests verified.

2. Start the stack and run its check.

3. **Telemetry out**: export the bundles written since the last one LightHouse holds, verify them, transfer them and import them in LightHouse (on the deployment’s page, or with `lighthouse-ai telemetry import`).

   Result: the deployment’s page shows the time of the last imported bundle.

4. **Commands in, results out**: export the command file from LightHouse (or with `lighthouse-ai commands export`), transfer it to the site and apply it; return the results with the next bundles.

   Result: the command results appear in LightHouse when that bundle is imported.

## Set-up mission

The **See your stack report in** step is complete for an air-gapped site once a telemetry bundle from it has been imported. See [Organisation set-up](/enterprise/#in-the-set-up-mission).

## Manual settings

**Get my stack** does not yet write two settings for a site with no internet access; they are added to the `.env` by hand: the offline profile for local inference, and the setting that loads retrieval’s models only from the installed mirror. [Self-hosted models](/clouds/on-premises/#self-hosted-models) and [Air-gapped operation](/clouds/on-premises/#air-gapped-operation) describe both.

Source: https://docs.atlanticagenticlabs.com/enterprise/air-gapped/