> 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.md). # Working with Seal OS Seal OS remediates vulnerabilities in OS-level packages: the Alpine `apk`, Debian and Ubuntu `apt`, and Red Hat / CentOS / Amazon Linux `rpm` packages that ship on a Linux host or inside a Linux container. The everyday work cycles through the same review-decide-build-verify rhythm as Seal Apps, but the shape of "build" differs between deployment contexts. Subpages for each: * [In CI/CD](/using-platform/working-with-seal-os/in-cicd.md) — `seal fix --os` runs inside a `Dockerfile` during `docker build`. Image builds are the trigger; every release of the image carries an up-to-date sealed OS layer. * [On live hosts](/using-platform/working-with-seal-os/on-hosts.md) — `seal fix --os` runs against a running Linux host (a VM or bare-metal server) with outbound access to Seal's hosted artifact servers. Scheduled patching runs are the trigger; sealed OS packages replace the host's installed ones in place. * [In air-gapped environments](/using-platform/working-with-seal-os/air-gapped.md) — hosts with no outbound access. The Seal CLI is not used; sealed packages are mirrored from Seal to an internal repository and the host's native package manager applies them. ## What this chapter does not cover * The setup mechanics of either deployment shape. Those live under [Seal OS in CI/CD](/setup-apps-os/seal-os-cicd.md) (for CLI-driven flows, in CI or on a connected host) and [On-prem and air-gapped environments](/setup-apps-os/on-prem.md) (for environments where hosts cannot reach Seal directly). * The Sealing Rules mechanic. Seal OS uses the same model as Seal Apps; see [Sealing Rules](/using-platform/sealing-rules.md). * The `seal fix --os` flag reference. Lives at [`seal fix --os` reference](/setup-apps-os/seal-os-cicd/seal-fix-os-reference.md). ## What is shared across the two contexts These elements apply regardless of where `seal fix --os` runs. ### One Seal Project per scan, separate from `seal fix` If a host or image also runs `seal fix` for application dependencies, point each `seal fix` invocation at a **different** Seal Project. Each CLI scan reports its discovered set of packages; the next scan against the same project marks every package it does not see as stale, and stale packages drop off the Protection page. Because `seal fix` and `seal fix --os` scan disjoint sets (application packages vs OS packages), running both against one `SEAL_PROJECT` makes the second run silently bury the first run's discovery. Use two Seal Projects per host or image — for example, `my-app` for the application scan and `my-app-os` for the OS scan — both under the same tenant. The on-disk substitutions in both invocations still happen correctly; only Seal's view of the project's package coverage is affected. ### Fix modes apply the same way `seal fix --os` accepts the same fix-mode flag as `seal fix`: `remote`, `local`, or `all`. The three modes map to the same Sealing Rule sources as for Seal Apps: * **Remote** — the CLI fetches remote rules from the Seal Platform. * **Local** — the CLI reads rules from `.seal-actions.yml` in the working directory (typically the build context for image builds, or a known location on the host for live patching). * **All** — every vulnerable OS package the CLI has a sealed version for is replaced, no rules consulted. Most Seal OS deployments use this mode because the typical intent is "seal everything sealable in the OS layer." The [Sealing Rules](/using-platform/sealing-rules.md) chapter covers the rule model itself. The day-2 rhythm differs by deployment context (covered in the subpages), not by fix mode. ### The OS-package family is auto-detected The CLI reads the target's `/etc/os-release` (or the in-build equivalent) and selects the right family: `apk` for Alpine, `deb` for Debian and Ubuntu, `rpm` for Red Hat, CentOS, Rocky Linux, AlmaLinux, and Amazon Linux. Sealed packages come from the matching artifact server (`apk.sealsecurity.io`, `deb.sealsecurity.io`, `rpm.sealsecurity.io`). There is no per-family CLI configuration. The family-specific details — package metadata format, the database the CLI updates after substitution, which native commands customers use to verify on the host — appear where they matter in the subpages. ## Sealing application artifacts in the same image When an image carries both OS packages **and** already-built application artifacts (JAR files, Python wheels) that you did not build yourself — a sibling case Seal OS does not cover on its own — pair `seal fix --os` with `seal fix --fs ` in the same `Dockerfile`. The `--fs` step recursively scans a directory and seals vulnerable artifacts in place. The canonical case is a [Seal Vendor Apps](/using-platform/working-with-seal-vendor-apps.md) pipeline, where the vendor packed JARs into the image. The same technique applies anywhere artifacts exist as built bytes rather than source: re-sealing a container you built before, sealing wheels delivered by a separate team's build, and so on. See [Seal Vendor Apps](/setup-containers/seal-vendor-apps.md) for the full pattern. ## Related * [Working with the platform](/using-platform/working-with-the-platform.md): the cross-product framing of the same rhythm. * [Seal OS in CI/CD](/setup-apps-os/seal-os-cicd.md): the setup chapter for image builds. * [Seal Vendor Apps](/setup-containers/seal-vendor-apps.md): the canonical chapter for `seal fix --fs`, paired with `seal fix --os`. * [On-prem and air-gapped environments](/setup-apps-os/on-prem.md): the setup chapter for environments where hosts cannot reach Seal directly. * [Sealing Rules](/using-platform/sealing-rules.md): the rule model `seal fix --os` consults in remote and local modes.