Update Self-Deployed Runtime
Answer the questions below to get the steps for moving your runtime to a new image version. The questions are the same dimensions as the install wizard—lifecycle mode, platform, and image procurement—so if you arrived here from the guided install, your choices carry over automatically and you only fill in what's missing. Your selections are stored in the URL, so you can bookmark or share the exact guide.
How is this runtime managed?
Determines whether updates are automatic or manual.
Your update steps: SDR Orchestrator (auto-managed) · Docker / Podman · Public Atlan Docker Hub
Update an orchestrator-managed runtime (Docker / Podman)
Updates are automatic
In orchestrator mode you don't run an update command. The orchestrator reconciles roughly every 60 minutes: it compares the version published for each managed app against what's deployed, and when they differ it runs the equivalent of helm upgrade --install (Kubernetes) or a blue-green redeploy (Docker/Podman) with the new image tag. The orchestrator also self-updates the same way when a new SDR version ships.
What you need to do
Nothing. You pull images directly from the public Atlan source, so the orchestrator fetches each new version itself on the next reconcile. You can optionally poll latest-releases to know when a new version is rolling out.
The latest-releases endpoint is the source of truth for which image version your tenant should be running. Authenticate with an Atlan API token and poll it for your tenant:
curl -sS \
-H "Authorization: Bearer $ATLAN_API_TOKEN" \
"https://<your-tenant>.atlan.com/api/service/marketplace/latest-releases"
Each entry lists the published version and the source image (repo:tag) for an app your tenant can run:
{
"releases": [
{
"app_name": "teradata",
"version": "3.1.4",
"image": "atlanhq/atlan-teradata-app:3.1.4"
}
]
}
Compare the returned version / image with what you're currently running. If they differ, a new version is available and the update steps below apply.
Confirm the update happened
After a reconcile, confirm the managed containers are on the new image:
docker ps --format '{{.Names}}\t{{.Image}}' | grep atlan
The image tag should match the version / image returned by latest-releases. You can also confirm in Atlan under Settings > Self-Deployed Runtimes.
See also
- App lifecycle modes: auto-update (orchestrator) vs manual update (single-app).
- Image procurement approach: public, prefix rewrite, or image map.
- Keep private registry in sync: the latest-releases poll and image-map refresh loop.
- Verify container images: confirm signatures with Cosign before mirroring.
Your update steps: SDR Orchestrator (auto-managed) · Docker / Podman · Mirrored, same names/tags
Update an orchestrator-managed runtime (Docker / Podman)
Updates are automatic
In orchestrator mode you don't run an update command. The orchestrator reconciles roughly every 60 minutes: it compares the version published for each managed app against what's deployed, and when they differ it runs the equivalent of helm upgrade --install (Kubernetes) or a blue-green redeploy (Docker/Podman) with the new image tag. The orchestrator also self-updates the same way when a new SDR version ships.
Mirror the new image before the orchestrator reconciles
Because your registry blocks the public Atlan source, the orchestrator can only pull an image you've already mirrored. If a new version is published and you haven't mirrored it, the next reconcile's pull fails. Mirror the new image before the orchestrator reconciles (≈ every 60 minutes).
Step 1: Discover the new version
The latest-releases endpoint is the source of truth for which image version your tenant should be running. Authenticate with an Atlan API token and poll it for your tenant:
curl -sS \
-H "Authorization: Bearer $ATLAN_API_TOKEN" \
"https://<your-tenant>.atlan.com/api/service/marketplace/latest-releases"
Each entry lists the published version and the source image (repo:tag) for an app your tenant can run:
{
"releases": [
{
"app_name": "teradata",
"version": "3.1.4",
"image": "atlanhq/atlan-teradata-app:3.1.4"
}
]
}
Compare the returned version / image with what you're currently running. If they differ, a new version is available and the update steps below apply.
Step 2: Mirror the new image
Pull the new image from the Atlan source, verify its signature, then re-tag and push it to your registry — the same flow you used when you first mirrored it:
docker login -u atlanhq # enter the Atlan-provided PAT
docker pull atlanhq/atlan-teradata-app:<new-tag>
# Verify the keyless Cosign signature before pushing (see Verify container images)
docker tag atlanhq/atlan-teradata-app:<new-tag> \
registry.mycompany.com/atlan/atlan-teradata-app:<new-tag>
docker push registry.mycompany.com/atlan/atlan-teradata-app:<new-tag>
Step 3: Confirm your prefix rewrite still resolves
With a prefix rewrite you keep the same repository name and tag, so no config change is needed — once the new tag exists under your prefix, the orchestrator resolves it automatically. No restart required.
Run the poll-mirror-map loop on a schedule (cron or CI) so every newly published image is mirrored and recorded before the next hourly reconcile attempts the upgrade. See Keep private registry in sync.
Confirm the update happened
After a reconcile, confirm the managed containers are on the new image:
docker ps --format '{{.Names}}\t{{.Image}}' | grep atlan
The image tag should match the version / image returned by latest-releases. You can also confirm in Atlan under Settings > Self-Deployed Runtimes.
See also
- App lifecycle modes: auto-update (orchestrator) vs manual update (single-app).
- Image procurement approach: public, prefix rewrite, or image map.
- Keep private registry in sync: the latest-releases poll and image-map refresh loop.
- Verify container images: confirm signatures with Cosign before mirroring.
Your update steps: SDR Orchestrator (auto-managed) · Docker / Podman · Rebuilt — names/tags differ
Update an orchestrator-managed runtime (Docker / Podman)
Updates are automatic
In orchestrator mode you don't run an update command. The orchestrator reconciles roughly every 60 minutes: it compares the version published for each managed app against what's deployed, and when they differ it runs the equivalent of helm upgrade --install (Kubernetes) or a blue-green redeploy (Docker/Podman) with the new image tag. The orchestrator also self-updates the same way when a new SDR version ships.
Mirror the new image before the orchestrator reconciles
Because your registry blocks the public Atlan source, the orchestrator can only pull an image you've already mirrored. If a new version is published and you haven't mirrored it, the next reconcile's pull fails. Mirror the new image before the orchestrator reconciles (≈ every 60 minutes).
Step 1: Discover the new version
The latest-releases endpoint is the source of truth for which image version your tenant should be running. Authenticate with an Atlan API token and poll it for your tenant:
curl -sS \
-H "Authorization: Bearer $ATLAN_API_TOKEN" \
"https://<your-tenant>.atlan.com/api/service/marketplace/latest-releases"
Each entry lists the published version and the source image (repo:tag) for an app your tenant can run:
{
"releases": [
{
"app_name": "teradata",
"version": "3.1.4",
"image": "atlanhq/atlan-teradata-app:3.1.4"
}
]
}
Compare the returned version / image with what you're currently running. If they differ, a new version is available and the update steps below apply.
Step 2: Mirror the new image
Pull the new image from the Atlan source, verify its signature, then re-tag and push it to your registry — the same flow you used when you first mirrored it:
docker login -u atlanhq # enter the Atlan-provided PAT
docker pull atlanhq/atlan-teradata-app:<new-tag>
# Verify the keyless Cosign signature before pushing (see Verify container images)
docker tag atlanhq/atlan-teradata-app:<new-tag> \
registry.mycompany.com/atlan/atlan-teradata-app:<new-tag>
docker push registry.mycompany.com/atlan/atlan-teradata-app:<new-tag>
Step 3: Update the image map
If your registry renamed or re-tagged the image, add or update the mapping in sdr/image-map.yaml in the object storage the SDR already uses. The orchestrator reads the map fresh on every reconcile, so no restart is needed.
images:
# bare repo covers every tag; or pin a specific rebuilt tag
"atlanhq/atlan-teradata-app": "registry.mycompany.com/atlan/atlan-teradata-app"
"atlanhq/atlan-teradata-app:3.1.4": "registry.mycompany.com/atlan/teradata:3.1.4-approved"
Run the poll-mirror-map loop on a schedule (cron or CI) so every newly published image is mirrored and recorded before the next hourly reconcile attempts the upgrade. See Keep private registry in sync.
Confirm the update happened
After a reconcile, confirm the managed containers are on the new image:
docker ps --format '{{.Names}}\t{{.Image}}' | grep atlan
The image tag should match the version / image returned by latest-releases. You can also confirm in Atlan under Settings > Self-Deployed Runtimes.
See also
- App lifecycle modes: auto-update (orchestrator) vs manual update (single-app).
- Image procurement approach: public, prefix rewrite, or image map.
- Keep private registry in sync: the latest-releases poll and image-map refresh loop.
- Verify container images: confirm signatures with Cosign before mirroring.
Your update steps: SDR Orchestrator (auto-managed) · Kubernetes · Public Atlan Docker Hub
Update an orchestrator-managed runtime (Kubernetes)
Updates are automatic
In orchestrator mode you don't run an update command. The orchestrator reconciles roughly every 60 minutes: it compares the version published for each managed app against what's deployed, and when they differ it runs the equivalent of helm upgrade --install (Kubernetes) or a blue-green redeploy (Docker/Podman) with the new image tag. The orchestrator also self-updates the same way when a new SDR version ships.
What you need to do
Nothing. You pull images directly from the public Atlan source, so the orchestrator fetches each new version itself on the next reconcile. You can optionally poll latest-releases to know when a new version is rolling out.
The latest-releases endpoint is the source of truth for which image version your tenant should be running. Authenticate with an Atlan API token and poll it for your tenant:
curl -sS \
-H "Authorization: Bearer $ATLAN_API_TOKEN" \
"https://<your-tenant>.atlan.com/api/service/marketplace/latest-releases"
Each entry lists the published version and the source image (repo:tag) for an app your tenant can run:
{
"releases": [
{
"app_name": "teradata",
"version": "3.1.4",
"image": "atlanhq/atlan-teradata-app:3.1.4"
}
]
}
Compare the returned version / image with what you're currently running. If they differ, a new version is available and the update steps below apply.
Confirm the update happened
After a reconcile, confirm the managed app rolled to the new tag:
kubectl get pods -n atlan
kubectl get deploy -n atlan -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.template.spec.containers[0].image}{"\n"}{end}'
The image tag on the running pods should match the version / image returned by latest-releases. You can also confirm in Atlan under Settings > Self-Deployed Runtimes.
See also
- App lifecycle modes: auto-update (orchestrator) vs manual update (single-app).
- Image procurement approach: public, prefix rewrite, or image map.
- Keep private registry in sync: the latest-releases poll and image-map refresh loop.
- Verify container images: confirm signatures with Cosign before mirroring.
Your update steps: SDR Orchestrator (auto-managed) · Kubernetes · Mirrored, same names/tags
Update an orchestrator-managed runtime (Kubernetes)
Updates are automatic
In orchestrator mode you don't run an update command. The orchestrator reconciles roughly every 60 minutes: it compares the version published for each managed app against what's deployed, and when they differ it runs the equivalent of helm upgrade --install (Kubernetes) or a blue-green redeploy (Docker/Podman) with the new image tag. The orchestrator also self-updates the same way when a new SDR version ships.
Mirror the new image before the orchestrator reconciles
Because your registry blocks the public Atlan source, the orchestrator can only pull an image you've already mirrored. If a new version is published and you haven't mirrored it, the next reconcile's pull fails. Mirror the new image before the orchestrator reconciles (≈ every 60 minutes).
Step 1: Discover the new version
The latest-releases endpoint is the source of truth for which image version your tenant should be running. Authenticate with an Atlan API token and poll it for your tenant:
curl -sS \
-H "Authorization: Bearer $ATLAN_API_TOKEN" \
"https://<your-tenant>.atlan.com/api/service/marketplace/latest-releases"
Each entry lists the published version and the source image (repo:tag) for an app your tenant can run:
{
"releases": [
{
"app_name": "teradata",
"version": "3.1.4",
"image": "atlanhq/atlan-teradata-app:3.1.4"
}
]
}
Compare the returned version / image with what you're currently running. If they differ, a new version is available and the update steps below apply.
Step 2: Mirror the new image
Pull the new image from the Atlan source, verify its signature, then re-tag and push it to your registry — the same flow you used when you first mirrored it:
docker login -u atlanhq # enter the Atlan-provided PAT
docker pull atlanhq/atlan-teradata-app:<new-tag>
# Verify the keyless Cosign signature before pushing (see Verify container images)
docker tag atlanhq/atlan-teradata-app:<new-tag> \
registry.mycompany.com/atlan/atlan-teradata-app:<new-tag>
docker push registry.mycompany.com/atlan/atlan-teradata-app:<new-tag>
Step 3: Confirm your prefix rewrite still resolves
With a prefix rewrite you keep the same repository name and tag, so no config change is needed — once the new tag exists under your prefix, the orchestrator resolves it automatically. No restart required.
Run the poll-mirror-map loop on a schedule (cron or CI) so every newly published image is mirrored and recorded before the next hourly reconcile attempts the upgrade. See Keep private registry in sync.
Confirm the update happened
After a reconcile, confirm the managed app rolled to the new tag:
kubectl get pods -n atlan
kubectl get deploy -n atlan -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.template.spec.containers[0].image}{"\n"}{end}'
The image tag on the running pods should match the version / image returned by latest-releases. You can also confirm in Atlan under Settings > Self-Deployed Runtimes.
See also
- App lifecycle modes: auto-update (orchestrator) vs manual update (single-app).
- Image procurement approach: public, prefix rewrite, or image map.
- Keep private registry in sync: the latest-releases poll and image-map refresh loop.
- Verify container images: confirm signatures with Cosign before mirroring.
Your update steps: SDR Orchestrator (auto-managed) · Kubernetes · Rebuilt — names/tags differ
Update an orchestrator-managed runtime (Kubernetes)
Updates are automatic
In orchestrator mode you don't run an update command. The orchestrator reconciles roughly every 60 minutes: it compares the version published for each managed app against what's deployed, and when they differ it runs the equivalent of helm upgrade --install (Kubernetes) or a blue-green redeploy (Docker/Podman) with the new image tag. The orchestrator also self-updates the same way when a new SDR version ships.
Mirror the new image before the orchestrator reconciles
Because your registry blocks the public Atlan source, the orchestrator can only pull an image you've already mirrored. If a new version is published and you haven't mirrored it, the next reconcile's pull fails. Mirror the new image before the orchestrator reconciles (≈ every 60 minutes).
Step 1: Discover the new version
The latest-releases endpoint is the source of truth for which image version your tenant should be running. Authenticate with an Atlan API token and poll it for your tenant:
curl -sS \
-H "Authorization: Bearer $ATLAN_API_TOKEN" \
"https://<your-tenant>.atlan.com/api/service/marketplace/latest-releases"
Each entry lists the published version and the source image (repo:tag) for an app your tenant can run:
{
"releases": [
{
"app_name": "teradata",
"version": "3.1.4",
"image": "atlanhq/atlan-teradata-app:3.1.4"
}
]
}
Compare the returned version / image with what you're currently running. If they differ, a new version is available and the update steps below apply.
Step 2: Mirror the new image
Pull the new image from the Atlan source, verify its signature, then re-tag and push it to your registry — the same flow you used when you first mirrored it:
docker login -u atlanhq # enter the Atlan-provided PAT
docker pull atlanhq/atlan-teradata-app:<new-tag>
# Verify the keyless Cosign signature before pushing (see Verify container images)
docker tag atlanhq/atlan-teradata-app:<new-tag> \
registry.mycompany.com/atlan/atlan-teradata-app:<new-tag>
docker push registry.mycompany.com/atlan/atlan-teradata-app:<new-tag>
Step 3: Update the image map
If your registry renamed or re-tagged the image, add or update the mapping in sdr/image-map.yaml in the object storage the SDR already uses. The orchestrator reads the map fresh on every reconcile, so no restart is needed.
images:
# bare repo covers every tag; or pin a specific rebuilt tag
"atlanhq/atlan-teradata-app": "registry.mycompany.com/atlan/atlan-teradata-app"
"atlanhq/atlan-teradata-app:3.1.4": "registry.mycompany.com/atlan/teradata:3.1.4-approved"
Run the poll-mirror-map loop on a schedule (cron or CI) so every newly published image is mirrored and recorded before the next hourly reconcile attempts the upgrade. See Keep private registry in sync.
Confirm the update happened
After a reconcile, confirm the managed app rolled to the new tag:
kubectl get pods -n atlan
kubectl get deploy -n atlan -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.template.spec.containers[0].image}{"\n"}{end}'
The image tag on the running pods should match the version / image returned by latest-releases. You can also confirm in Atlan under Settings > Self-Deployed Runtimes.
See also
- App lifecycle modes: auto-update (orchestrator) vs manual update (single-app).
- Image procurement approach: public, prefix rewrite, or image map.
- Keep private registry in sync: the latest-releases poll and image-map refresh loop.
- Verify container images: confirm signatures with Cosign before mirroring.
Your update steps: Single-app (you manage) · Docker / Podman · Public Atlan Docker Hub
Update a connector app (Docker Compose)
In single-app mode there's no auto-update. You discover the new version, mirror it if needed, then pull and redeploy yourself. The steps are the same for every connector — the image name and tag come from your downloaded config / the Atlan UI.
Step 1: Discover the new version
The latest-releases endpoint is the source of truth for which image version your tenant should be running. Authenticate with an Atlan API token and poll it for your tenant:
curl -sS \
-H "Authorization: Bearer $ATLAN_API_TOKEN" \
"https://<your-tenant>.atlan.com/api/service/marketplace/latest-releases"
Each entry lists the published version and the source image (repo:tag) for an app your tenant can run:
{
"releases": [
{
"app_name": "teradata",
"version": "3.1.4",
"image": "atlanhq/atlan-teradata-app:3.1.4"
}
]
}
Compare the returned version / image with what you're currently running. If they differ, a new version is available and the update steps below apply.
Step 2: Pull and redeploy
Point your per-app YAML at the new image reference, then pull and recreate the container:
cd {app_name}-deployment
docker compose pull
docker compose up -d
Verify the update
docker compose ps
docker inspect <package> --format '{{.Config.Image}}'
The running image tag should match the version returned by latest-releases. In Atlan, go to Workflows > Agent and confirm the entry is still Active.
See also
- App lifecycle modes: auto-update (orchestrator) vs manual update (single-app).
- Image procurement approach: public, prefix rewrite, or image map.
- Keep private registry in sync: the latest-releases poll and image-map refresh loop.
- Verify container images: confirm signatures with Cosign before mirroring.
Your update steps: Single-app (you manage) · Docker / Podman · Mirrored to your registry
Update a connector app (Docker Compose)
In single-app mode there's no auto-update. You discover the new version, mirror it if needed, then pull and redeploy yourself. The steps are the same for every connector — the image name and tag come from your downloaded config / the Atlan UI.
Step 1: Discover the new version
The latest-releases endpoint is the source of truth for which image version your tenant should be running. Authenticate with an Atlan API token and poll it for your tenant:
curl -sS \
-H "Authorization: Bearer $ATLAN_API_TOKEN" \
"https://<your-tenant>.atlan.com/api/service/marketplace/latest-releases"
Each entry lists the published version and the source image (repo:tag) for an app your tenant can run:
{
"releases": [
{
"app_name": "teradata",
"version": "3.1.4",
"image": "atlanhq/atlan-teradata-app:3.1.4"
}
]
}
Compare the returned version / image with what you're currently running. If they differ, a new version is available and the update steps below apply.
Step 2: Re-mirror the new image
Your deployment pulls from your own registry, so replicate the new image before you redeploy.
Pull the new image from the Atlan source, verify its signature, then re-tag and push it to your registry — the same flow you used when you first mirrored it:
docker login -u atlanhq # enter the Atlan-provided PAT
docker pull atlanhq/<image-name>:<new-tag>
# Verify the keyless Cosign signature before pushing (see Verify container images)
docker tag atlanhq/<image-name>:<new-tag> \
registry.mycompany.com/atlan/<image-name>:<new-tag>
docker push registry.mycompany.com/atlan/<image-name>:<new-tag>
Step 3: Pull and redeploy
Point your per-app YAML at the new image reference, then pull and recreate the container:
app_image: "registry.mycompany.com/atlan/<image-name>:<new-tag>"
cd {app_name}-deployment
docker compose pull
docker compose up -d
Verify the update
docker compose ps
docker inspect <package> --format '{{.Config.Image}}'
The running image tag should match the version returned by latest-releases. In Atlan, go to Workflows > Agent and confirm the entry is still Active.
See also
- App lifecycle modes: auto-update (orchestrator) vs manual update (single-app).
- Image procurement approach: public, prefix rewrite, or image map.
- Keep private registry in sync: the latest-releases poll and image-map refresh loop.
- Verify container images: confirm signatures with Cosign before mirroring.
Your update steps: Single-app (you manage) · Kubernetes · Public Atlan Docker Hub
Update a connector app (Kubernetes)
In single-app mode there's no auto-update. You discover the new version, mirror it if needed, then pull and redeploy yourself. The steps are the same for every connector — the image name and tag come from your downloaded config / the Atlan UI.
Step 1: Discover the new version
The latest-releases endpoint is the source of truth for which image version your tenant should be running. Authenticate with an Atlan API token and poll it for your tenant:
curl -sS \
-H "Authorization: Bearer $ATLAN_API_TOKEN" \
"https://<your-tenant>.atlan.com/api/service/marketplace/latest-releases"
Each entry lists the published version and the source image (repo:tag) for an app your tenant can run:
{
"releases": [
{
"app_name": "teradata",
"version": "3.1.4",
"image": "atlanhq/atlan-teradata-app:3.1.4"
}
]
}
Compare the returned version / image with what you're currently running. If they differ, a new version is available and the update steps below apply.
Step 2: Pull and redeploy
Set the new tag in values.yaml (use your mirrored reference if you mirror), then run helm upgrade against the existing release:
image:
repository: "atlanhq/<image-name>"
tag: "<new-tag>"
helm upgrade <chart>-release ./<chart> -n <namespace> -f values.yaml
Verify the update
kubectl get pods -n <namespace>
kubectl get pod -n <namespace> -l app.kubernetes.io/name=<chart> \
-o jsonpath='{.items[0].spec.containers[0].image}'
The running image tag should match the version returned by latest-releases. In Atlan, go to Workflows > Agent and confirm the entry is still Active.
See also
- App lifecycle modes: auto-update (orchestrator) vs manual update (single-app).
- Image procurement approach: public, prefix rewrite, or image map.
- Keep private registry in sync: the latest-releases poll and image-map refresh loop.
- Verify container images: confirm signatures with Cosign before mirroring.
Your update steps: Single-app (you manage) · Kubernetes · Mirrored to your registry
Update a connector app (Kubernetes)
In single-app mode there's no auto-update. You discover the new version, mirror it if needed, then pull and redeploy yourself. The steps are the same for every connector — the image name and tag come from your downloaded config / the Atlan UI.
Step 1: Discover the new version
The latest-releases endpoint is the source of truth for which image version your tenant should be running. Authenticate with an Atlan API token and poll it for your tenant:
curl -sS \
-H "Authorization: Bearer $ATLAN_API_TOKEN" \
"https://<your-tenant>.atlan.com/api/service/marketplace/latest-releases"
Each entry lists the published version and the source image (repo:tag) for an app your tenant can run:
{
"releases": [
{
"app_name": "teradata",
"version": "3.1.4",
"image": "atlanhq/atlan-teradata-app:3.1.4"
}
]
}
Compare the returned version / image with what you're currently running. If they differ, a new version is available and the update steps below apply.
Step 2: Re-mirror the new image
Your deployment pulls from your own registry, so replicate the new image before you redeploy.
Pull the new image from the Atlan source, verify its signature, then re-tag and push it to your registry — the same flow you used when you first mirrored it:
docker login -u atlanhq # enter the Atlan-provided PAT
docker pull atlanhq/<image-name>:<new-tag>
# Verify the keyless Cosign signature before pushing (see Verify container images)
docker tag atlanhq/<image-name>:<new-tag> \
registry.mycompany.com/atlan/<image-name>:<new-tag>
docker push registry.mycompany.com/atlan/<image-name>:<new-tag>
Step 3: Pull and redeploy
Set the new tag in values.yaml (use your mirrored reference if you mirror), then run helm upgrade against the existing release:
image:
repository: "registry.mycompany.com/atlan/<image-name>"
tag: "<new-tag>"
helm upgrade <chart>-release ./<chart> -n <namespace> -f values.yaml
Verify the update
kubectl get pods -n <namespace>
kubectl get pod -n <namespace> -l app.kubernetes.io/name=<chart> \
-o jsonpath='{.items[0].spec.containers[0].image}'
The running image tag should match the version returned by latest-releases. In Atlan, go to Workflows > Agent and confirm the entry is still Active.
See also
- App lifecycle modes: auto-update (orchestrator) vs manual update (single-app).
- Image procurement approach: public, prefix rewrite, or image map.
- Keep private registry in sync: the latest-releases poll and image-map refresh loop.
- Verify container images: confirm signatures with Cosign before mirroring.