Update Self-Deployed Runtime
Answer a few questions and get the steps to update your Self-Deployed Runtime apps to a new image version, tailored to your lifecycle mode, platform, and image procurement.
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. To see which version is rolling out, use either check below.
From the Atlan UI: the current published version is shown on the app's card in Connector > Marketplace, and the deployed version under Settings > Self-Deployed Runtimes. No API token needed.
From the API: poll the latest-releases endpoint.
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": "mssql",
"version": "3.1.4",
"image": "atlanhq/atlan-mssql-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": "mssql",
"version": "3.1.4",
"image": "atlanhq/atlan-mssql-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-mssql-app:<new-tag>
# Verify the keyless Cosign signature before pushing (see Verify container images)
docker tag atlanhq/atlan-mssql-app:<new-tag> \
registry.mycompany.com/atlan/atlan-mssql-app:<new-tag>
docker push registry.mycompany.com/atlan/atlan-mssql-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": "mssql",
"version": "3.1.4",
"image": "atlanhq/atlan-mssql-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-mssql-app:<new-tag>
# Verify the keyless Cosign signature before pushing (see Verify container images)
docker tag atlanhq/atlan-mssql-app:<new-tag> \
registry.mycompany.com/atlan/atlan-mssql-app:<new-tag>
docker push registry.mycompany.com/atlan/atlan-mssql-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-mssql-app": "registry.mycompany.com/atlan/atlan-mssql-app"
"atlanhq/atlan-mssql-app:3.1.4": "registry.mycompany.com/atlan/mssql: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. To see which version is rolling out, use either check below.
From the Atlan UI: the current published version is shown on the app's card in Connector > Marketplace, and the deployed version under Settings > Self-Deployed Runtimes. No API token needed.
From the API: poll the latest-releases endpoint.
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": "mssql",
"version": "3.1.4",
"image": "atlanhq/atlan-mssql-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": "mssql",
"version": "3.1.4",
"image": "atlanhq/atlan-mssql-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-mssql-app:<new-tag>
# Verify the keyless Cosign signature before pushing (see Verify container images)
docker tag atlanhq/atlan-mssql-app:<new-tag> \
registry.mycompany.com/atlan/atlan-mssql-app:<new-tag>
docker push registry.mycompany.com/atlan/atlan-mssql-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": "mssql",
"version": "3.1.4",
"image": "atlanhq/atlan-mssql-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-mssql-app:<new-tag>
# Verify the keyless Cosign signature before pushing (see Verify container images)
docker tag atlanhq/atlan-mssql-app:<new-tag> \
registry.mycompany.com/atlan/atlan-mssql-app:<new-tag>
docker push registry.mycompany.com/atlan/atlan-mssql-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-mssql-app": "registry.mycompany.com/atlan/atlan-mssql-app"
"atlanhq/atlan-mssql-app:3.1.4": "registry.mycompany.com/atlan/mssql: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 move the deployment to the new image version yourself. The steps are the same for every connector.
Update to the new version
You pull the public Atlan image directly, so there's nothing to mirror. The Atlan UI generates a ready-to-apply image override — no API token and no hand-editing of the per-app YAML. Use the manual/API method instead if you drive updates programmatically.
- From the Atlan UI
- Manually / via API
Step 1: Generate the new per-app YAML
Sign in to your Atlan tenant as an administrator, open Connector > Marketplace, select the app you deployed, and click Download config for Self-Deployed Runtime in the right-hand sidebar.
In the dialog, choose Existing deployment — an image-only update that reuses your credentials, so no new OAuth client is minted. Select Docker Compose, click Generate, and download the <app>-app.yaml. It carries the new image and version to drop into your existing Compose setup:
# DO NOT EDIT `app_name`, `app_id`, or `version_id`.
# Regenerate this file from the Atlan Marketplace UI to pick up new releases.
app_name: mssql
app_id: 019c4730-e964-7031-821a-bf9c6835a958
# Optional: If you want to use a custom image, edit `app_image`.
app_image: atlanhq/atlan-mssql-app:3.1.4
display_app_name: "MSSQL"
version_id: 019f7fb8-e0a5-70a3-8096-7c4495983346
app_version: "3.1.4"
# Optional: If you want to use a custom port, edit `app_port`.
app_port: 8000
Step 2: Drop it in and recreate the container
Replace the per-app YAML in your deployment directory with the downloaded file, then pull and recreate the container:
cd {app_name}-deployment
docker compose pull
docker compose up -d
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": "mssql",
"version": "3.1.4",
"image": "atlanhq/atlan-mssql-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 new version. 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 move the deployment to the new image version yourself. The steps are the same for every connector.
Update to the new version
Your deployment pulls from your own private registry, so re-mirror the new image, then redeploy.
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": "mssql",
"version": "3.1.4",
"image": "atlanhq/atlan-mssql-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 new version. 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 move the deployment to the new image version yourself. The steps are the same for every connector.
Update to the new version
You pull the public Atlan image directly, so there's nothing to mirror. The Atlan UI generates a ready-to-apply image override — no API token and no hand-editing of values.yaml. Use the manual/API method instead if you drive updates programmatically.
- From the Atlan UI
- Manually / via API
Step 1: Generate the image override
Sign in to your Atlan tenant as an administrator, open Connector > Marketplace, select the app you deployed, and click Download config for Self-Deployed Runtime in the right-hand sidebar.
In the dialog, choose Existing deployment — an image-only update that reuses your credentials, so no new OAuth client is minted and your existing values.yaml stays the source of truth. Select Kubernetes (Helm), click Generate, and download the <app>-image.yaml override. It pins the latest published image and includes the exact command to run:
# Generated by Atlan for the MSSQL image update.
# Apply on top of your existing values.yaml:
# helm upgrade <release-name> oci://registry-1.docker.io/atlanhq/atlan-mssql-app \
# -f values.yaml -f mssql-image.yaml
#
# Your existing values.yaml stays the source of truth for everything else
# (replicaCount, env, dapr, OAuth credentials, etc.). This file only
# moves the image pointer to the latest deployable version.
image:
repository: "atlanhq/atlan-mssql-app"
tag: "3.1.4"
Step 2: Apply the override
Run helm upgrade against your existing release, layering the override on top of your current values.yaml:
helm upgrade <release-name> oci://registry-1.docker.io/atlanhq/atlan-mssql-app \
-f values.yaml -f mssql-image.yaml
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": "mssql",
"version": "3.1.4",
"image": "atlanhq/atlan-mssql-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 new version. 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 move the deployment to the new image version yourself. The steps are the same for every connector.
Update to the new version
Your deployment pulls from your own private registry, so re-mirror the new image, then redeploy.
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": "mssql",
"version": "3.1.4",
"image": "atlanhq/atlan-mssql-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 new version. 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.