Update Self-Deployed Runtime

||Connect docs via MCP

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.

SDR Orchestrator (auto-managed)The orchestrator reconciles and updates apps for you.

Single-app (you manage)You update each connector deployment yourself.

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

Stay ahead of the reconcile

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.

Automate it

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

Stay ahead of the reconcile

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.

sdr/image-map.yaml

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"

Automate it

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

Stay ahead of the reconcile

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.

Automate it

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

Stay ahead of the reconcile

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.

sdr/image-map.yaml

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"

Automate it

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)

You own the update

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

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:

mssql-app.yaml (example)

# 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

Manually / via API

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)

You own the update

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:

<package>.yaml

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)

You own the update

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

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:

mssql-image.yaml (example)

# 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

Manually / via API

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:

values.yaml

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)

You own the update

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:

values.yaml

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.