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

# Updating to a new base image release

Seal publishes new sealed iterations of each base image when:

* A newly disclosed vulnerability in the underlying packages has a backportable fix, and the next iteration (`sp2`, `sp3`, and so on) includes it.
* The upstream image publishes a new build of the same tag (a new build-timestamp), and Seal seals the new build.

Either way, the published reference changes. Your `Dockerfile`s, Helm charts, and Kubernetes manifests are pinned to a specific reference, so they keep pulling the previous sealed iteration until you choose to roll forward.

This is deliberate. Builds against a stable reference are reproducible; updates are explicit moments in your delivery process where the team gets to review, test, and approve the change.

## How to learn that a new iteration shipped

Your Seal account team notifies you when a new sealed iteration of an image you depend on becomes available. For high-severity disclosures that drive a new iteration on short notice, the same channel applies. If you want to confirm the latest available iteration for an image you already use, ask your account team directly.

## The update mechanics

The update is a one-line change to the `FROM` reference. For a `Dockerfile`:

```diff
- FROM <seal-registry>/python:3.12.9-slim-bullseye-20250408T180700Z-sp2
+ FROM <seal-registry>/python:3.12.9-slim-bullseye-20250408T180700Z-sp3
```

For a Helm values file:

```diff
  image:
    repository: <seal-registry>/python
-   tag: 3.12.9-slim-bullseye-20250408T180700Z-sp2
+   tag: 3.12.9-slim-bullseye-20250408T180700Z-sp3
```

Commit, build, test, deploy. Treat the change like any other base-image bump.

## Iterating the sealed iteration only vs. moving the build-timestamp

Two distinct kinds of update:

* **Sealed-iteration bump** (`sp2` → `sp3`): same underlying upstream snapshot, more vulnerabilities sealed. Low-risk; the underlying packages are unchanged, only patched. The diff is the set of newly sealed CVEs.
* **Build-timestamp bump** (`20250408T180700Z` → `20250612T134200Z`): a different upstream snapshot of the same tag. The upstream image author published a new build; Seal sealed the new build. This is a larger change because the underlying packages may have moved (kernel headers, distro patches, third-party packages bundled with the language runtime); review accordingly.

Either way, the reference is one immutable string. There is no rolling tag for a sealed image; every reference resolves to one specific image both today and tomorrow.

## Rolling back

The previous sealed iteration is still available in the registry; rolling back is the same one-line change in the reverse direction:

```diff
- FROM <seal-registry>/python:3.12.9-slim-bullseye-20250408T180700Z-sp3
+ FROM <seal-registry>/python:3.12.9-slim-bullseye-20250408T180700Z-sp2
```

Rollbacks should be rare. Sealed iterations preserve the package layout and behavior of the upstream image; a regression specific to a sealed iteration is uncommon. If you encounter one, roll back, then contact your Seal account team with the symptoms — the same channel they would use to advise on a new iteration.

## Coordinating with mirrors

For environments that [mirror sealed images into an internal registry](/setup-containers/seal-base-images/mirroring.md), the update flow has one extra step: copy the new iteration into the internal registry before the `FROM` change lands, so the build does not stall on a missing image.

The order is:

1. `crane copy` (or equivalent) the new iteration into the internal registry.
2. Open the PR with the `FROM` update.
3. Merge once the mirror is in place and CI passes.

For continuous-mirror setups (Harbor pull-through, ECR Pull Through Cache, and so on), step 1 happens automatically on first pull; the explicit copy is only needed for one-shot mirrors.

## Coordinating with Sealing Rules

Seal Base Images sit outside the Sealing Rule model. Sealing Rules govern how the [Seal CLI](/setup-apps-os/cli-in-cicd.md) replaces vulnerable packages inside a customer-built image or codebase. A base-image update is not a Sealing Rule change; it is a base-image-reference change, owned by whoever owns the relevant `Dockerfile` or Helm chart in your team's IaC.

The corollary: a base-image-only deployment does not need Sealing Rules at all. Customers who use Seal Base Images exclusively (no `seal fix` step, no manifest-pinning) and the Sealing Rules tab is empty are operating the platform correctly.

## Related

* [Pulling a sealed base image](/setup-containers/seal-base-images/pulling.md): the reference format the update changes.
* [Mirroring to your internal registry](/setup-containers/seal-base-images/mirroring.md): the mirror-coordination step in the update flow.
* [Using Seal Base Images with Kubernetes and Helm](/setup-containers/seal-base-images/kubernetes.md): the Helm-values pattern for the bump.