> 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

Roll forward when Seal publishes a newer sealed version of the upstream image you depend on.

Seal publishes new sealed versions of each base image when:

* A newly disclosed vulnerability in the underlying packages has a backportable fix, and the next sealed version (`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 version 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 sealed version shipped

Your Seal account team notifies you when a new sealed version of an image you depend on becomes available. For high-severity disclosures that drive a new sealed version on short notice, the same channel applies. If you want to confirm the latest available sealed version 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 version only vs. moving the build-timestamp

Two distinct kinds of update:

* **Sealed-version 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 version 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 versions preserve the package layout and behavior of the upstream image; a regression specific to a sealed version 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 sealed version.

## 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 sealed version 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 sealed version 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.