> 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-my-container.md). # Working with Seal My Container Seal My Container seals the OS layer of your own private container images by running `seal image fix` against the built image. The day-2 work centers on one pattern: a centralized re-seal pipeline that triggers on registry-push events, pulls the newly pushed image, runs `seal image fix`, and pushes the sealed result back. Once that pipeline is in place, the originating teams do not change their workflow; the sealed image arrives at the registry on every push. This chapter covers the recurring rhythm — what to watch, what to do when things change, what the failure modes are. The setup mechanics (registry credentials, webhook configuration, the `seal image fix` flag reference) live under [Seal My Container](/setup-containers/seal-my-container.md). ## The recurring rhythm The four steps from [Working with the platform](/using-platform/working-with-the-platform.md), specialized for Seal My Container: 1. **Review** the Vulnerable packages tab on the [Protection page](/discovering/protection-page.md), filtered to the Seal Project the re-seal pipeline reports to. Rows arrive as the pipeline runs, one set per image that passed through it. 2. **Decide what to seal.** `seal image fix` replaces every vulnerable OS package Seal has a sealed version for. There is no per-rule control on this command; the seal step inside the generated Dockerfile always runs in all mode. The decision is binary, per-image: does the image flow through the re-seal pipeline or not. 3. **Let the pipeline run.** When a team pushes an image to the registry, the webhook fires the re-seal job, which pulls the image, seals it, and pushes the sealed result back to the same tag (or a parallel tag, depending on your configuration). No customer action is needed per push. 4. **Verify.** The Protection page reflects the seal step's outcome — rows move to **Sealed** as the pipeline reports its run.
The Protection page on the Vulnerable packages tab

The Protection page reflects each re-seal pass.

