> 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/setup-apps-os/on-prem.md). # On-prem and air-gapped environments Some customer environments cannot reach Seal's hosted services from the hosts that need sealed packages: strict egress policies, internal-only CI clusters, regulated networks with curated allow-lists, fully air-gapped facilities. The Seal CLI does not run in these environments — without connectivity to Seal's servers, the CLI cannot fetch sealed packages or read remote rules — and the standard CI/CD and live-host setup patterns do not apply. The workflow here is built around the Seal Repository page on a connected machine. You download sealed packages manually from there, then either install them by hand on each host, or upload them to an internal artifact server and let the host's native package manager pull from there. Both paths cover Seal Apps (application-level dependencies) and Seal OS (operating-system packages) with the same shape. ## Step 1: download sealed packages from the Repository page From a machine with internet access, browse the [Repository page](/discovering/repository-page/sealed-packages.md). On a package's detail page, the **Download** action gives you the artifact for the ecosystem — the `.tgz` for npm, the `.whl` for Python, the `.jar` for Maven, the `.rpm` / `.deb` / `.apk` for OS packages, and so on. The dialog lets you pick the specific sealed iteration to download. For each vulnerable package you want sealed in your environment, repeat the download for the relevant iteration. The artifact you receive is the same one a connected build would have pulled from Seal's hosted artifact server — no on-prem-specific repackaging step is required.
The Download dialog on a sealed package's detail page on the Repository page, with the version selector and download button visible

The Download dialog on a sealed package's detail page.

## Step 2: deliver to your hosts Once you have the artifacts on a machine you control, two delivery options. ### Manual installation per host For small fleets, one-off remediation, or environments without an internal artifact server, copy each sealed artifact to the target host and install it through the host's native package manager (for Seal OS) or the build's normal dependency-resolution mechanism (for Seal Apps). The sealed artifacts are the same format as the corresponding upstream artifacts, so any pattern your team already uses to install a downloaded package by hand applies unchanged. The work is to get the file onto each host that needs it. ### Internal artifact server For larger fleets or recurring use, upload the downloaded sealed packages to your internal artifact server (Nexus, Artifactory, an internal Alpine / Debian / RPM / npm / Maven / PyPI repository) and configure each host or build to pull from the internal server. The configuration on the host is the same configuration you would use for any other internal mirror — the sealed packages look like regular packages from the artifact server's perspective. For Seal Apps, this means pinning the sealed version (`2.7.4-sp1` instead of `2.7.4`) in the build's manifest. For Seal OS, this means adding the internal repository to the host's package-manager sources alongside its existing ones; the next native upgrade cycle picks up the sealed versions. After a publish to the internal server, follow the artifact server's normal metadata-regeneration step so clients see the new packages. ## Authentication Authentication is needed on the connected side for the Repository download. The hosts that consume the sealed packages — whether installing manually or pulling from your internal artifact server — do not authenticate with Seal at all. No `SEAL_TOKEN` is needed on those hosts. ## What this deployment does not include Several Seal Platform features depend on the CLI running and reporting back to the platform. They do not apply to on-prem deployments: * **Sealing Rules**: the rule mechanic governs CLI behavior. Without the CLI, rules have no effect. The Sealing rules tab being empty is not a problem for an on-prem deployment. * **Protection page visibility for these hosts**: nothing reports back from the host side, so the Protection page does not list these hosts' installed packages and does not move row states. Discovery for the affected Seal Project happens through whatever other mechanism you have configured (a connected CI pipeline, an imported manifest, a connected scan elsewhere). If none of those apply, the project has no platform-side visibility. * **Email notifications about new sealed iterations**: these fire based on what Seal sees you using. With no platform-side usage, no notifications. Customers on this deployment learn about new sealed iterations through their Seal account team. To roll forward, repeat the download-and-deliver cycle for the newer iteration. ## Related * [Choosing your deployment method](/setup-apps-os/choosing-deployment-method.md): the decision page that places this pattern against the four other deployment methods. * [The Repository page](/discovering/repository-page.md): the catalog and download page this workflow centers on. * [Working with Seal Apps under Manual](/using-platform/working-with-seal-apps/manual.md): the day-2 operating rhythm for application dependencies in this pattern. * [Working with Seal OS in air-gapped environments](/using-platform/working-with-seal-os/air-gapped.md): the day-2 operating rhythm for OS packages.