> For the complete documentation index, see [llms.txt](https://docs.sealsecurity.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sealsecurity.io/using-platform/working-with-seal-os/air-gapped.md). # In air-gapped environments In air-gapped environments, the host has no outbound connectivity to Seal's hosted artifact servers. The Seal CLI is not used inside the air-gap: the CLI cannot reach the Seal Platform or the OS-package artifact servers, and it does not have an internal-mirror configuration. The deployment shape is instead built around the customer's existing OS-mirror infrastructure: sealed packages are pulled from Seal on the connected side, transported into the air-gapped network, published to an internal repository, and applied on the host by the native package manager (`apk`, `apt`, `dnf` / `yum`). The setup-side mechanics — what to mirror, how to publish to an internal Alpine / Debian / RPM repository, and how to configure each host's package manager — are covered under [On-prem and air-gapped environments](/setup-apps-os/on-prem.md). This page covers the day-to-day operation once that setup is in place. ## The recurring rhythm The four steps from [Working with the platform](/using-platform/working-with-the-platform.md), specialized for air-gapped Seal OS: 1. **Review** what is available. The Vulnerable packages tab on the Protection page does not see your air-gapped hosts — the CLI does not run there and nothing reports back. Use the [Repository page](/discovering/repository-page/sealed-packages.md) on a connected machine to browse what Seal has published for the OS packages you mirror, or check with your Seal account team. 2. **Decide what to bring in.** Refresh your internal mirror to include the sealed iterations you want available to your hosts. The mechanics depend on your mirror tooling and are covered in the setup chapter. 3. **Let the hosts pick up the changes.** On the next patching cycle, each host's native package manager (`apk upgrade`, `apt-get upgrade`, `dnf upgrade`) sees the new sealed iterations in the internal repository and applies them. 4. **Verify on the host.** Confirm via the native package manager: `apk info -v `, `dpkg-query -W `, or `rpm -q `. The Protection page does not reflect air-gapped hosts at all. ## What the platform does and does not show The Seal Platform shows what `seal fix --os` reports — and `seal fix --os` does not run in this deployment. The consequence: * The Vulnerable packages tab does not list your air-gapped hosts' installed packages. * Email notifications about newly available sealed versions, which fire based on what Seal sees you using, do not fire for these hosts. * Audit reports built from Protection-page data do not cover these hosts. If you need that coverage for an audit, build it from the host-side inventory you already collect (the SBOM your existing tooling produces, the package-manager queries above, or whatever your internal vulnerability-tracking workflow consumes). Everything Seal-side that depends on visibility into customer usage is absent here by construction. This is a property of the air-gapped deployment, not a missing feature. ## Common situations ### A new vulnerability is disclosed in an OS package you have installed You learn about this through your existing vulnerability-tracking workflow, not through the Seal Platform. Once you know, check the Repository page for a sealed iteration that addresses it; if one exists, pull it into your mirror and apply on the next patching cycle. If Seal needs to publish a new iteration, your account team can confirm timing. ### A host fails after patching from the internal mirror Same diagnostic process as [on live hosts](/using-platform/working-with-seal-os/on-hosts.md#a-host-fails-after-patching): in the overwhelming majority of cases, the sealed package is not the cause. Roll back through the package manager, confirm the hypothesis, and contact your account team with the logs if the sealed package is implicated. ### The internal mirror has the iteration but the host did not pull it Operational issues that look like Seal problems but are really mirror or package-manager issues: * The host's package-manager configuration points at a stale repository location. * The mirror's metadata was not regenerated after the new packages landed. Each package manager needs a metadata refresh after a publish (`createrepo` for `rpm`, `apt-ftparchive` or `reprepro` for `deb`, an index rebuild for `apk`) before clients see new packages. * The host's release codename or architecture variable does not match the directory layout in the mirror. ## Related * [On-prem and air-gapped environments](/setup-apps-os/on-prem.md): the setup chapter covering the mirror configuration and per-distribution package-manager settings. * [Working with Seal OS on live hosts](/using-platform/working-with-seal-os/on-hosts.md): the connected-side counterpart. The patching cadence and per-host operations are similar; the difference is the source of sealed packages. * [The Repository page](/discovering/repository-page.md): browse sealed packages from a connected machine.