> 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-base-images.md).

# Seal Base Images

A Seal base image is a sealed version of a public container base image. You pull it instead of pulling the upstream image directly, and your application is built on top of it. The vulnerabilities in the underlying packages (the OS layer and any language runtime the upstream image bundles) are already remediated when the pull completes; no `seal fix --os` step is required inside your `Dockerfile`, no rebuild against a new distribution. Your build is unchanged except for the base-image reference.

## Which images are available

Whether a specific upstream image has a sealed counterpart depends on whether Seal has built one. The set of sealed images Seal maintains is driven by customer demand. Ask your Seal account team for the sealed image you need; if it isn't available, they coordinate adding it.

## Seal Base Images and Wolfi

Customers often weigh Seal Base Images against [Wolfi](https://wolfi.dev/), Chainguard's minimal Linux distribution that aims to produce inherently vulnerability-free base images. The two approaches answer the same problem from opposite ends:

* **Wolfi** asks you to rebuild your stack on top of a different distribution: a minimal package set, curated to exclude vulnerable upstream versions. Adopting it means switching base images and accepting whatever consequences fall out of the package-set difference (build-time toolchain, runtime library paths, dependency availability).
* **Seal Base Images** keep your stack on its existing upstream base (Python on Debian slim, OpenJDK on Alpine, Ubuntu LTS, and so on). Seal seals the existing image rather than asking you to switch to a different one. Your build, your dependency set, your operational tooling all stay the same; only the vulnerabilities go away.

The two are not mutually exclusive; some customers use Wolfi for new green-field services and Seal Base Images for everything that has an existing operational footprint. But on an existing service, Seal Base Images are usually the lower-friction path: drop-in replacement at the registry-pull layer, no source-tree changes.

## How a Seal base image is delivered

Each sealed image is published as a regular container image to Seal's hosted image registry. The image is signed (cosign) and ships with a Software Bill of Materials and a VEX attestation listing the vulnerabilities sealed.

Your `Dockerfile` changes one line: the `FROM` reference. The rest of the build is untouched. After the pull, the image behaves exactly like the upstream version it sealed — same paths, same package metadata, same entrypoint — only with the vulnerabilities backported out.

## Chapter contents

This chapter is the canonical setup home for the Seal Base Images deployment.

* [Authenticating with Seal's image registry](/setup-containers/seal-base-images/authenticating.md): the credentials your image-pull layer needs.
* [Pulling a sealed base image](/setup-containers/seal-base-images/pulling.md): the canonical `FROM` reference and `docker pull` patterns.
* [Mirroring to your internal registry](/setup-containers/seal-base-images/mirroring.md): when policy or air-gap requires the image to come from your own registry rather than Seal's hosted one.
* [Using Seal Base Images with Kubernetes and Helm](/setup-containers/seal-base-images/kubernetes.md): `imagePullSecret`, deployment manifests, Helm value overrides.
* [Updating to a new base image release](/setup-containers/seal-base-images/updating.md): how to roll forward when Seal publishes a newer sealed iteration of the same upstream image.

## Before you start

* A [token](/getting-started/tokens.md) for your tenant. The same token used elsewhere in Seal authenticates your image pulls.
* Network access from your image-pull layer (CI, Kubernetes nodes, developer workstations) to Seal's hosted image registry. The hostname is documented under [Authenticating with Seal's image registry](/setup-containers/seal-base-images/authenticating.md).
* For container builds: a `Dockerfile` you control, with a `FROM` line that you are willing to repoint.

## How this differs from the rest of the platform

Seal Base Images is the only deployment method that does **not** involve the Seal CLI or a configured artifact server. Your container runtime (Docker, Podman, containerd, a Kubernetes node's image puller, your CI's build agent) is the only thing that touches Seal at runtime. No `seal fix` step, no manifest-pinning maintenance.

This is also the deployment method with the highest leverage when the upstream image is what the customer's team is uncomfortable shipping. A single repointed `FROM` clears the OS-layer findings for every container built on that base.

## Related

* [Seal Base Images](/introduction/product-family/seal-base-images.md): the product-family page that frames where this fits among the five Seal products.
* Working with Seal Base Images: the day-2 operating rhythm once the setup is in place. (Documented under "Using the Seal Platform.")
* Seal My Container: the sister product for sealing your own private container images, when the image you want sealed is one you built rather than a public upstream. (Documented in the next chapter.)