Air-gapped deployments
Some environments have no network path to your manager at all. They run the same application as every other Kubernetes deployment. Releases go in, and state and logs come back, in one folder the site's admin carries across the gap.
online machine the folder inside the site
alien-deploy sync ───▶ site-7-sync/to-site ───▶ alien-deploy sync
sends reports, verifies, installs,
downloads the update ◀─── site-7-sync/from-site ◀─── writes a reportYou run alien release as usual. Everything else happens at the site, with alien-deploy sync on both sides. It works the same with a manager you run and with alien.dev.
Onboard the site
alien onboard site-7 --platforms kubernetes --airgappedThis registers the deployment and prints three things for the site's admin:
| Token | The site's deployment token. It stays on the online machine: it can download this site's updates and send its reports, nothing else. |
| Key | Your manager's bundle key (ed25519:...). Every update is signed with it. Confirm it with the site's admin by phone or email, separately from the token. |
| Start | The command that starts the first sync: alien-deploy sync --token ... --manager https://... |
The site shows up in alien deployments ls as site-7/site-7.
First sync, online
On a machine that can reach your manager:
alien-deploy sync --token ax_... --manager https://manager.example.comThis creates site-7-sync/ and downloads the release the site should run into it. An update holds the application's images, the images the chart runs (the Operator and its cleanup hooks), the Helm chart, the deployment's target, and alien-deploy builds for the site. A manifest lists every file's SHA-256, and your manager signs the manifest.
The token is saved on this machine, readable only by its owner, and never written into the folder.
First sync, inside the site
Carry site-7-sync/ into the site. From the directory that holds it, on a machine with kubectl and helm access to the cluster:
alien-deploy sync \
--registry registry.internal/vendor \
-f values.yaml \
--trusted-key ed25519:...sync checks the signature against the trusted key and every file against its checksum. It then pushes the images to the site's registry by digest, installs the chart pointed at them, waits until the application is running, and writes a report into the folder. values.yaml connects the site's infrastructure the same way as a connected install (see Connect the customer's infrastructure).
The install remembers the key. Later updates don't need --trusted-key, and an update signed with any other key is refused. The registry, namespace, values and Kubernetes context are remembered on this machine too.
| Option | Description |
|---|---|
--registry | Registry and optional path for the images |
--registry-username, --registry-password | Registry credentials (or AIRGAP_REGISTRY_USERNAME, AIRGAP_REGISTRY_PASSWORD). They become the image pull secret of the Operator, its hooks and the application, and later syncs reuse them from there. |
--trusted-key | The bundle key, on the first install (or ALIEN_TRUSTED_KEY) |
--insecure-registry | The registry serves plain HTTP |
-n, --namespace | Namespace (defaults to the application name) |
-f, --values | Helm values for this site |
--kube-context | Kubernetes context (defaults to the current one) |
Every sync after that
Run alien-deploy sync with no options, on whichever side the folder is:
- Online, it sends the site's reports to your manager and downloads the next update, if there is one.
- Inside the site, it installs the update and writes a new report.
On a machine that reaches both the manager and the cluster, one run does both.
Updates only carry image layers the site doesn't already have, so after the first one they're usually small. For a site whose reports never come back, alien-deploy sync --full includes every layer.
alien-deploy sync --dry-run shows what would happen without changing anything: inside the site, it verifies the update and lists the release change, the images and the chart resources that would change.
What the site sends back
A report holds the deployment's state and the telemetry the Operator collected from this application's pods since the last report. Other applications in the namespace are left out. When a report reaches your manager, alien deployments ls shows the site's status and release, and the logs go where connected deployments' logs go: alien logs --deployment site-7/site-7 and your OpenTelemetry backend.
Nothing is lost between trips. The Operator keeps telemetry until an update confirms your manager received it (up to 512 MiB by default; AIRGAP_TELEMETRY_BUFFER_BYTES on the Operator changes the limit). Reports that overlap are sent once.
Rollback
alien-deploy rollbackReturns the site to the release it ran before the last sync, from the copy kept in the folder, and writes a report so your manager sees the change.
Updates
Every alien release reaches the site on its next sync. The update includes the Operator version your manager runs, so the Operator is updated along with the application. Release channels and pins apply to air-gapped sites the same way.