The cadence of the rhythm is the cadence of the originating teams' pushes. Teams that release weekly see weekly seal passes; teams that release on every merge see one per merge. ## Two trigger patterns The setup chapter covers both in detail; the day-2 implications differ. * **Per-push**: every newly-pushed tag is sealed within minutes. The smallest seal latency on new builds; the trade-off is that long-lived production images that have not been re-pushed keep shipping with whatever sealed iterations were current at the last push. * **Scheduled (e.g. nightly re-seal of every production-ready tag)**: long-lived images get the newest sealed iterations without a push trigger; fresh pushes wait until the next scheduled run. Use this when image-release cadence is slower than Seal's iteration cadence. Some teams run both: per-push for new tags, plus a periodic sweep for the long-lived ones. The two pipelines share the same `seal image fix` invocation; only the trigger differs. ## Handling upstream container updates When a team rebuilds their image — a base-image bump, a `RUN apk add` change, a switched-out language runtime, or just a routine rebuild against the current upstream — the push to the registry triggers the re-seal pipeline as usual. The newly-built image's OS layer becomes the input to `seal image fix`; whatever vulnerabilities the new upstream layer introduces are sealed in the same pass, and whatever vulnerabilities the previous build's layer had go away (because the layer itself was replaced upstream). The centralized pipeline is **idempotent across rebuilds**: each push is a fresh pass over whatever the team produced this time. There is no carry-over from previous re-seal runs of the same tag, no stale state to clean up. ## When Seal publishes a newer iteration New sealed iterations affect long-lived images, not the ones being actively rebuilt: * Images that are rebuilt and re-sealed regularly always get the safest sealed iteration that exists at the moment of the seal pass. The cycle handles itself. * Long-lived images that haven't been re-pushed since `sp2` shipped are still running with `sp1` (or older). Two ways to bring them current: * A **scheduled re-seal sweep** picks them up automatically, on whatever cadence the schedule runs. * A **manual re-seal** of the affected tags: invoke the centralized pipeline against the tags directly, outside the normal webhook trigger. For a high-severity disclosure that needs the newest sealed iteration into production faster than your normal release cycle, the manual re-seal is the path. The newly-sealed image lands on the same tag, and the next pull (or rolling restart) of every deployment picks it up. ## Common situations ### A team pushes a new image version The pipeline picks it up via the webhook, seals it, pushes it back. The Protection page reflects the pass on the next refresh. From the team's perspective, nothing visible changed: they pushed, the registry shows the same tag (with sealed contents). ### A team bumps their base image Same path. The new base layer's OS packages are now part of what discovery sees; the seal pass covers them. New vulnerable packages from the bumped base appear as new rows on the Vulnerable packages tab; the seal pass substitutes whatever sealed iterations are available, and the rows go to **Sealed**. ### Seal publishes a new iteration affecting a package in your images For images that get re-pushed regularly, no action is needed. For long-lived images, run the manual or scheduled re-seal described above. ### The pipeline fails on a specific image The image-build wrapper Docker BuildKit runs inside the re-seal job logs the failure; treat the diagnosis the same as any other Docker-build failure. Common categories: * The source image's distribution is one Seal does not support. The seal step fails before it does anything. Confirm the image's base is on the supported list in the [setup chapter](/setup-containers/seal-my-container.md#what-it-covers). * The pipeline's host lost authentication to the registry or to Seal. Check the host's environment and credentials. * The image is too large for the host running the seal pass (disk, memory). Provision a larger host for the re-seal pipeline, or split very large images out into a per-team build that uses [Seal OS in CI/CD](/setup-apps-os/seal-os-cicd.md) directly. ### A deployment fails after a sealed image lands In the overwhelming majority of cases, a deployment failure that follows shortly after a seal pass has nothing to do with the substitution. Some other change in the same release cycle is more likely the cause. Check your deployment logs and your commit history first. If you still suspect the sealed OS packages are the cause, the immediate operational lever is to redeploy the previous tag (if the re-seal pipeline uses a parallel `-sealed` tag) or pull from your registry's tag history (if the pipeline overwrote in place — most registries retain prior digests). Once you confirm the sealed image is the cause, contact your Seal account team with the affected tag and the deployment logs. For high-availability deployments, the usual practice is to canary the sealed image (one replica, one cluster, one region) before rolling it out broadly. The pipeline can be configured to seal to a parallel tag during canary and to the production tag only after sign-off. ### The pipeline ran but the row didn't move on the Protection page The narrow case where `seal image fix` completed successfully but the Protection page does not reflect it is almost always project attribution: `SEAL_PROJECT` on the host points at a different Seal Project than the one you are watching. Project attribution comes entirely from `SEAL_PROJECT`; if the pipeline's value is a different project (or a typo the platform treats as a new project), the rows you expect to move are not the ones the run is touching. ## What this deployment looks like to the rest of Seal The CLI does run and does report back, so the Protection page sees what Seal My Container has sealed — the same way it sees what `seal fix --os` or `seal fix` sees. Email notifications about newly available sealed versions work normally for the Seal Project the pipeline reports to. `seal image fix` does not consult Sealing Rules. The seal step inside the generated Dockerfile always runs in all mode (the equivalent of "seal everything sealable"), regardless of what rules are configured for the Seal Project. The Sealing rules tab being empty or non-empty has no bearing on what this command does. The Seal Project the pipeline reports to is logically one per image (or one per logical grouping of images). Multiple unrelated images sharing one `SEAL_PROJECT` will see each other's scans clobber theirs, the same way that running `seal fix` and `seal fix --os` against the same project does; see the [setup chapter's note on this](/setup-containers/seal-my-container.md#before-you-start) for the recommended naming convention. ## Related * [Seal My Container](/setup-containers/seal-my-container.md): the setup chapter. * [Implementing the centralized re-seal pipeline](/setup-containers/seal-my-container/centralized-pipeline.md): the per-registry trigger patterns the rhythm builds on. * [The `seal image fix` command and flags](/setup-containers/seal-my-container/seal-image-fix-reference.md): the command the pipeline invokes. * [Working with Seal Vendor Apps](/using-platform/working-with-seal-vendor-apps.md): the sister product for images you did not build yourself.