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 <image> --platform <platform> [--tag <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
<image>	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>	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. 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.

What runs under the hood

seal image fix is a thin wrapper around three docker invocations:

1. docker pull --platform <platform> <image> — fetches the source image into the local Docker daemon.

2. docker build --secret id=SEAL_TOKEN,env=SEAL_TOKEN -t <tag> -f <generated-dockerfile> . — 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 <tag> — pushes the sealed image to the destination registry.

The generated Dockerfile is FROM <image> 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.

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 <path> against the relevant directory in a custom Dockerfile. See Seal Vendor Apps for the pattern.

Example

The canonical invocation, which seals the image in place and pushes back to the same tag:

export SEAL_TOKEN=<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:

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:

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. 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: the registry credentials the underlying docker pull and docker push use.

• Implementing the centralized re-seal pipeline: the canonical production setup that calls this command.

• Common issues: the failures that come up most often.

• Seal OS in CI/CD: the parallel chapter that runs the same seal step inside a Dockerfile you write yourself.