> 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-containers/seal-my-container/seal-image-fix-reference.md). # The seal image fix command and flags Flags, arguments, and environment variables of the \`seal image fix\` command. `seal image fix` is the Seal CLI subcommand that seals the OS layer of a pre-built container image. The image is pulled from a registry, rebuilt with the seal step inside a generated `Dockerfile`, and pushed back. The pull and push use the host's Docker credentials; the seal step uses the Seal token passed in as a BuildKit secret. ## Synopsis ``` seal image fix --platform [--tag ] [persistent flags] ``` The image is a **positional argument**, not a `--image` flag. The image reference is whatever form your Docker daemon understands (`registry/repo:tag`, `registry/repo@sha256:...`, or a short form against the default registry). ## Required arguments | Position | Meaning | | --------- | ------------------------------------------------------------------------------------------------------- | | `` | The fully-qualified reference of the image to seal. Must be pullable from the host running the command. | ## Flags `seal image fix` has two flags of its own; everything else comes from the persistent flag set shared with the rest of the CLI. | Flag | Required | Default | Meaning | | ------------ | -------- | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--platform` | yes | — | The Docker platform to pull and build for, in the same syntax as `docker --platform` (`linux/amd64`, `linux/arm64`, and so on). Required even when the image is single-architecture; the CLI passes the value through to `docker pull` and `docker build`. | | `--tag` | no | the source image's reference | The fully-qualified reference to push the sealed result to. If omitted, the sealed image is pushed back to the exact same reference it was pulled from, overwriting the source tag in place. **This is the canonical pattern**: every deployment that already pulls the original reference picks up the sealed version on its next pull, with no manifest, no `Dockerfile`, and no Helm-values changes. Pass `--tag` only when you specifically want the sealed result to land at a different reference (a parallel tag, a different repository, or a separate registry). | Persistent flags relevant to `seal image fix`: | Flag | Meaning in the `image fix` context | | ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `-v` / `-vv` / `-vvvv` | Verbosity. The output of the underlying `seal fix --os` step inside the build appears in the build log; higher verbosity prints more detail when diagnosing a problem. | | `--config ` | Path to a Seal CLI config file (`.seal-config.yml`). The same configuration model as the rest of the CLI applies. | | `--clean` and `--remove-cli` | Passed through to the inner `seal fix --os` step. The CLI sets `--remove-cli` automatically inside the generated `Dockerfile` so the binary does not ship in the resulting image. | ## Environment variables | Variable | Required | Purpose | | ----------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `SEAL_TOKEN` | Yes | The Seal token, passed into the build via BuildKit's `--secret id=SEAL_TOKEN,env=SEAL_TOKEN`. It is not baked into the resulting image. | | `SEAL_PROJECT` | Yes | The Seal Project ID to attribute the seal to. The first run with a `SEAL_PROJECT` value that does not exist creates the project automatically. | | `SEAL_USE_SEALED_NAMES` | No | Set to `1` to rename sealed packages inside the image so external scanners do not flag them. See [Renaming packages inside containers](/setup-containers/seal-my-container/renaming.md). Defaults to off. | The same `SEAL_PROJECT` caveat that applies to `seal fix --os` applies here: if the same image build also runs `seal fix` for application dependencies separately, **use a different `SEAL_PROJECT`** for the two so the second scan does not bury the first's discovery on the Protection page. The mechanism is documented in [Seal OS in CI/CD](/setup-apps-os/seal-os-cicd.md#use-a-separate-seal-project-for-seal-fix---os). ## What runs under the hood `seal image fix` is a thin wrapper around three `docker` invocations: 1. `docker pull --platform `: fetches the source image into the local Docker daemon. 2. `docker build --secret id=SEAL_TOKEN,env=SEAL_TOKEN -t -f .`: runs a build whose `Dockerfile` is generated by the CLI. BuildKit must be enabled (it is by default in current Docker versions). 3. `docker push `: pushes the sealed image to the destination registry. The generated `Dockerfile` is `FROM ` followed by two `RUN` steps: 1. `seal fix --os --mode=all --clean`: seals the OS-package layer. Same logic as the standalone command documented in [Seal OS in CI/CD](/setup-apps-os/seal-os-cicd.md). 2. `seal fix --fs java / --mode=all --clean`: recursively scans the image's filesystem from `/` for JAR files and seals any whose contents match a vulnerable library Seal recognizes. This is the post-build application-layer step; it covers JARs the image already shipped with, including JARs you did not build yourself. The generated `Dockerfile` is written to a temporary working directory and removed after the build. It is not customer-editable. To seal Python wheels in addition to OS packages and JARs, run `seal fix --fs python ` against the relevant directory in a custom `Dockerfile`. See [Seal Vendor Apps](/setup-containers/seal-vendor-apps.md) for the pattern. ## Example The canonical invocation, which seals the image in place and pushes back to the same tag: ```bash export SEAL_TOKEN= export SEAL_PROJECT=my-app-image seal image fix \ my-registry.example.com/my-app:1.0.0 \ --platform linux/amd64 ``` After this completes, `my-registry.example.com/my-app:1.0.0` in the registry is the sealed version; the unsealed bits are gone. Every consumer that pulls the tag on its next run gets the sealed image without any change to its `Dockerfile`, Helm values, or deployment manifest. To land the sealed result at a different tag (for example, to keep the unsealed version around for rollback or comparison), add `--tag`: ```bash seal image fix \ my-registry.example.com/my-app:1.0.0 \ --platform linux/amd64 \ --tag my-registry.example.com/my-app:1.0.0-sealed ``` This pushes the sealed image to `my-app:1.0.0-sealed` and leaves `my-app:1.0.0` untouched. Use this form when downstream pull policy is explicit about which tag to pick up. ## Multi-architecture images `seal image fix` operates on a single platform per invocation, set by `--platform`. For a multi-arch image, run the command once per architecture and assemble the manifest list afterwards with `docker buildx imagetools create` or the equivalent: ```bash seal image fix my-registry.example.com/my-app:1.0.0 --platform linux/amd64 --tag my-registry.example.com/my-app:1.0.0-sealed-amd64 seal image fix my-registry.example.com/my-app:1.0.0 --platform linux/arm64 --tag my-registry.example.com/my-app:1.0.0-sealed-arm64 docker buildx imagetools create \ -t my-registry.example.com/my-app:1.0.0-sealed \ my-registry.example.com/my-app:1.0.0-sealed-amd64 \ my-registry.example.com/my-app:1.0.0-sealed-arm64 ``` Wrap this in a small script when you need it; the CLI does not provide a single-shot multi-arch convenience flag. ## Exit behavior The command exits with status `0` when it has successfully pushed the sealed image. A non-zero exit means one of the underlying steps failed; common causes are documented in [Common issues](/setup-containers/seal-my-container/common-issues.md). The CLI's stderr names the specific failure: usually a Docker error (pull denied, push denied, build failed) or a Seal error (token rejected, image's distribution unsupported). ## Related * [Authenticating with your container registry](/setup-containers/seal-my-container/authenticating-registry.md): the registry credentials the underlying `docker pull` and `docker push` use. * [Implementing the centralized re-seal pipeline](/setup-containers/seal-my-container/centralized-pipeline.md): the canonical production setup that calls this command. * [Common issues](/setup-containers/seal-my-container/common-issues.md): the failures that come up most often. * [Seal OS in CI/CD](/setup-apps-os/seal-os-cicd.md): the parallel chapter that runs the same seal step inside a `Dockerfile` you write yourself.