> 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/pulling.md).

# Pulling a sealed base image

Once your image-pull layer is [authenticated against Seal's registry](/setup-containers/seal-base-images/authenticating.md), pulling a sealed base image is identical to pulling any other OCI image: a `docker pull`, a `podman pull`, or a `FROM` reference in your `Dockerfile`. This page covers the reference format and the canonical patterns.

## The reference format

Every sealed image is identified by three parts, plus the registry hostname:

```
<seal-registry>/<image>:<upstream-version>-<build-timestamp>-sp<N>
```

* **`<image>`** is the upstream image's name (`python`, `node`, `openjdk`, `elasticsearch`, and so on).
* **`<upstream-version>`** is the upstream tag this sealed iteration was built from (`3.12.9-slim-bullseye`, `21-jdk-alpine`, `8.13.4`, and so on).
* **`<build-timestamp>`** is the moment the upstream tag was pulled by Seal, in compact ISO 8601: `YYYYMMDDTHHMMSSZ` (for example, `20250408T180700Z`). This pins the sealed image to a specific point-in-time of the upstream tag.
* **`sp<N>`** is the sealed iteration: `sp1` is the first sealed iteration of that build-timestamped upstream snapshot, `sp2` is the next, and so on. Each `spN` is cumulative — every fix from earlier iterations plus the new ones.

A concrete example, for a sealed Python 3.12 slim Bullseye image:

```
<seal-registry>/python:3.12.9-slim-bullseye-20250408T180700Z-sp2
```

This is the second sealed iteration of the upstream `python:3.12.9-slim-bullseye` image as pulled by Seal on `2025-04-08 18:07:00 UTC`.

Your Seal account team provides the exact reference for each sealed image enabled for your tenant. Use that reference verbatim; do not construct it from parts.

## Using a sealed image in a `Dockerfile`

Change the `FROM` line. Nothing else changes:

```dockerfile
# Before
# FROM python:3.12.9-slim-bullseye

# After
FROM <seal-registry>/python:3.12.9-slim-bullseye-20250408T180700Z-sp2

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "main.py"]
```

The rest of the `Dockerfile` is unchanged. The sealed base image preserves the file layout, default user, entrypoint, and shell of the upstream image; anything that worked against the upstream still works against the sealed counterpart.

## Pulling directly

For inspection, smoke testing, or pre-fetching for an offline build, pull the image directly with `docker` or `podman`:

```bash
docker pull <seal-registry>/python:3.12.9-slim-bullseye-20250408T180700Z-sp2
```

Once cached locally, the image is available for `docker run`, `docker inspect`, or any other docker subcommand. The output of `docker inspect` shows the same configuration the upstream image would, plus the labels Seal adds during sealing.

## Pinning strategy

Because the reference includes both the build-timestamp and the sealed iteration, every `FROM` line you check in points at one specific image. There is no rolling `latest` tag for a Seal Base Image: a tag like `python:3.12.9-slim-bullseye-20250408T180700Z-sp2` resolves to exactly one image, today and tomorrow.

To pick up a newer sealed iteration when one ships (`sp3`, `sp4`, and so on), update the `FROM` line. The mechanics are documented in [Updating to a new base image release](/setup-containers/seal-base-images/updating.md).

This is intentional. Container builds that depend on `:latest` are notoriously hard to reproduce; Seal Base Image references give you a sealed equivalent without giving up the reproducibility of a pinned tag.

## Multi-arch images

Each sealed image is published as a manifest list spanning the architectures the upstream image supports (typically `linux/amd64` and `linux/arm64`). A regular `docker pull` resolves to the right architecture for the host automatically; specify `--platform=linux/arm64` (or `--platform=linux/amd64`) if you need to pull an architecture other than the host's, the same way you would for any upstream multi-arch image.

If the upstream image is single-architecture, the Seal counterpart is also single-architecture. Your Seal account team confirms which architectures are available for each sealed image.

## Verifying signatures

Every sealed image is signed with `cosign` against a Seal-owned key. The trust setup and the verification commands are documented under [Cryptographic signing and hash verification](/trust/signing.md); the short version is:

```bash
cosign verify --key <seal-cosign-public-key> \
  <seal-registry>/python:3.12.9-slim-bullseye-20250408T180700Z-sp2
```

A successful verify confirms the image was published by Seal and has not been tampered with in transit. For policy-driven environments (Kyverno, Sigstore Policy Controller, Gatekeeper), use the same key to enforce signature requirements at pod-launch time.

## Attestations

Each sealed image ships with a VEX attestation listing the vulnerabilities that have been remediated and an SBOM listing the packages inside. Both are attached to the image as cosign attestations and can be downloaded from the registry alongside the image. The full attestation model is documented under [Attestations](/trust/attestations.md).

## Related

* [Authenticating with Seal's image registry](/setup-containers/seal-base-images/authenticating.md): credentials and registry-login mechanics.
* [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.
* [Updating to a new base image release](/setup-containers/seal-base-images/updating.md): rolling forward to a newer sealed iteration.