On live hosts

Day-to-day rhythm of Seal OS when seal fix --os runs against a live Linux host — virtual machine or bare metal.

On live hosts — virtual machines, bare-metal servers, long-lived application instances — seal fix --os runs against the host's installed OS packages, replacing them in place. There is no image build; the host's package-manager database is rewritten directly, and subsequent operations see the sealed versions as the installed set.

The day-2 work here looks more like traditional patching than like a CI workflow: the trigger is a scheduled patching cycle (often the same one that already drives apt upgrade / dnf update / apk upgrade), and the unit of operation is a host or a fleet of hosts.

The recurring rhythm

The four steps from Working with the platform, specialized for live-host Seal OS:

1. Review the Vulnerable packages tab on the Protection page, filtered to the Seal Project the host's OS scan is attributed to. Each host (or fleet, if hosts share a Seal Project) contributes rows; the last seal fix --os run determines what is current.

2. Decide what to seal. Most live-host deployments run seal fix --os in all fix mode — the operational intent is "patch everything Seal can patch on this host." Teams that want per-host or per-package control use Remote or Local rules.

3. Let the next patching cycle run. Run seal fix --os on the host (typically with sudo -E seal fix --os --mode all invoked from your config-management system, cron, or whatever drives existing OS patching on the host).

4. Verify. After the run, the row state on the Protection page moves to Sealed. On the host itself, the native package manager (apk info, dpkg-query, rpm -q) reports the sealed version as installed.

The cadence is whatever your existing OS-patching cadence is. A host that gets apt upgrade weekly is well-suited to a weekly seal fix --os; a host on a monthly maintenance window picks up new sealed iterations on that window.

When new vulnerabilities are disclosed against a sealed iteration

The row mechanic is identical to Seal Apps; see Working with Seal Apps under Remote. The live-host-specific twist is the same one as for image builds, only with a different cadence: the running host stays on the iteration it was last patched to until the next seal fix --os run. If a critical OS-package vulnerability lands and your normal patching cadence is monthly, you have to run seal fix --os out of cycle to land the new iteration in production.

Common situations

A new vulnerability is disclosed in an OS package you have installed

A row appears on the Vulnerable packages tab once the next seal fix --os run discovers it. The row state matches Seal's response: Ready to seal if a sealed iteration is ready, Generate available if not, Version in progress while Seal is building it. The next patching cycle picks up whatever is ready at that time.

A package is installed by hand outside the patching cycle

apt install, dnf install, or apk add after the most recent seal fix --os run leaves the new package as the upstream version on disk. The next seal fix --os run will discover and seal it; until then, the host runs with the vulnerable version. If the newly-installed package is the trigger for the unscheduled run (an emergency dependency), run seal fix --os immediately after the install.

A host fails after patching

Same diagnostic split as Seal Apps and Seal OS in CI/CD: in the overwhelming majority of cases, the failure is not the sealed package. A simultaneous configuration change, a service that depended on a side-effect of an upstream package version, or an unrelated regression is far more likely. Check the host's logs and the patching window's change set first.

If you still suspect the sealed OS packages, the immediate operational lever is rollback through the package manager — the same way you would roll back any other patch. The package manager's history shows what changed; downgrade the affected packages to their upstream versions to confirm the hypothesis. If the host recovers, contact your Seal account team with the host's logs and the sealed package versions involved.

For high-availability deployments, the usual practice is to run seal fix --os against a small subset of hosts first (one canary in each role, for example), confirm they stay healthy through a normal workload, and then roll the cycle out to the rest of the fleet.

The host was patched but the rows did not move on the Protection page

The narrow case where seal fix --os ran successfully but the Protection page does not reflect it:

• The run was attributed to a different Seal Project — SEAL_PROJECT on the host points at an unexpected value. Project attribution comes entirely from SEAL_PROJECT.

• The CLI ran in the wrong fix mode for the configured rules. Running in local mode when the rules live in the platform, or remote when they live in .seal-actions.yml, does not fail the run; the substitution simply does not happen.

• The same Seal Project is being shared between seal fix and seal fix --os on this host. The second scan against the same project marks every package the previous scan reported and the current one did not as stale. See "One Seal Project per scan, separate from seal fix" in the chapter overview.

Related

• Seal OS in CI/CD: the setup chapter. The same CLI mechanics apply on a connected live host as in a CI/CD pipeline; only the invocation context differs.

• On-prem and air-gapped environments: the setup chapter for hosts that cannot reach Seal directly.

• In air-gapped environments: the variant for hosts without outbound Internet access.

• Working with Seal OS in CI/CD: the other Seal OS deployment shape.