Install Self-Deployed Runtime
Answer the questions below. Only the choices relevant to your path appear, and a tailored install guide assembles once you've made your selections. Your selections are stored in the URL, so you can bookmark or share the exact guide.
How do you want to manage app lifecycle?
This decides who owns installs, upgrades, and uninstall for the apps you require. Learn more about this choice ↗
Your install guide: SDR Orchestrator (auto-managed) · Docker / Podman · Public Atlan Docker Hub
Install SDR Orchestrator on Docker / Podman
System requirements
- SDR Orchestrator: 0.5 vCPU, 256 MB RAM, ~500 MB disk.
- Per app: 0.5–1 vCPU, 512 MB–1 GB RAM, ~1–2 GB disk.
- Size the VM by adding orchestrator + per-app needs (e.g. orchestrator + 3 apps ≈ 2 vCPUs, 4 GB RAM, 20 GB disk).
Prerequisites
- Linux host (x86_64 or arm64) — Windows/macOS not supported.
- Docker Engine 20.10+ with Compose, or Podman 4.0+ with podman-compose.
- A Docker Hub PAT from Atlan (to pull private app images).
- Object storage and a secret store.
- Outbound HTTPS + gRPC to Atlan, Docker Hub (or your registry), and S3.
Download SDR package
- Docker
- Podman
curl -fSL -o sdr-orchestrator-docker.tar.gz \
https://atlan-public.s3.eu-west-1.amazonaws.com/sdr-orchestrator-app/sdr-orchestrator-docker.tar.gz
tar -xzf sdr-orchestrator-docker.tar.gz
cd sdr-orchestrator-docker
curl -fSL -o sdr-orchestrator-podman.tar.gz \
https://atlan-public.s3.eu-west-1.amazonaws.com/sdr-orchestrator-app/sdr-orchestrator-podman.tar.gz
tar -xzf sdr-orchestrator-podman.tar.gz
cd sdr-orchestrator-podman
Prepare host environment
- Docker
- Podman
docker login -u atlanhq # enter the Atlan-provided PAT
sudo loginctl enable-linger $(whoami)
systemctl --user enable --now podman.socket
podman login -u atlanhq docker.io # enter the Atlan-provided PAT
Generate OAuth credentials
SDR uses per-deployment OAuth credentials to authenticate with Atlan. Generate an API token in the Atlan UI, then register this deployment:
curl --location 'https://<tenant>.atlan.com/api/service/oauth-clients' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer YOUR_API_TOKEN' \
--data '{
"displayName": "sdr-orchestrator",
"description": "OAuth client for SDR Orchestrator",
"scopes": ["events-app-permissions-scope","temporal-app-permissions-scope"]
}'
Save the clientId and clientSecret from the response — you'll use them in the configuration below.
Configure .env
- Docker
- Podman
Set credentials, a unique SDR_DEPLOYMENT_NAME, your Docker group ID (getent group docker | cut -d: -f3), and the absolute deployments path.
ATLAN_AUTH_CLIENT_ID=oauth-client-xxxxxxxx
ATLAN_AUTH_CLIENT_SECRET=xxxxxxxx
SDR_DEPLOYMENT_NAME=my-env
DOCKER_GID=988
SDR_DEPLOYMENTS_HOST_DIR=/home/ubuntu/sdr-orchestrator-docker/deployments
LOG_LEVEL=INFO
ATLAN_AUTH_CLIENT_ID=oauth-client-xxxxxxxx
ATLAN_AUTH_CLIENT_SECRET=xxxxxxxx
SDR_DEPLOYMENT_NAME=my-env
CONTAINER_RUNTIME_SOCKET=unix:///run/user/1000/podman/podman.sock
SDR_DEPLOYMENTS_HOST_DIR=/home/ubuntu/sdr-orchestrator-podman/deployments
LOG_LEVEL=INFO
Prepare config.yaml
Atlan identity
atlan:
deployment_name: "mycompany-ec2" # must match SDR_DEPLOYMENT_NAME
domain: "mycompany.atlan.com"
Object storage (in config.yaml)
Self-Deployed Runtime needs a store for reading and writing files. Configure the object store that matches your environment.
If your preferred object or secret store isn't listed, reach out to Atlan support. Dapr supports additional stores beyond those shown here.
- AWS S3
- Google Cloud Storage
- Azure Blob Storage
- Local file path
components:
objectstore:
type: bindings.aws.s3
version: v1
metadata:
- name: accessKey # optional, empty for IAM auth
value: ""
- name: secretKey # optional, empty for IAM auth
value: ""
- name: bucket
value: "<bucket-name>"
- name: region
value: "<bucket-region>"
- name: forcePathStyle
value: "true"
When accessKey and secretKey are empty, the SDR uses the EC2 instance role to access S3. Attach this minimum policy to the role:
{
"Version": "2012-10-17",
"Statement": [
{ "Effect": "Allow", "Action": ["s3:ListBucket"], "Resource": "arn:aws:s3:::<bucket-name>" },
{
"Effect": "Allow",
"Action": ["s3:PutObject", "s3:GetObject", "s3:DeleteObject"],
"Resource": "arn:aws:s3:::<bucket-name>/*"
}
]
}
Connection checks pass without these permissions. Extraction activities fail with AccessDenied only when the SDR writes to the bucket during a crawl. If the bucket uses SSE-KMS, also grant kms:GenerateDataKey and kms:Decrypt.
components:
objectstore:
type: bindings.gcp.bucket
version: v1
metadata:
- name: bucket
value: "<your-gcs-bucket-name>"
- name: type
value: "service_account"
- name: project_id
value: "<your-gcp-project-id>"
components:
objectstore:
type: bindings.azure.blobstorage
version: v1
metadata:
- name: accountName
value: "<your-storage-account-name>"
- name: accountKey
value: "<your-storage-account-key>"
- name: containerName
value: "<your-container-name>"
components:
objectstore:
type: bindings.localstorage
version: v1
metadata:
- name: rootPath
value: "/data/storage"
Mount a Docker volume to the configured path in your compose file, for example:
volumes:
- ./data:/data/storage
Secret store (in config.yaml)
Self-Deployed Runtime fetches source-system credentials from a secret store. Configure the one that aligns with your security infrastructure.
- AWS Secrets Manager
- Azure Key Vault
- GCP Secret Manager
- HashiCorp Vault
- Environment variables
components:
secretstore:
type: secretstores.aws.secretmanager
version: v1
metadata:
- name: region # required
value: "<secret-region>"
- name: accessKey # optional, empty for IAM auth
value: ""
- name: secretKey # optional, empty for IAM auth
value: ""
Leave accessKey/secretKey empty for IAM role / IRSA authentication. For an IAM user, set them to the user's keys and grant:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret"],
"Resource": "arn:aws:secretsmanager:<region>:<account-id>:secret:<secret-name>*"
}
]
}
Include the trailing * in the secret ARN — AWS appends a random suffix to secret names, so omitting it can cause access failures.
components:
secretstore:
type: secretstores.azure.keyvault
version: v1
metadata:
- name: vaultName
value: "<your-keyvault-name>"
- name: azureTenantId
value: "<your-tenant-id>"
- name: azureClientId
value: "<your-client-id>"
- name: azureClientSecret
value: "<your-client-secret>"
Azure Key Vault supports multiple auth methods: client secret (shown), certificate (azureCertificateFile), or managed identity (omit the auth fields).
components:
secretstore:
type: secretstores.gcp.secretmanager
version: v1
metadata:
- name: type
value: "service_account"
- name: project_id
value: "<project-id>"
- name: private_key_id
value: "<private-key-id>"
- name: private_key
value: "<private-key>"
- name: client_email
value: "<client-email>"
- name: client_id
value: "<client-id>"
components:
secretstore:
type: secretstores.hashicorp.vault
version: v1
metadata:
- name: vaultAddr # Optional
value: "https://127.0.0.1:8200"
- name: caCert # Optional. This or caPath/caPem
value: "[ca_cert]"
- name: skipVerify # Optional
value: "false"
- name: vaultTokenMountPath # or vaultToken
value: "[path_to_token_file]"
- name: vaultToken # or vaultTokenMountPath
value: "[vault_token]"
- name: vaultKVPrefix # Optional
value: "dapr"
- name: enginePath # Optional
value: "secret"
- name: vaultValueType # Optional
value: "map"
components:
secretstore:
type: secretstores.local.env
version: v1
Container registry — Docker Hub
Add a container_registry section to the end of config.yaml with the credentials the SDR uses to pull private atlanhq/* images. Leave base unset to pull from Docker Hub unchanged — it's only needed when you mirror images.
container_registry:
username: "<your-dockerhub-username>"
password: "<your-dockerhub-pat>"
# base: "" — optional; set only when mirroring to your own registry
The container_registry section is not in the default config.yaml — add it manually at the end of the file.
Sample config.yaml files
Copy-paste-ready files for common infrastructure combinations:
- AWS
- GCP
- Azure
- AWS + private registry
- On-premises
atlan:
deployment_name: "mycompany-ec2"
domain: "mycompany.atlan.com"
components:
objectstore:
type: bindings.aws.s3
version: v1
metadata:
- name: bucket
value: "<your-bucket-name>"
- name: region
value: "us-east-1"
- name: forcePathStyle
value: "true"
secretstore:
type: secretstores.aws.secretmanager
version: v1
metadata:
- name: region
value: "us-east-1"
container_registry:
base: "docker.io/atlanhq"
username: "<your-dockerhub-username>"
password: "<your-dockerhub-pat>"
atlan:
deployment_name: "mycompany-gce"
domain: "mycompany.atlan.com"
components:
objectstore:
type: bindings.gcp.bucket
version: v1
metadata:
- name: bucket
value: "<your-gcs-bucket-name>"
- name: type
value: "service_account"
- name: project_id
value: "<your-gcp-project-id>"
secretstore:
type: secretstores.gcp.secretmanager
version: v1
metadata:
- name: type
value: "service_account"
- name: project_id
value: "<your-gcp-project-id>"
- name: private_key_id
value: "<private-key-id>"
- name: private_key
value: "<private-key>"
- name: client_email
value: "<client-email>"
container_registry:
base: "docker.io/atlanhq"
username: "<your-dockerhub-username>"
password: "<your-dockerhub-pat>"
atlan:
deployment_name: "mycompany-azure"
domain: "mycompany.atlan.com"
components:
objectstore:
type: bindings.azure.blobstorage
version: v1
metadata:
- name: accountName
value: "<your-storage-account-name>"
- name: accountKey
value: "<your-storage-account-key>"
- name: containerName
value: "<your-container-name>"
secretstore:
type: secretstores.azure.keyvault
version: v1
metadata:
- name: vaultName
value: "<your-keyvault-name>"
- name: azureTenantId
value: "<your-tenant-id>"
- name: azureClientId
value: "<your-client-id>"
- name: azureClientSecret
value: "<your-client-secret>"
container_registry:
base: "docker.io/atlanhq"
username: "<your-dockerhub-username>"
password: "<your-dockerhub-pat>"
atlan:
deployment_name: "mycompany-ec2"
domain: "mycompany.atlan.com"
components:
objectstore:
type: bindings.aws.s3
version: v1
metadata:
- name: bucket
value: "<your-bucket-name>"
- name: region
value: "us-east-1"
- name: forcePathStyle
value: "true"
secretstore:
type: secretstores.aws.secretmanager
version: v1
metadata:
- name: region
value: "us-east-1"
container_registry:
base: "<your-registry-host>/atlan"
username: "<your-registry-username>"
password: "<your-registry-token>"
atlan:
deployment_name: "mycompany-onprem"
domain: "mycompany.atlan.com"
components:
objectstore:
type: bindings.localstorage
version: v1
metadata:
- name: rootPath
value: "/data/storage"
secretstore:
type: secretstores.local.env
version: v1
container_registry:
base: "docker.io/atlanhq"
username: "<your-dockerhub-username>"
password: "<your-dockerhub-pat>"
Start SDR Orchestrator
- Docker
- Podman
docker compose up -d
podman compose up -d
Verify installation
- Docker
- Podman
docker ps | grep atlan-sdr
docker logs atlan-sdr-<deployment-name>
podman ps | grep atlan-sdr
podman logs atlan-sdr-<deployment-name>
In Atlan, go to Settings > Self-Deployed Runtimes — your deployment appears as Connected.
Deploy connector apps from the Atlan UI
Once the runtime shows Connected, go to the Marketplace, pick an app, click Install, and choose this SDR as the deployment target. The orchestrator provisions credentials, runs the configurator, starts the container, and reports back — the steps are identical regardless of which connector you pick. No terminal commands needed.
Automatic updates
The orchestrator manages two kinds of automatic updates — no manual action needed:
- App updates: when a new app version is published, the reconciler detects the version mismatch (checked every ~60 minutes) and runs
helm upgrade --install(or the Docker equivalent) with the new image tag. - SDR self-updates: the orchestrator is itself a marketplace app. When a new SDR version ships, the same reconciler rolls the orchestrator to the new version (blue-green on Docker, rolling on Kubernetes).
Common issues:
- ImagePullBackOff / pull failures: check registry credentials and whether the Docker Hub PAT needs rotation.
- "Disconnected" / "IP not allowed": your egress IP may need allowlisting on the Atlan tenant — contact your Atlan representative.
- Auth token refresh failed: recheck the OAuth
clientId/clientSecret.
See the SDR Orchestrator FAQ for more.
When a new version ships, follow the guided update steps for this same profile — your selections carry over.
Your install guide: SDR Orchestrator (auto-managed) · Docker / Podman · Mirrored, same names/tags
Install SDR Orchestrator on Docker / Podman
System requirements
- SDR Orchestrator: 0.5 vCPU, 256 MB RAM, ~500 MB disk.
- Per app: 0.5–1 vCPU, 512 MB–1 GB RAM, ~1–2 GB disk.
- Size the VM by adding orchestrator + per-app needs (e.g. orchestrator + 3 apps ≈ 2 vCPUs, 4 GB RAM, 20 GB disk).
Prerequisites
- Linux host (x86_64 or arm64) — Windows/macOS not supported.
- Docker Engine 20.10+ with Compose, or Podman 4.0+ with podman-compose.
- A Docker Hub PAT from Atlan (to pull private app images).
- Object storage and a secret store.
- Outbound HTTPS + gRPC to Atlan, Docker Hub (or your registry), and S3.
Download SDR package
- Docker
- Podman
curl -fSL -o sdr-orchestrator-docker.tar.gz \
https://atlan-public.s3.eu-west-1.amazonaws.com/sdr-orchestrator-app/sdr-orchestrator-docker.tar.gz
tar -xzf sdr-orchestrator-docker.tar.gz
cd sdr-orchestrator-docker
curl -fSL -o sdr-orchestrator-podman.tar.gz \
https://atlan-public.s3.eu-west-1.amazonaws.com/sdr-orchestrator-app/sdr-orchestrator-podman.tar.gz
tar -xzf sdr-orchestrator-podman.tar.gz
cd sdr-orchestrator-podman
Prepare host environment
- Docker
- Podman
docker login -u atlanhq # enter the Atlan-provided PAT
sudo loginctl enable-linger $(whoami)
systemctl --user enable --now podman.socket
podman login -u atlanhq docker.io # enter the Atlan-provided PAT
Generate OAuth credentials
SDR uses per-deployment OAuth credentials to authenticate with Atlan. Generate an API token in the Atlan UI, then register this deployment:
curl --location 'https://<tenant>.atlan.com/api/service/oauth-clients' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer YOUR_API_TOKEN' \
--data '{
"displayName": "sdr-orchestrator",
"description": "OAuth client for SDR Orchestrator",
"scopes": ["events-app-permissions-scope","temporal-app-permissions-scope"]
}'
Save the clientId and clientSecret from the response — you'll use them in the configuration below.
Configure .env
- Docker
- Podman
Set credentials, a unique SDR_DEPLOYMENT_NAME, your Docker group ID (getent group docker | cut -d: -f3), and the absolute deployments path.
ATLAN_AUTH_CLIENT_ID=oauth-client-xxxxxxxx
ATLAN_AUTH_CLIENT_SECRET=xxxxxxxx
SDR_DEPLOYMENT_NAME=my-env
DOCKER_GID=988
SDR_DEPLOYMENTS_HOST_DIR=/home/ubuntu/sdr-orchestrator-docker/deployments
LOG_LEVEL=INFO
ATLAN_AUTH_CLIENT_ID=oauth-client-xxxxxxxx
ATLAN_AUTH_CLIENT_SECRET=xxxxxxxx
SDR_DEPLOYMENT_NAME=my-env
CONTAINER_RUNTIME_SOCKET=unix:///run/user/1000/podman/podman.sock
SDR_DEPLOYMENTS_HOST_DIR=/home/ubuntu/sdr-orchestrator-podman/deployments
LOG_LEVEL=INFO
Prepare config.yaml
Atlan identity
atlan:
deployment_name: "mycompany-ec2" # must match SDR_DEPLOYMENT_NAME
domain: "mycompany.atlan.com"
Object storage (in config.yaml)
Self-Deployed Runtime needs a store for reading and writing files. Configure the object store that matches your environment.
If your preferred object or secret store isn't listed, reach out to Atlan support. Dapr supports additional stores beyond those shown here.
- AWS S3
- Google Cloud Storage
- Azure Blob Storage
- Local file path
components:
objectstore:
type: bindings.aws.s3
version: v1
metadata:
- name: accessKey # optional, empty for IAM auth
value: ""
- name: secretKey # optional, empty for IAM auth
value: ""
- name: bucket
value: "<bucket-name>"
- name: region
value: "<bucket-region>"
- name: forcePathStyle
value: "true"
When accessKey and secretKey are empty, the SDR uses the EC2 instance role to access S3. Attach this minimum policy to the role:
{
"Version": "2012-10-17",
"Statement": [
{ "Effect": "Allow", "Action": ["s3:ListBucket"], "Resource": "arn:aws:s3:::<bucket-name>" },
{
"Effect": "Allow",
"Action": ["s3:PutObject", "s3:GetObject", "s3:DeleteObject"],
"Resource": "arn:aws:s3:::<bucket-name>/*"
}
]
}
Connection checks pass without these permissions. Extraction activities fail with AccessDenied only when the SDR writes to the bucket during a crawl. If the bucket uses SSE-KMS, also grant kms:GenerateDataKey and kms:Decrypt.
components:
objectstore:
type: bindings.gcp.bucket
version: v1
metadata:
- name: bucket
value: "<your-gcs-bucket-name>"
- name: type
value: "service_account"
- name: project_id
value: "<your-gcp-project-id>"
components:
objectstore:
type: bindings.azure.blobstorage
version: v1
metadata:
- name: accountName
value: "<your-storage-account-name>"
- name: accountKey
value: "<your-storage-account-key>"
- name: containerName
value: "<your-container-name>"
components:
objectstore:
type: bindings.localstorage
version: v1
metadata:
- name: rootPath
value: "/data/storage"
Mount a Docker volume to the configured path in your compose file, for example:
volumes:
- ./data:/data/storage
Secret store (in config.yaml)
Self-Deployed Runtime fetches source-system credentials from a secret store. Configure the one that aligns with your security infrastructure.
- AWS Secrets Manager
- Azure Key Vault
- GCP Secret Manager
- HashiCorp Vault
- Environment variables
components:
secretstore:
type: secretstores.aws.secretmanager
version: v1
metadata:
- name: region # required
value: "<secret-region>"
- name: accessKey # optional, empty for IAM auth
value: ""
- name: secretKey # optional, empty for IAM auth
value: ""
Leave accessKey/secretKey empty for IAM role / IRSA authentication. For an IAM user, set them to the user's keys and grant:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret"],
"Resource": "arn:aws:secretsmanager:<region>:<account-id>:secret:<secret-name>*"
}
]
}
Include the trailing * in the secret ARN — AWS appends a random suffix to secret names, so omitting it can cause access failures.
components:
secretstore:
type: secretstores.azure.keyvault
version: v1
metadata:
- name: vaultName
value: "<your-keyvault-name>"
- name: azureTenantId
value: "<your-tenant-id>"
- name: azureClientId
value: "<your-client-id>"
- name: azureClientSecret
value: "<your-client-secret>"
Azure Key Vault supports multiple auth methods: client secret (shown), certificate (azureCertificateFile), or managed identity (omit the auth fields).
components:
secretstore:
type: secretstores.gcp.secretmanager
version: v1
metadata:
- name: type
value: "service_account"
- name: project_id
value: "<project-id>"
- name: private_key_id
value: "<private-key-id>"
- name: private_key
value: "<private-key>"
- name: client_email
value: "<client-email>"
- name: client_id
value: "<client-id>"
components:
secretstore:
type: secretstores.hashicorp.vault
version: v1
metadata:
- name: vaultAddr # Optional
value: "https://127.0.0.1:8200"
- name: caCert # Optional. This or caPath/caPem
value: "[ca_cert]"
- name: skipVerify # Optional
value: "false"
- name: vaultTokenMountPath # or vaultToken
value: "[path_to_token_file]"
- name: vaultToken # or vaultTokenMountPath
value: "[vault_token]"
- name: vaultKVPrefix # Optional
value: "dapr"
- name: enginePath # Optional
value: "secret"
- name: vaultValueType # Optional
value: "map"
components:
secretstore:
type: secretstores.local.env
version: v1
Container registry — mirrored under a prefix
Set base to your registry prefix to rewrite image references. For example, atlanhq/monte-carlo:1.2.3 becomes your-registry/atlan/monte-carlo:1.2.3.
container_registry:
base: "<your-registry-host>/atlan"
username: "<your-registry-username>"
password: "<your-registry-token>"
docker pull atlanhq/atlan-saperp-app:latest
docker tag atlanhq/atlan-saperp-app:latest your-registry/atlan/atlan-saperp-app:latest
docker push your-registry/atlan/atlan-saperp-app:latest
Sample config.yaml files
Copy-paste-ready files for common infrastructure combinations:
- AWS
- GCP
- Azure
- AWS + private registry
- On-premises
atlan:
deployment_name: "mycompany-ec2"
domain: "mycompany.atlan.com"
components:
objectstore:
type: bindings.aws.s3
version: v1
metadata:
- name: bucket
value: "<your-bucket-name>"
- name: region
value: "us-east-1"
- name: forcePathStyle
value: "true"
secretstore:
type: secretstores.aws.secretmanager
version: v1
metadata:
- name: region
value: "us-east-1"
container_registry:
base: "docker.io/atlanhq"
username: "<your-dockerhub-username>"
password: "<your-dockerhub-pat>"
atlan:
deployment_name: "mycompany-gce"
domain: "mycompany.atlan.com"
components:
objectstore:
type: bindings.gcp.bucket
version: v1
metadata:
- name: bucket
value: "<your-gcs-bucket-name>"
- name: type
value: "service_account"
- name: project_id
value: "<your-gcp-project-id>"
secretstore:
type: secretstores.gcp.secretmanager
version: v1
metadata:
- name: type
value: "service_account"
- name: project_id
value: "<your-gcp-project-id>"
- name: private_key_id
value: "<private-key-id>"
- name: private_key
value: "<private-key>"
- name: client_email
value: "<client-email>"
container_registry:
base: "docker.io/atlanhq"
username: "<your-dockerhub-username>"
password: "<your-dockerhub-pat>"
atlan:
deployment_name: "mycompany-azure"
domain: "mycompany.atlan.com"
components:
objectstore:
type: bindings.azure.blobstorage
version: v1
metadata:
- name: accountName
value: "<your-storage-account-name>"
- name: accountKey
value: "<your-storage-account-key>"
- name: containerName
value: "<your-container-name>"
secretstore:
type: secretstores.azure.keyvault
version: v1
metadata:
- name: vaultName
value: "<your-keyvault-name>"
- name: azureTenantId
value: "<your-tenant-id>"
- name: azureClientId
value: "<your-client-id>"
- name: azureClientSecret
value: "<your-client-secret>"
container_registry:
base: "docker.io/atlanhq"
username: "<your-dockerhub-username>"
password: "<your-dockerhub-pat>"
atlan:
deployment_name: "mycompany-ec2"
domain: "mycompany.atlan.com"
components:
objectstore:
type: bindings.aws.s3
version: v1
metadata:
- name: bucket
value: "<your-bucket-name>"
- name: region
value: "us-east-1"
- name: forcePathStyle
value: "true"
secretstore:
type: secretstores.aws.secretmanager
version: v1
metadata:
- name: region
value: "us-east-1"
container_registry:
base: "<your-registry-host>/atlan"
username: "<your-registry-username>"
password: "<your-registry-token>"
atlan:
deployment_name: "mycompany-onprem"
domain: "mycompany.atlan.com"
components:
objectstore:
type: bindings.localstorage
version: v1
metadata:
- name: rootPath
value: "/data/storage"
secretstore:
type: secretstores.local.env
version: v1
container_registry:
base: "docker.io/atlanhq"
username: "<your-dockerhub-username>"
password: "<your-dockerhub-pat>"
Start SDR Orchestrator
- Docker
- Podman
docker compose up -d
podman compose up -d
Verify installation
- Docker
- Podman
docker ps | grep atlan-sdr
docker logs atlan-sdr-<deployment-name>
podman ps | grep atlan-sdr
podman logs atlan-sdr-<deployment-name>
In Atlan, go to Settings > Self-Deployed Runtimes — your deployment appears as Connected.
Deploy connector apps from the Atlan UI
Once the runtime shows Connected, go to the Marketplace, pick an app, click Install, and choose this SDR as the deployment target. The orchestrator provisions credentials, runs the configurator, starts the container, and reports back — the steps are identical regardless of which connector you pick. No terminal commands needed.
Automatic updates
The orchestrator manages two kinds of automatic updates — no manual action needed:
- App updates: when a new app version is published, the reconciler detects the version mismatch (checked every ~60 minutes) and runs
helm upgrade --install(or the Docker equivalent) with the new image tag. - SDR self-updates: the orchestrator is itself a marketplace app. When a new SDR version ships, the same reconciler rolls the orchestrator to the new version (blue-green on Docker, rolling on Kubernetes).
Common issues:
- ImagePullBackOff / pull failures: check registry credentials and whether the Docker Hub PAT needs rotation.
- "Disconnected" / "IP not allowed": your egress IP may need allowlisting on the Atlan tenant — contact your Atlan representative.
- Auth token refresh failed: recheck the OAuth
clientId/clientSecret.
See the SDR Orchestrator FAQ for more.
When a new version ships, follow the guided update steps for this same profile — your selections carry over.
Your install guide: SDR Orchestrator (auto-managed) · Docker / Podman · Rebuilt — names/tags differ
Install SDR Orchestrator on Docker / Podman
System requirements
- SDR Orchestrator: 0.5 vCPU, 256 MB RAM, ~500 MB disk.
- Per app: 0.5–1 vCPU, 512 MB–1 GB RAM, ~1–2 GB disk.
- Size the VM by adding orchestrator + per-app needs (e.g. orchestrator + 3 apps ≈ 2 vCPUs, 4 GB RAM, 20 GB disk).
Prerequisites
- Linux host (x86_64 or arm64) — Windows/macOS not supported.
- Docker Engine 20.10+ with Compose, or Podman 4.0+ with podman-compose.
- A Docker Hub PAT from Atlan (to pull private app images).
- Object storage and a secret store.
- Outbound HTTPS + gRPC to Atlan, Docker Hub (or your registry), and S3.
Download SDR package
- Docker
- Podman
curl -fSL -o sdr-orchestrator-docker.tar.gz \
https://atlan-public.s3.eu-west-1.amazonaws.com/sdr-orchestrator-app/sdr-orchestrator-docker.tar.gz
tar -xzf sdr-orchestrator-docker.tar.gz
cd sdr-orchestrator-docker
curl -fSL -o sdr-orchestrator-podman.tar.gz \
https://atlan-public.s3.eu-west-1.amazonaws.com/sdr-orchestrator-app/sdr-orchestrator-podman.tar.gz
tar -xzf sdr-orchestrator-podman.tar.gz
cd sdr-orchestrator-podman
Prepare host environment
- Docker
- Podman
docker login -u atlanhq # enter the Atlan-provided PAT
sudo loginctl enable-linger $(whoami)
systemctl --user enable --now podman.socket
podman login -u atlanhq docker.io # enter the Atlan-provided PAT
Generate OAuth credentials
SDR uses per-deployment OAuth credentials to authenticate with Atlan. Generate an API token in the Atlan UI, then register this deployment:
curl --location 'https://<tenant>.atlan.com/api/service/oauth-clients' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer YOUR_API_TOKEN' \
--data '{
"displayName": "sdr-orchestrator",
"description": "OAuth client for SDR Orchestrator",
"scopes": ["events-app-permissions-scope","temporal-app-permissions-scope"]
}'
Save the clientId and clientSecret from the response — you'll use them in the configuration below.
Configure .env
- Docker
- Podman
Set credentials, a unique SDR_DEPLOYMENT_NAME, your Docker group ID (getent group docker | cut -d: -f3), and the absolute deployments path.
ATLAN_AUTH_CLIENT_ID=oauth-client-xxxxxxxx
ATLAN_AUTH_CLIENT_SECRET=xxxxxxxx
SDR_DEPLOYMENT_NAME=my-env
DOCKER_GID=988
SDR_DEPLOYMENTS_HOST_DIR=/home/ubuntu/sdr-orchestrator-docker/deployments
LOG_LEVEL=INFO
ATLAN_AUTH_CLIENT_ID=oauth-client-xxxxxxxx
ATLAN_AUTH_CLIENT_SECRET=xxxxxxxx
SDR_DEPLOYMENT_NAME=my-env
CONTAINER_RUNTIME_SOCKET=unix:///run/user/1000/podman/podman.sock
SDR_DEPLOYMENTS_HOST_DIR=/home/ubuntu/sdr-orchestrator-podman/deployments
LOG_LEVEL=INFO
Prepare config.yaml
Atlan identity
atlan:
deployment_name: "mycompany-ec2" # must match SDR_DEPLOYMENT_NAME
domain: "mycompany.atlan.com"
Object storage (in config.yaml)
Self-Deployed Runtime needs a store for reading and writing files. Configure the object store that matches your environment.
If your preferred object or secret store isn't listed, reach out to Atlan support. Dapr supports additional stores beyond those shown here.
- AWS S3
- Google Cloud Storage
- Azure Blob Storage
- Local file path
components:
objectstore:
type: bindings.aws.s3
version: v1
metadata:
- name: accessKey # optional, empty for IAM auth
value: ""
- name: secretKey # optional, empty for IAM auth
value: ""
- name: bucket
value: "<bucket-name>"
- name: region
value: "<bucket-region>"
- name: forcePathStyle
value: "true"
When accessKey and secretKey are empty, the SDR uses the EC2 instance role to access S3. Attach this minimum policy to the role:
{
"Version": "2012-10-17",
"Statement": [
{ "Effect": "Allow", "Action": ["s3:ListBucket"], "Resource": "arn:aws:s3:::<bucket-name>" },
{
"Effect": "Allow",
"Action": ["s3:PutObject", "s3:GetObject", "s3:DeleteObject"],
"Resource": "arn:aws:s3:::<bucket-name>/*"
}
]
}
Connection checks pass without these permissions. Extraction activities fail with AccessDenied only when the SDR writes to the bucket during a crawl. If the bucket uses SSE-KMS, also grant kms:GenerateDataKey and kms:Decrypt.
components:
objectstore:
type: bindings.gcp.bucket
version: v1
metadata:
- name: bucket
value: "<your-gcs-bucket-name>"
- name: type
value: "service_account"
- name: project_id
value: "<your-gcp-project-id>"
components:
objectstore:
type: bindings.azure.blobstorage
version: v1
metadata:
- name: accountName
value: "<your-storage-account-name>"
- name: accountKey
value: "<your-storage-account-key>"
- name: containerName
value: "<your-container-name>"
components:
objectstore:
type: bindings.localstorage
version: v1
metadata:
- name: rootPath
value: "/data/storage"
Mount a Docker volume to the configured path in your compose file, for example:
volumes:
- ./data:/data/storage
Secret store (in config.yaml)
Self-Deployed Runtime fetches source-system credentials from a secret store. Configure the one that aligns with your security infrastructure.
- AWS Secrets Manager
- Azure Key Vault
- GCP Secret Manager
- HashiCorp Vault
- Environment variables
components:
secretstore:
type: secretstores.aws.secretmanager
version: v1
metadata:
- name: region # required
value: "<secret-region>"
- name: accessKey # optional, empty for IAM auth
value: ""
- name: secretKey # optional, empty for IAM auth
value: ""
Leave accessKey/secretKey empty for IAM role / IRSA authentication. For an IAM user, set them to the user's keys and grant:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret"],
"Resource": "arn:aws:secretsmanager:<region>:<account-id>:secret:<secret-name>*"
}
]
}
Include the trailing * in the secret ARN — AWS appends a random suffix to secret names, so omitting it can cause access failures.
components:
secretstore:
type: secretstores.azure.keyvault
version: v1
metadata:
- name: vaultName
value: "<your-keyvault-name>"
- name: azureTenantId
value: "<your-tenant-id>"
- name: azureClientId
value: "<your-client-id>"
- name: azureClientSecret
value: "<your-client-secret>"
Azure Key Vault supports multiple auth methods: client secret (shown), certificate (azureCertificateFile), or managed identity (omit the auth fields).
components:
secretstore:
type: secretstores.gcp.secretmanager
version: v1
metadata:
- name: type
value: "service_account"
- name: project_id
value: "<project-id>"
- name: private_key_id
value: "<private-key-id>"
- name: private_key
value: "<private-key>"
- name: client_email
value: "<client-email>"
- name: client_id
value: "<client-id>"
components:
secretstore:
type: secretstores.hashicorp.vault
version: v1
metadata:
- name: vaultAddr # Optional
value: "https://127.0.0.1:8200"
- name: caCert # Optional. This or caPath/caPem
value: "[ca_cert]"
- name: skipVerify # Optional
value: "false"
- name: vaultTokenMountPath # or vaultToken
value: "[path_to_token_file]"
- name: vaultToken # or vaultTokenMountPath
value: "[vault_token]"
- name: vaultKVPrefix # Optional
value: "dapr"
- name: enginePath # Optional
value: "secret"
- name: vaultValueType # Optional
value: "map"
components:
secretstore:
type: secretstores.local.env
version: v1
Container registry — rebuilt images (image map)
If your registry renames repositories or tags during replication, write an image-map.yaml to the object storage the SDR already uses and point the orchestrator at it with image_map_path.
images:
"atlanhq/atlan-saperp-app": "your-registry/atlan/atlan-saperp-app"
"atlanhq/atlan-saperp-app:latest": "your-registry/atlan/saperp:approved"
container_registry:
image_map_path: "sdr/image-map.yaml"
username: "<your-registry-username>"
password: "<your-registry-token>"
Poll the latest-releases endpoint so new images are mirrored before they're needed, and verify each image with Cosign before pushing.
curl -sS -H "Authorization: Bearer $ATLAN_API_TOKEN" \
"https://<your-tenant>.atlan.com/api/service/marketplace/latest-releases"
Sample config.yaml files
Copy-paste-ready files for common infrastructure combinations:
- AWS
- GCP
- Azure
- AWS + private registry
- On-premises
atlan:
deployment_name: "mycompany-ec2"
domain: "mycompany.atlan.com"
components:
objectstore:
type: bindings.aws.s3
version: v1
metadata:
- name: bucket
value: "<your-bucket-name>"
- name: region
value: "us-east-1"
- name: forcePathStyle
value: "true"
secretstore:
type: secretstores.aws.secretmanager
version: v1
metadata:
- name: region
value: "us-east-1"
container_registry:
base: "docker.io/atlanhq"
username: "<your-dockerhub-username>"
password: "<your-dockerhub-pat>"
atlan:
deployment_name: "mycompany-gce"
domain: "mycompany.atlan.com"
components:
objectstore:
type: bindings.gcp.bucket
version: v1
metadata:
- name: bucket
value: "<your-gcs-bucket-name>"
- name: type
value: "service_account"
- name: project_id
value: "<your-gcp-project-id>"
secretstore:
type: secretstores.gcp.secretmanager
version: v1
metadata:
- name: type
value: "service_account"
- name: project_id
value: "<your-gcp-project-id>"
- name: private_key_id
value: "<private-key-id>"
- name: private_key
value: "<private-key>"
- name: client_email
value: "<client-email>"
container_registry:
base: "docker.io/atlanhq"
username: "<your-dockerhub-username>"
password: "<your-dockerhub-pat>"
atlan:
deployment_name: "mycompany-azure"
domain: "mycompany.atlan.com"
components:
objectstore:
type: bindings.azure.blobstorage
version: v1
metadata:
- name: accountName
value: "<your-storage-account-name>"
- name: accountKey
value: "<your-storage-account-key>"
- name: containerName
value: "<your-container-name>"
secretstore:
type: secretstores.azure.keyvault
version: v1
metadata:
- name: vaultName
value: "<your-keyvault-name>"
- name: azureTenantId
value: "<your-tenant-id>"
- name: azureClientId
value: "<your-client-id>"
- name: azureClientSecret
value: "<your-client-secret>"
container_registry:
base: "docker.io/atlanhq"
username: "<your-dockerhub-username>"
password: "<your-dockerhub-pat>"
atlan:
deployment_name: "mycompany-ec2"
domain: "mycompany.atlan.com"
components:
objectstore:
type: bindings.aws.s3
version: v1
metadata:
- name: bucket
value: "<your-bucket-name>"
- name: region
value: "us-east-1"
- name: forcePathStyle
value: "true"
secretstore:
type: secretstores.aws.secretmanager
version: v1
metadata:
- name: region
value: "us-east-1"
container_registry:
base: "<your-registry-host>/atlan"
username: "<your-registry-username>"
password: "<your-registry-token>"
atlan:
deployment_name: "mycompany-onprem"
domain: "mycompany.atlan.com"
components:
objectstore:
type: bindings.localstorage
version: v1
metadata:
- name: rootPath
value: "/data/storage"
secretstore:
type: secretstores.local.env
version: v1
container_registry:
base: "docker.io/atlanhq"
username: "<your-dockerhub-username>"
password: "<your-dockerhub-pat>"
Start SDR Orchestrator
- Docker
- Podman
docker compose up -d
podman compose up -d
Verify installation
- Docker
- Podman
docker ps | grep atlan-sdr
docker logs atlan-sdr-<deployment-name>
podman ps | grep atlan-sdr
podman logs atlan-sdr-<deployment-name>
In Atlan, go to Settings > Self-Deployed Runtimes — your deployment appears as Connected.
Deploy connector apps from the Atlan UI
Once the runtime shows Connected, go to the Marketplace, pick an app, click Install, and choose this SDR as the deployment target. The orchestrator provisions credentials, runs the configurator, starts the container, and reports back — the steps are identical regardless of which connector you pick. No terminal commands needed.
Automatic updates
The orchestrator manages two kinds of automatic updates — no manual action needed:
- App updates: when a new app version is published, the reconciler detects the version mismatch (checked every ~60 minutes) and runs
helm upgrade --install(or the Docker equivalent) with the new image tag. - SDR self-updates: the orchestrator is itself a marketplace app. When a new SDR version ships, the same reconciler rolls the orchestrator to the new version (blue-green on Docker, rolling on Kubernetes).
Common issues:
- ImagePullBackOff / pull failures: check registry credentials and whether the Docker Hub PAT needs rotation.
- "Disconnected" / "IP not allowed": your egress IP may need allowlisting on the Atlan tenant — contact your Atlan representative.
- Auth token refresh failed: recheck the OAuth
clientId/clientSecret.
See the SDR Orchestrator FAQ for more.
When a new version ships, follow the guided update steps for this same profile — your selections carry over.
Your install guide: SDR Orchestrator (auto-managed) · Kubernetes · Public Atlan Docker Hub
Install SDR Orchestrator on Kubernetes
System requirements
- Any CNCF-conformant cluster (EKS, GKE, AKS, k3s, OpenShift…), v1.24+.
kubectland Helm v3+ with admin access.- SDR Orchestrator: 100m–500m CPU, 256Mi–512Mi memory.
- Per app: 0.5–1 vCPU, 512 MB–1 GB memory.
Prerequisites
- A Docker Hub PAT from Atlan (to pull private app images).
- Object storage and a secret store.
- Outbound HTTPS from the cluster to
<tenant>.atlan.com, the Temporal endpoint, anddocker.io.
Download SDR package
curl -fSL -o sdr-orchestrator-k8s.tar.gz \
https://atlan-public.s3.eu-west-1.amazonaws.com/sdr-orchestrator-k8s-app/sdr-orchestrator-k8s.tar.gz
tar -xzf sdr-orchestrator-k8s.tar.gz
cd sdr-orchestrator-k8s
Create namespace and registry credentials
kubectl create namespace atlan
kubectl create secret docker-registry atlan-registry-creds \
--namespace atlan \
--docker-server=docker.io \
--docker-username=YOUR_DOCKERHUB_USERNAME \
--docker-password=YOUR_DOCKERHUB_PAT
Generate OAuth credentials
SDR uses per-deployment OAuth credentials to authenticate with Atlan. Generate an API token in the Atlan UI, then register this deployment:
curl --location 'https://<tenant>.atlan.com/api/service/oauth-clients' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer YOUR_API_TOKEN' \
--data '{
"displayName": "sdr-orchestrator",
"description": "OAuth client for SDR Orchestrator",
"scopes": ["events-app-permissions-scope","temporal-app-permissions-scope"]
}'
Save the clientId and clientSecret from the response — you'll use them in the configuration below.
Configure values.yaml
Atlan identity
sdr:
enabled: true
deploymentName: "mycompany-eks"
credentials:
clientId: "oauth-client-xxxxxxxx"
clientSecret: "xxxxxxxx"
config:
domain: "mycompany.atlan.com"
Object storage (in values.yaml)
Self-Deployed Runtime needs a store for reading and writing files. Configure the object store that matches your environment.
If your preferred object or secret store isn't listed, reach out to Atlan support. Dapr supports additional stores beyond those shown here.
- AWS S3
- Google Cloud Storage
- Azure Blob Storage
sdr:
config:
components:
objectstore:
type: bindings.aws.s3
version: v1
metadata:
- name: accessKey # optional, empty for IAM auth
value: ""
- name: secretKey # optional, empty for IAM auth
value: ""
- name: bucket
value: "<bucket-name>"
- name: region
value: "<bucket-region>"
- name: forcePathStyle
value: "true"
When accessKey and secretKey are empty, the SDR uses the node's IAM role (or IRSA) to access S3. Attach this minimum policy to the role:
{
"Version": "2012-10-17",
"Statement": [
{ "Effect": "Allow", "Action": ["s3:ListBucket"], "Resource": "arn:aws:s3:::<bucket-name>" },
{
"Effect": "Allow",
"Action": ["s3:PutObject", "s3:GetObject", "s3:DeleteObject"],
"Resource": "arn:aws:s3:::<bucket-name>/*"
}
]
}
Connection checks pass without these permissions. Extraction activities fail with AccessDenied only when the SDR writes to the bucket during a crawl. If the bucket uses SSE-KMS, also grant kms:GenerateDataKey and kms:Decrypt.
sdr:
config:
components:
objectstore:
type: bindings.gcp.bucket
version: v1
metadata:
- name: bucket
value: "<your-gcs-bucket-name>"
- name: type
value: "service_account"
- name: project_id
value: "<your-gcp-project-id>"
sdr:
config:
components:
objectstore:
type: bindings.azure.blobstorage
version: v1
metadata:
- name: accountName
value: "<your-storage-account-name>"
- name: accountKey
value: "<your-storage-account-key>"
- name: containerName
value: "<your-container-name>"
Secret store (in values.yaml)
Self-Deployed Runtime fetches source-system credentials from a secret store. Configure the one that aligns with your security infrastructure.
- AWS Secrets Manager
- Azure Key Vault
- GCP Secret Manager
- HashiCorp Vault
- Environment variables
sdr:
config:
components:
secretstore:
type: secretstores.aws.secretmanager
version: v1
metadata:
- name: region # required
value: "<secret-region>"
- name: accessKey # optional, empty for IAM auth
value: ""
- name: secretKey # optional, empty for IAM auth
value: ""
Leave accessKey/secretKey empty for IAM role / IRSA authentication. For an IAM user, set them to the user's keys and grant:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret"],
"Resource": "arn:aws:secretsmanager:<region>:<account-id>:secret:<secret-name>*"
}
]
}
Include the trailing * in the secret ARN — AWS appends a random suffix to secret names, so omitting it can cause access failures.
sdr:
config:
components:
secretstore:
type: secretstores.azure.keyvault
version: v1
metadata:
- name: vaultName
value: "<your-keyvault-name>"
- name: azureTenantId
value: "<your-tenant-id>"
- name: azureClientId
value: "<your-client-id>"
- name: azureClientSecret
value: "<your-client-secret>"
Azure Key Vault supports multiple auth methods: client secret (shown), certificate (azureCertificateFile), or managed identity (omit the auth fields).
sdr:
config:
components:
secretstore:
type: secretstores.gcp.secretmanager
version: v1
metadata:
- name: type
value: "service_account"
- name: project_id
value: "<project-id>"
- name: private_key_id
value: "<private-key-id>"
- name: private_key
value: "<private-key>"
- name: client_email
value: "<client-email>"
- name: client_id
value: "<client-id>"
sdr:
config:
components:
secretstore:
type: secretstores.hashicorp.vault
version: v1
metadata:
- name: vaultAddr # Optional
value: "https://127.0.0.1:8200"
- name: caCert # Optional. This or caPath/caPem
value: "[ca_cert]"
- name: skipVerify # Optional
value: "false"
- name: vaultTokenMountPath # or vaultToken
value: "[path_to_token_file]"
- name: vaultToken # or vaultTokenMountPath
value: "[vault_token]"
- name: vaultKVPrefix # Optional
value: "dapr"
- name: enginePath # Optional
value: "secret"
- name: vaultValueType # Optional
value: "map"
sdr:
config:
components:
secretstore:
type: secretstores.local.env
version: v1
Container registry — public Docker Hub
Leave containerRegistryBase unset. The orchestrator pulls images from Docker Hub using the atlan-registry-creds secret you created earlier.
Sample values.yaml
- AWS (EKS)
- GCP (GKE)
- Azure (AKS)
image:
repository: atlanhq/atlan-sdr-orchestrator-k8s
tag: "latest" # pre-filled by Atlan—don't change
pullPolicy: Always
sdr:
enabled: true
deploymentName: "mycompany-eks"
credentials:
clientId: "oauth-client-xxxxxxxx"
clientSecret: "xxxxxxxx"
imagePullSecrets:
- name: atlan-registry-creds
config:
domain: "mycompany.atlan.com"
components:
objectstore:
type: bindings.aws.s3
version: v1
metadata:
- name: bucket
value: "<your-bucket-name>"
- name: region
value: "us-east-1"
- name: forcePathStyle
value: "true"
secretstore:
type: secretstores.aws.secretmanager
version: v1
metadata:
- name: region
value: "us-east-1"
image:
repository: atlanhq/atlan-sdr-orchestrator-k8s
tag: "latest" # pre-filled by Atlan—don't change
pullPolicy: Always
sdr:
enabled: true
deploymentName: "mycompany-gke"
credentials:
clientId: "oauth-client-xxxxxxxx"
clientSecret: "xxxxxxxx"
imagePullSecrets:
- name: atlan-registry-creds
config:
domain: "mycompany.atlan.com"
components:
objectstore:
type: bindings.gcp.bucket
version: v1
metadata:
- name: bucket
value: "<your-gcs-bucket-name>"
- name: type
value: "service_account"
- name: project_id
value: "<your-gcp-project-id>"
secretstore:
type: secretstores.gcp.secretmanager
version: v1
metadata:
- name: type
value: "service_account"
- name: project_id
value: "<your-gcp-project-id>"
image:
repository: atlanhq/atlan-sdr-orchestrator-k8s
tag: "latest" # pre-filled by Atlan—don't change
pullPolicy: Always
sdr:
enabled: true
deploymentName: "mycompany-aks"
credentials:
clientId: "oauth-client-xxxxxxxx"
clientSecret: "xxxxxxxx"
imagePullSecrets:
- name: atlan-registry-creds
config:
domain: "mycompany.atlan.com"
components:
objectstore:
type: bindings.azure.blobstorage
version: v1
metadata:
- name: accountName
value: "<your-storage-account-name>"
- name: accountKey
value: "<your-storage-account-key>"
- name: containerName
value: "<your-container-name>"
secretstore:
type: secretstores.azure.keyvault
version: v1
metadata:
- name: vaultName
value: "<your-keyvault-name>"
- name: azureTenantId
value: "<your-tenant-id>"
- name: azureClientId
value: "<your-client-id>"
- name: azureClientSecret
value: "<your-client-secret>"
Install SDR Orchestrator
By default the release name is atlan-sdr-<deployment_name>, which the self-update mechanism relies on. Keep this default unless you've set a custom release name (for example via an externally managed Helm release).
helm install atlan-sdr-<DEPLOYMENT_NAME> ./chart \
--namespace atlan \
-f values.yaml
Helm creates the Deployment, Secret, ConfigMap, ServiceAccount, Role, and RoleBinding in one command.
Verify installation
kubectl get pods -n atlan -l app=atlan-sdr
kubectl logs -n atlan -l app=atlan-sdr --tail=50
Look for K8s SDR worker listening on task_queue, then in Atlan go to Settings > Self-Deployed Runtimes — your deployment appears as Connected.
Deploy connector apps from the Atlan UI
Once the runtime shows Connected, go to the Marketplace, pick an app, click Install, and choose this SDR as the deployment target. The orchestrator provisions credentials, runs the configurator, starts the container, and reports back — the steps are identical regardless of which connector you pick. No terminal commands needed.
Automatic updates
The orchestrator manages two kinds of automatic updates — no manual action needed:
- App updates: when a new app version is published, the reconciler detects the version mismatch (checked every ~60 minutes) and runs
helm upgrade --install(or the Docker equivalent) with the new image tag. - SDR self-updates: the orchestrator is itself a marketplace app. When a new SDR version ships, the same reconciler rolls the orchestrator to the new version (blue-green on Docker, rolling on Kubernetes).
Uninstall
helm list -n atlan
helm uninstall <app> -n atlan # each managed app first
helm uninstall atlan-sdr-<DEPLOYMENT_NAME> -n atlan
kubectl delete secret atlan-registry-creds -n atlan
kubectl delete namespace atlan
Common issues:
- ImagePullBackOff / pull failures: check registry credentials and whether the Docker Hub PAT needs rotation.
- "Disconnected" / "IP not allowed": your egress IP may need allowlisting on the Atlan tenant — contact your Atlan representative.
- Auth token refresh failed: recheck the OAuth
clientId/clientSecret.
See the SDR Orchestrator FAQ for more.
When a new version ships, follow the guided update steps for this same profile — your selections carry over.
Your install guide: SDR Orchestrator (auto-managed) · Kubernetes · Mirrored, same names/tags
Install SDR Orchestrator on Kubernetes
System requirements
- Any CNCF-conformant cluster (EKS, GKE, AKS, k3s, OpenShift…), v1.24+.
kubectland Helm v3+ with admin access.- SDR Orchestrator: 100m–500m CPU, 256Mi–512Mi memory.
- Per app: 0.5–1 vCPU, 512 MB–1 GB memory.
Prerequisites
- A Docker Hub PAT from Atlan (to pull private app images).
- Object storage and a secret store.
- Outbound HTTPS from the cluster to
<tenant>.atlan.com, the Temporal endpoint, anddocker.io.
Download SDR package
curl -fSL -o sdr-orchestrator-k8s.tar.gz \
https://atlan-public.s3.eu-west-1.amazonaws.com/sdr-orchestrator-k8s-app/sdr-orchestrator-k8s.tar.gz
tar -xzf sdr-orchestrator-k8s.tar.gz
cd sdr-orchestrator-k8s
Create namespace and registry credentials
kubectl create namespace atlan
kubectl create secret docker-registry atlan-registry-creds \
--namespace atlan \
--docker-server=docker.io \
--docker-username=YOUR_DOCKERHUB_USERNAME \
--docker-password=YOUR_DOCKERHUB_PAT
Generate OAuth credentials
SDR uses per-deployment OAuth credentials to authenticate with Atlan. Generate an API token in the Atlan UI, then register this deployment:
curl --location 'https://<tenant>.atlan.com/api/service/oauth-clients' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer YOUR_API_TOKEN' \
--data '{
"displayName": "sdr-orchestrator",
"description": "OAuth client for SDR Orchestrator",
"scopes": ["events-app-permissions-scope","temporal-app-permissions-scope"]
}'
Save the clientId and clientSecret from the response — you'll use them in the configuration below.
Configure values.yaml
Atlan identity
sdr:
enabled: true
deploymentName: "mycompany-eks"
credentials:
clientId: "oauth-client-xxxxxxxx"
clientSecret: "xxxxxxxx"
config:
domain: "mycompany.atlan.com"
Object storage (in values.yaml)
Self-Deployed Runtime needs a store for reading and writing files. Configure the object store that matches your environment.
If your preferred object or secret store isn't listed, reach out to Atlan support. Dapr supports additional stores beyond those shown here.
- AWS S3
- Google Cloud Storage
- Azure Blob Storage
sdr:
config:
components:
objectstore:
type: bindings.aws.s3
version: v1
metadata:
- name: accessKey # optional, empty for IAM auth
value: ""
- name: secretKey # optional, empty for IAM auth
value: ""
- name: bucket
value: "<bucket-name>"
- name: region
value: "<bucket-region>"
- name: forcePathStyle
value: "true"
When accessKey and secretKey are empty, the SDR uses the node's IAM role (or IRSA) to access S3. Attach this minimum policy to the role:
{
"Version": "2012-10-17",
"Statement": [
{ "Effect": "Allow", "Action": ["s3:ListBucket"], "Resource": "arn:aws:s3:::<bucket-name>" },
{
"Effect": "Allow",
"Action": ["s3:PutObject", "s3:GetObject", "s3:DeleteObject"],
"Resource": "arn:aws:s3:::<bucket-name>/*"
}
]
}
Connection checks pass without these permissions. Extraction activities fail with AccessDenied only when the SDR writes to the bucket during a crawl. If the bucket uses SSE-KMS, also grant kms:GenerateDataKey and kms:Decrypt.
sdr:
config:
components:
objectstore:
type: bindings.gcp.bucket
version: v1
metadata:
- name: bucket
value: "<your-gcs-bucket-name>"
- name: type
value: "service_account"
- name: project_id
value: "<your-gcp-project-id>"
sdr:
config:
components:
objectstore:
type: bindings.azure.blobstorage
version: v1
metadata:
- name: accountName
value: "<your-storage-account-name>"
- name: accountKey
value: "<your-storage-account-key>"
- name: containerName
value: "<your-container-name>"
Secret store (in values.yaml)
Self-Deployed Runtime fetches source-system credentials from a secret store. Configure the one that aligns with your security infrastructure.
- AWS Secrets Manager
- Azure Key Vault
- GCP Secret Manager
- HashiCorp Vault
- Environment variables
sdr:
config:
components:
secretstore:
type: secretstores.aws.secretmanager
version: v1
metadata:
- name: region # required
value: "<secret-region>"
- name: accessKey # optional, empty for IAM auth
value: ""
- name: secretKey # optional, empty for IAM auth
value: ""
Leave accessKey/secretKey empty for IAM role / IRSA authentication. For an IAM user, set them to the user's keys and grant:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret"],
"Resource": "arn:aws:secretsmanager:<region>:<account-id>:secret:<secret-name>*"
}
]
}
Include the trailing * in the secret ARN — AWS appends a random suffix to secret names, so omitting it can cause access failures.
sdr:
config:
components:
secretstore:
type: secretstores.azure.keyvault
version: v1
metadata:
- name: vaultName
value: "<your-keyvault-name>"
- name: azureTenantId
value: "<your-tenant-id>"
- name: azureClientId
value: "<your-client-id>"
- name: azureClientSecret
value: "<your-client-secret>"
Azure Key Vault supports multiple auth methods: client secret (shown), certificate (azureCertificateFile), or managed identity (omit the auth fields).
sdr:
config:
components:
secretstore:
type: secretstores.gcp.secretmanager
version: v1
metadata:
- name: type
value: "service_account"
- name: project_id
value: "<project-id>"
- name: private_key_id
value: "<private-key-id>"
- name: private_key
value: "<private-key>"
- name: client_email
value: "<client-email>"
- name: client_id
value: "<client-id>"
sdr:
config:
components:
secretstore:
type: secretstores.hashicorp.vault
version: v1
metadata:
- name: vaultAddr # Optional
value: "https://127.0.0.1:8200"
- name: caCert # Optional. This or caPath/caPem
value: "[ca_cert]"
- name: skipVerify # Optional
value: "false"
- name: vaultTokenMountPath # or vaultToken
value: "[path_to_token_file]"
- name: vaultToken # or vaultTokenMountPath
value: "[vault_token]"
- name: vaultKVPrefix # Optional
value: "dapr"
- name: enginePath # Optional
value: "secret"
- name: vaultValueType # Optional
value: "map"
sdr:
config:
components:
secretstore:
type: secretstores.local.env
version: v1
Container registry — mirrored under a prefix
Set containerRegistryBase to rewrite image URLs at deploy time. For example, atlanhq/atlan-oracle-app:1.0 becomes myregistry.io/atlan/atlan-oracle-app:1.0.
sdr:
config:
containerRegistryBase: "myregistry.io/atlan"
Sample values.yaml
- AWS (EKS)
- GCP (GKE)
- Azure (AKS)
image:
repository: atlanhq/atlan-sdr-orchestrator-k8s
tag: "latest" # pre-filled by Atlan—don't change
pullPolicy: Always
sdr:
enabled: true
deploymentName: "mycompany-eks"
credentials:
clientId: "oauth-client-xxxxxxxx"
clientSecret: "xxxxxxxx"
imagePullSecrets:
- name: atlan-registry-creds
config:
domain: "mycompany.atlan.com"
components:
objectstore:
type: bindings.aws.s3
version: v1
metadata:
- name: bucket
value: "<your-bucket-name>"
- name: region
value: "us-east-1"
- name: forcePathStyle
value: "true"
secretstore:
type: secretstores.aws.secretmanager
version: v1
metadata:
- name: region
value: "us-east-1"
image:
repository: atlanhq/atlan-sdr-orchestrator-k8s
tag: "latest" # pre-filled by Atlan—don't change
pullPolicy: Always
sdr:
enabled: true
deploymentName: "mycompany-gke"
credentials:
clientId: "oauth-client-xxxxxxxx"
clientSecret: "xxxxxxxx"
imagePullSecrets:
- name: atlan-registry-creds
config:
domain: "mycompany.atlan.com"
components:
objectstore:
type: bindings.gcp.bucket
version: v1
metadata:
- name: bucket
value: "<your-gcs-bucket-name>"
- name: type
value: "service_account"
- name: project_id
value: "<your-gcp-project-id>"
secretstore:
type: secretstores.gcp.secretmanager
version: v1
metadata:
- name: type
value: "service_account"
- name: project_id
value: "<your-gcp-project-id>"
image:
repository: atlanhq/atlan-sdr-orchestrator-k8s
tag: "latest" # pre-filled by Atlan—don't change
pullPolicy: Always
sdr:
enabled: true
deploymentName: "mycompany-aks"
credentials:
clientId: "oauth-client-xxxxxxxx"
clientSecret: "xxxxxxxx"
imagePullSecrets:
- name: atlan-registry-creds
config:
domain: "mycompany.atlan.com"
components:
objectstore:
type: bindings.azure.blobstorage
version: v1
metadata:
- name: accountName
value: "<your-storage-account-name>"
- name: accountKey
value: "<your-storage-account-key>"
- name: containerName
value: "<your-container-name>"
secretstore:
type: secretstores.azure.keyvault
version: v1
metadata:
- name: vaultName
value: "<your-keyvault-name>"
- name: azureTenantId
value: "<your-tenant-id>"
- name: azureClientId
value: "<your-client-id>"
- name: azureClientSecret
value: "<your-client-secret>"
Install SDR Orchestrator
By default the release name is atlan-sdr-<deployment_name>, which the self-update mechanism relies on. Keep this default unless you've set a custom release name (for example via an externally managed Helm release).
helm install atlan-sdr-<DEPLOYMENT_NAME> ./chart \
--namespace atlan \
-f values.yaml
Helm creates the Deployment, Secret, ConfigMap, ServiceAccount, Role, and RoleBinding in one command.
Verify installation
kubectl get pods -n atlan -l app=atlan-sdr
kubectl logs -n atlan -l app=atlan-sdr --tail=50
Look for K8s SDR worker listening on task_queue, then in Atlan go to Settings > Self-Deployed Runtimes — your deployment appears as Connected.
Deploy connector apps from the Atlan UI
Once the runtime shows Connected, go to the Marketplace, pick an app, click Install, and choose this SDR as the deployment target. The orchestrator provisions credentials, runs the configurator, starts the container, and reports back — the steps are identical regardless of which connector you pick. No terminal commands needed.
Automatic updates
The orchestrator manages two kinds of automatic updates — no manual action needed:
- App updates: when a new app version is published, the reconciler detects the version mismatch (checked every ~60 minutes) and runs
helm upgrade --install(or the Docker equivalent) with the new image tag. - SDR self-updates: the orchestrator is itself a marketplace app. When a new SDR version ships, the same reconciler rolls the orchestrator to the new version (blue-green on Docker, rolling on Kubernetes).
Uninstall
helm list -n atlan
helm uninstall <app> -n atlan # each managed app first
helm uninstall atlan-sdr-<DEPLOYMENT_NAME> -n atlan
kubectl delete secret atlan-registry-creds -n atlan
kubectl delete namespace atlan
Common issues:
- ImagePullBackOff / pull failures: check registry credentials and whether the Docker Hub PAT needs rotation.
- "Disconnected" / "IP not allowed": your egress IP may need allowlisting on the Atlan tenant — contact your Atlan representative.
- Auth token refresh failed: recheck the OAuth
clientId/clientSecret.
See the SDR Orchestrator FAQ for more.
When a new version ships, follow the guided update steps for this same profile — your selections carry over.
Your install guide: SDR Orchestrator (auto-managed) · Kubernetes · Rebuilt — names/tags differ
Install SDR Orchestrator on Kubernetes
System requirements
- Any CNCF-conformant cluster (EKS, GKE, AKS, k3s, OpenShift…), v1.24+.
kubectland Helm v3+ with admin access.- SDR Orchestrator: 100m–500m CPU, 256Mi–512Mi memory.
- Per app: 0.5–1 vCPU, 512 MB–1 GB memory.
Prerequisites
- A Docker Hub PAT from Atlan (to pull private app images).
- Object storage and a secret store.
- Outbound HTTPS from the cluster to
<tenant>.atlan.com, the Temporal endpoint, anddocker.io.
Download SDR package
curl -fSL -o sdr-orchestrator-k8s.tar.gz \
https://atlan-public.s3.eu-west-1.amazonaws.com/sdr-orchestrator-k8s-app/sdr-orchestrator-k8s.tar.gz
tar -xzf sdr-orchestrator-k8s.tar.gz
cd sdr-orchestrator-k8s
Create namespace and registry credentials
kubectl create namespace atlan
kubectl create secret docker-registry atlan-registry-creds \
--namespace atlan \
--docker-server=docker.io \
--docker-username=YOUR_DOCKERHUB_USERNAME \
--docker-password=YOUR_DOCKERHUB_PAT
Generate OAuth credentials
SDR uses per-deployment OAuth credentials to authenticate with Atlan. Generate an API token in the Atlan UI, then register this deployment:
curl --location 'https://<tenant>.atlan.com/api/service/oauth-clients' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer YOUR_API_TOKEN' \
--data '{
"displayName": "sdr-orchestrator",
"description": "OAuth client for SDR Orchestrator",
"scopes": ["events-app-permissions-scope","temporal-app-permissions-scope"]
}'
Save the clientId and clientSecret from the response — you'll use them in the configuration below.
Configure values.yaml
Atlan identity
sdr:
enabled: true
deploymentName: "mycompany-eks"
credentials:
clientId: "oauth-client-xxxxxxxx"
clientSecret: "xxxxxxxx"
config:
domain: "mycompany.atlan.com"
Object storage (in values.yaml)
Self-Deployed Runtime needs a store for reading and writing files. Configure the object store that matches your environment.
If your preferred object or secret store isn't listed, reach out to Atlan support. Dapr supports additional stores beyond those shown here.
- AWS S3
- Google Cloud Storage
- Azure Blob Storage
sdr:
config:
components:
objectstore:
type: bindings.aws.s3
version: v1
metadata:
- name: accessKey # optional, empty for IAM auth
value: ""
- name: secretKey # optional, empty for IAM auth
value: ""
- name: bucket
value: "<bucket-name>"
- name: region
value: "<bucket-region>"
- name: forcePathStyle
value: "true"
When accessKey and secretKey are empty, the SDR uses the node's IAM role (or IRSA) to access S3. Attach this minimum policy to the role:
{
"Version": "2012-10-17",
"Statement": [
{ "Effect": "Allow", "Action": ["s3:ListBucket"], "Resource": "arn:aws:s3:::<bucket-name>" },
{
"Effect": "Allow",
"Action": ["s3:PutObject", "s3:GetObject", "s3:DeleteObject"],
"Resource": "arn:aws:s3:::<bucket-name>/*"
}
]
}
Connection checks pass without these permissions. Extraction activities fail with AccessDenied only when the SDR writes to the bucket during a crawl. If the bucket uses SSE-KMS, also grant kms:GenerateDataKey and kms:Decrypt.
sdr:
config:
components:
objectstore:
type: bindings.gcp.bucket
version: v1
metadata:
- name: bucket
value: "<your-gcs-bucket-name>"
- name: type
value: "service_account"
- name: project_id
value: "<your-gcp-project-id>"
sdr:
config:
components:
objectstore:
type: bindings.azure.blobstorage
version: v1
metadata:
- name: accountName
value: "<your-storage-account-name>"
- name: accountKey
value: "<your-storage-account-key>"
- name: containerName
value: "<your-container-name>"
Secret store (in values.yaml)
Self-Deployed Runtime fetches source-system credentials from a secret store. Configure the one that aligns with your security infrastructure.
- AWS Secrets Manager
- Azure Key Vault
- GCP Secret Manager
- HashiCorp Vault
- Environment variables
sdr:
config:
components:
secretstore:
type: secretstores.aws.secretmanager
version: v1
metadata:
- name: region # required
value: "<secret-region>"
- name: accessKey # optional, empty for IAM auth
value: ""
- name: secretKey # optional, empty for IAM auth
value: ""
Leave accessKey/secretKey empty for IAM role / IRSA authentication. For an IAM user, set them to the user's keys and grant:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret"],
"Resource": "arn:aws:secretsmanager:<region>:<account-id>:secret:<secret-name>*"
}
]
}
Include the trailing * in the secret ARN — AWS appends a random suffix to secret names, so omitting it can cause access failures.
sdr:
config:
components:
secretstore:
type: secretstores.azure.keyvault
version: v1
metadata:
- name: vaultName
value: "<your-keyvault-name>"
- name: azureTenantId
value: "<your-tenant-id>"
- name: azureClientId
value: "<your-client-id>"
- name: azureClientSecret
value: "<your-client-secret>"
Azure Key Vault supports multiple auth methods: client secret (shown), certificate (azureCertificateFile), or managed identity (omit the auth fields).
sdr:
config:
components:
secretstore:
type: secretstores.gcp.secretmanager
version: v1
metadata:
- name: type
value: "service_account"
- name: project_id
value: "<project-id>"
- name: private_key_id
value: "<private-key-id>"
- name: private_key
value: "<private-key>"
- name: client_email
value: "<client-email>"
- name: client_id
value: "<client-id>"
sdr:
config:
components:
secretstore:
type: secretstores.hashicorp.vault
version: v1
metadata:
- name: vaultAddr # Optional
value: "https://127.0.0.1:8200"
- name: caCert # Optional. This or caPath/caPem
value: "[ca_cert]"
- name: skipVerify # Optional
value: "false"
- name: vaultTokenMountPath # or vaultToken
value: "[path_to_token_file]"
- name: vaultToken # or vaultTokenMountPath
value: "[vault_token]"
- name: vaultKVPrefix # Optional
value: "dapr"
- name: enginePath # Optional
value: "secret"
- name: vaultValueType # Optional
value: "map"
sdr:
config:
components:
secretstore:
type: secretstores.local.env
version: v1
Container registry — rebuilt images (image map)
If your registry renames repositories or tags during replication, write an image-map.yaml to the object storage the SDR already uses and point the orchestrator at it with imageMapPath. The orchestrator reads the map on every install, upgrade, and self-update.
images:
# repo -> repo: covers every tag; source tag preserved
"atlanhq/atlan-oracle-app": "myregistry.io/atlan/atlan-oracle-app"
# repo:tag -> repo:tag: pins a single rebuilt/renamed image
"atlanhq/atlan-oracle-app:1.0": "myregistry.io/atlan/oracle:1.0-approved"
sdr:
config:
imageMapPath: "sdr/image-map.yaml"
Poll the latest-releases endpoint so new images are mirrored before they're needed, and verify each image with Cosign before pushing.
curl -sS -H "Authorization: Bearer $ATLAN_API_TOKEN" \
"https://<your-tenant>.atlan.com/api/service/marketplace/latest-releases"
Sample values.yaml
- AWS (EKS)
- GCP (GKE)
- Azure (AKS)
image:
repository: atlanhq/atlan-sdr-orchestrator-k8s
tag: "latest" # pre-filled by Atlan—don't change
pullPolicy: Always
sdr:
enabled: true
deploymentName: "mycompany-eks"
credentials:
clientId: "oauth-client-xxxxxxxx"
clientSecret: "xxxxxxxx"
imagePullSecrets:
- name: atlan-registry-creds
config:
domain: "mycompany.atlan.com"
components:
objectstore:
type: bindings.aws.s3
version: v1
metadata:
- name: bucket
value: "<your-bucket-name>"
- name: region
value: "us-east-1"
- name: forcePathStyle
value: "true"
secretstore:
type: secretstores.aws.secretmanager
version: v1
metadata:
- name: region
value: "us-east-1"
image:
repository: atlanhq/atlan-sdr-orchestrator-k8s
tag: "latest" # pre-filled by Atlan—don't change
pullPolicy: Always
sdr:
enabled: true
deploymentName: "mycompany-gke"
credentials:
clientId: "oauth-client-xxxxxxxx"
clientSecret: "xxxxxxxx"
imagePullSecrets:
- name: atlan-registry-creds
config:
domain: "mycompany.atlan.com"
components:
objectstore:
type: bindings.gcp.bucket
version: v1
metadata:
- name: bucket
value: "<your-gcs-bucket-name>"
- name: type
value: "service_account"
- name: project_id
value: "<your-gcp-project-id>"
secretstore:
type: secretstores.gcp.secretmanager
version: v1
metadata:
- name: type
value: "service_account"
- name: project_id
value: "<your-gcp-project-id>"
image:
repository: atlanhq/atlan-sdr-orchestrator-k8s
tag: "latest" # pre-filled by Atlan—don't change
pullPolicy: Always
sdr:
enabled: true
deploymentName: "mycompany-aks"
credentials:
clientId: "oauth-client-xxxxxxxx"
clientSecret: "xxxxxxxx"
imagePullSecrets:
- name: atlan-registry-creds
config:
domain: "mycompany.atlan.com"
components:
objectstore:
type: bindings.azure.blobstorage
version: v1
metadata:
- name: accountName
value: "<your-storage-account-name>"
- name: accountKey
value: "<your-storage-account-key>"
- name: containerName
value: "<your-container-name>"
secretstore:
type: secretstores.azure.keyvault
version: v1
metadata:
- name: vaultName
value: "<your-keyvault-name>"
- name: azureTenantId
value: "<your-tenant-id>"
- name: azureClientId
value: "<your-client-id>"
- name: azureClientSecret
value: "<your-client-secret>"
Install SDR Orchestrator
By default the release name is atlan-sdr-<deployment_name>, which the self-update mechanism relies on. Keep this default unless you've set a custom release name (for example via an externally managed Helm release).
helm install atlan-sdr-<DEPLOYMENT_NAME> ./chart \
--namespace atlan \
-f values.yaml
Helm creates the Deployment, Secret, ConfigMap, ServiceAccount, Role, and RoleBinding in one command.
Verify installation
kubectl get pods -n atlan -l app=atlan-sdr
kubectl logs -n atlan -l app=atlan-sdr --tail=50
Look for K8s SDR worker listening on task_queue, then in Atlan go to Settings > Self-Deployed Runtimes — your deployment appears as Connected.
Deploy connector apps from the Atlan UI
Once the runtime shows Connected, go to the Marketplace, pick an app, click Install, and choose this SDR as the deployment target. The orchestrator provisions credentials, runs the configurator, starts the container, and reports back — the steps are identical regardless of which connector you pick. No terminal commands needed.
Automatic updates
The orchestrator manages two kinds of automatic updates — no manual action needed:
- App updates: when a new app version is published, the reconciler detects the version mismatch (checked every ~60 minutes) and runs
helm upgrade --install(or the Docker equivalent) with the new image tag. - SDR self-updates: the orchestrator is itself a marketplace app. When a new SDR version ships, the same reconciler rolls the orchestrator to the new version (blue-green on Docker, rolling on Kubernetes).
Uninstall
helm list -n atlan
helm uninstall <app> -n atlan # each managed app first
helm uninstall atlan-sdr-<DEPLOYMENT_NAME> -n atlan
kubectl delete secret atlan-registry-creds -n atlan
kubectl delete namespace atlan
Common issues:
- ImagePullBackOff / pull failures: check registry credentials and whether the Docker Hub PAT needs rotation.
- "Disconnected" / "IP not allowed": your egress IP may need allowlisting on the Atlan tenant — contact your Atlan representative.
- Auth token refresh failed: recheck the OAuth
clientId/clientSecret.
See the SDR Orchestrator FAQ for more.
When a new version ships, follow the guided update steps for this same profile — your selections carry over.
Your install guide: Single-app (you manage) · Docker / Podman · Public Atlan Docker Hub
Install a connector app via Docker Compose
These steps are identical for every connector. The Helm chart name, image, and tag come from the config you download from the Marketplace (the image tag is also shown in the Atlan UI). For connector-specific requirements, see that connector's own documentation.
Prerequisites
- Docker ecosystem (Docker Engine, CLI, Compose).
- A Docker Hub Personal Access Token (PAT) from Atlan.
- Object storage and a secret store with appropriate permissions.
- The connector's system requirements — see that connector's documentation.
For security reasons the Docker Hub PAT is regenerated periodically. If the token is embedded in automation or CI/CD, those jobs may fail. Contact your Atlan representative for the latest token.
Download deployment configuration
In Atlan, open Workflow center > Marketplace, select the app, and click Download config for Self-Deployed Runtime. Choose Docker Compose and a deployment name, then Generate. Atlan produces config.yaml (auth + store placeholders) and a per-app YAML (app metadata, including the image and tag). Save both into a working directory.
Prepare deployment environment
Authenticate with Docker Hub, then download the configurator binary for your platform:
docker login -u atlanhq # enter the Atlan-provided PAT
- Linux AMD64
- Linux ARM64
- macOS ARM64
- macOS Intel
curl -O https://atlan-public.s3.amazonaws.com/apps/docker-compose-configurator-amd64.tgz
tar -xvf docker-compose-configurator-amd64.tgz
curl -O https://atlan-public.s3.amazonaws.com/apps/docker-compose-configurator-arm64.tgz
tar -xvf docker-compose-configurator-arm64.tgz
curl -O https://atlan-public.s3.amazonaws.com/apps/docker-compose-configurator-macos-aarch64.tgz
tar -xvf docker-compose-configurator-macos-aarch64.tgz
curl -O https://atlan-public.s3.amazonaws.com/apps/docker-compose-configurator-macos-intel.tgz
tar -xvf docker-compose-configurator-macos-intel.tgz
Configure deployment files
Object storage (in config.yaml)
Self-Deployed Runtime needs a store for reading and writing files. Configure the object store that matches your environment.
If your preferred object or secret store isn't listed, reach out to Atlan support. Dapr supports additional stores beyond those shown here.
- AWS S3
- Google Cloud Storage
- Azure Blob Storage
- Local file path
objectstore:
type: bindings.aws.s3
version: v1
metadata:
- name: accessKey # optional, empty for IAM auth
value: ""
- name: secretKey # optional, empty for IAM auth
value: ""
- name: bucket
value: "<bucket-name>"
- name: region
value: "<bucket-region>"
- name: forcePathStyle
value: "true"
objectstore:
type: bindings.gcp.bucket
version: v1
metadata:
- name: bucket
value: "<your-gcs-bucket-name>"
- name: type
value: "service_account"
- name: project_id
value: "<your-gcp-project-id>"
objectstore:
type: bindings.azure.blobstorage
version: v1
metadata:
- name: accountName
value: "<your-storage-account-name>"
- name: accountKey
value: "<your-storage-account-key>"
- name: containerName
value: "<your-container-name>"
objectstore:
type: bindings.localstorage
version: v1
metadata:
- name: rootPath
value: "/data/storage"
Mount a Docker volume to the configured path in your compose file, for example:
volumes:
- ./data:/data/storage
Secret store (in config.yaml)
Self-Deployed Runtime fetches source-system credentials from a secret store. Configure the one that aligns with your security infrastructure.
- AWS Secrets Manager
- Azure Key Vault
- GCP Secret Manager
- HashiCorp Vault
- Environment variables
secretstore:
type: secretstores.aws.secretmanager
version: v1
metadata:
- name: region # required
value: "<secret-region>"
- name: accessKey # optional, empty for IAM auth
value: ""
- name: secretKey # optional, empty for IAM auth
value: ""
Leave accessKey/secretKey empty for IAM role / IRSA authentication. For an IAM user, set them to the user's keys and grant:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret"],
"Resource": "arn:aws:secretsmanager:<region>:<account-id>:secret:<secret-name>*"
}
]
}
Include the trailing * in the secret ARN — AWS appends a random suffix to secret names, so omitting it can cause access failures.
secretstore:
type: secretstores.azure.keyvault
version: v1
metadata:
- name: vaultName
value: "<your-keyvault-name>"
- name: azureTenantId
value: "<your-tenant-id>"
- name: azureClientId
value: "<your-client-id>"
- name: azureClientSecret
value: "<your-client-secret>"
Azure Key Vault supports multiple auth methods: client secret (shown), certificate (azureCertificateFile), or managed identity (omit the auth fields).
secretstore:
type: secretstores.gcp.secretmanager
version: v1
metadata:
- name: type
value: "service_account"
- name: project_id
value: "<project-id>"
- name: private_key_id
value: "<private-key-id>"
- name: private_key
value: "<private-key>"
- name: client_email
value: "<client-email>"
- name: client_id
value: "<client-id>"
secretstore:
type: secretstores.hashicorp.vault
version: v1
metadata:
- name: vaultAddr # Optional
value: "https://127.0.0.1:8200"
- name: caCert # Optional. This or caPath/caPem
value: "[ca_cert]"
- name: skipVerify # Optional
value: "false"
- name: vaultTokenMountPath # or vaultToken
value: "[path_to_token_file]"
- name: vaultToken # or vaultTokenMountPath
value: "[vault_token]"
- name: vaultKVPrefix # Optional
value: "dapr"
- name: enginePath # Optional
value: "secret"
- name: vaultValueType # Optional
value: "map"
secretstore:
type: secretstores.local.env
version: v1
Image source — public Docker Hub
You authenticated with Docker Hub earlier (docker login), so no extra configuration is needed — the generated compose pulls atlanhq/<image-name>:<tag> directly.
Deploy runtime
./docker-compose-generator/generate --app <package>.yaml --config config.yaml
cd {app_name}-deployment
docker compose up -d
Verify
docker compose ps
docker logs <package> --tail=50 -f
Look for Uvicorn running on http://0.0.0.0:8000, dapr initialized. Status: Running, and GET /server/ready 200 in the logs.
Verify registration in Atlan
Once deployed, the app registers itself with your tenant. In Atlan, go to Workflows > Agent and confirm an entry named <app_name>-<deployment_name> shows as Active (takes a couple of minutes).
There's no auto-update in single-app mode. Poll the latest-releases endpoint to learn when a new version ships, then pull the new image and redeploy. (In-UI surfacing of outdated versions is planned.)
curl -sS -H "Authorization: Bearer $ATLAN_API_TOKEN" \
"https://<your-tenant>.atlan.com/api/service/marketplace/latest-releases"
Next steps
- Configure workflow execution: set up secret retrieval for your runtime.
- Verify container images: confirm image signatures with Cosign.
When a new version ships, follow the guided update steps for this same profile — your selections carry over.
Your install guide: Single-app (you manage) · Docker / Podman · Mirrored to your registry
Install a connector app via Docker Compose
These steps are identical for every connector. The Helm chart name, image, and tag come from the config you download from the Marketplace (the image tag is also shown in the Atlan UI). For connector-specific requirements, see that connector's own documentation.
Prerequisites
- Docker ecosystem (Docker Engine, CLI, Compose).
- A Docker Hub Personal Access Token (PAT) from Atlan.
- Object storage and a secret store with appropriate permissions.
- The connector's system requirements — see that connector's documentation.
For security reasons the Docker Hub PAT is regenerated periodically. If the token is embedded in automation or CI/CD, those jobs may fail. Contact your Atlan representative for the latest token.
Download deployment configuration
In Atlan, open Workflow center > Marketplace, select the app, and click Download config for Self-Deployed Runtime. Choose Docker Compose and a deployment name, then Generate. Atlan produces config.yaml (auth + store placeholders) and a per-app YAML (app metadata, including the image and tag). Save both into a working directory.
Prepare deployment environment
Authenticate with Docker Hub, then download the configurator binary for your platform:
docker login -u atlanhq # enter the Atlan-provided PAT
- Linux AMD64
- Linux ARM64
- macOS ARM64
- macOS Intel
curl -O https://atlan-public.s3.amazonaws.com/apps/docker-compose-configurator-amd64.tgz
tar -xvf docker-compose-configurator-amd64.tgz
curl -O https://atlan-public.s3.amazonaws.com/apps/docker-compose-configurator-arm64.tgz
tar -xvf docker-compose-configurator-arm64.tgz
curl -O https://atlan-public.s3.amazonaws.com/apps/docker-compose-configurator-macos-aarch64.tgz
tar -xvf docker-compose-configurator-macos-aarch64.tgz
curl -O https://atlan-public.s3.amazonaws.com/apps/docker-compose-configurator-macos-intel.tgz
tar -xvf docker-compose-configurator-macos-intel.tgz
Configure deployment files
Object storage (in config.yaml)
Self-Deployed Runtime needs a store for reading and writing files. Configure the object store that matches your environment.
If your preferred object or secret store isn't listed, reach out to Atlan support. Dapr supports additional stores beyond those shown here.
- AWS S3
- Google Cloud Storage
- Azure Blob Storage
- Local file path
objectstore:
type: bindings.aws.s3
version: v1
metadata:
- name: accessKey # optional, empty for IAM auth
value: ""
- name: secretKey # optional, empty for IAM auth
value: ""
- name: bucket
value: "<bucket-name>"
- name: region
value: "<bucket-region>"
- name: forcePathStyle
value: "true"
objectstore:
type: bindings.gcp.bucket
version: v1
metadata:
- name: bucket
value: "<your-gcs-bucket-name>"
- name: type
value: "service_account"
- name: project_id
value: "<your-gcp-project-id>"
objectstore:
type: bindings.azure.blobstorage
version: v1
metadata:
- name: accountName
value: "<your-storage-account-name>"
- name: accountKey
value: "<your-storage-account-key>"
- name: containerName
value: "<your-container-name>"
objectstore:
type: bindings.localstorage
version: v1
metadata:
- name: rootPath
value: "/data/storage"
Mount a Docker volume to the configured path in your compose file, for example:
volumes:
- ./data:/data/storage
Secret store (in config.yaml)
Self-Deployed Runtime fetches source-system credentials from a secret store. Configure the one that aligns with your security infrastructure.
- AWS Secrets Manager
- Azure Key Vault
- GCP Secret Manager
- HashiCorp Vault
- Environment variables
secretstore:
type: secretstores.aws.secretmanager
version: v1
metadata:
- name: region # required
value: "<secret-region>"
- name: accessKey # optional, empty for IAM auth
value: ""
- name: secretKey # optional, empty for IAM auth
value: ""
Leave accessKey/secretKey empty for IAM role / IRSA authentication. For an IAM user, set them to the user's keys and grant:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret"],
"Resource": "arn:aws:secretsmanager:<region>:<account-id>:secret:<secret-name>*"
}
]
}
Include the trailing * in the secret ARN — AWS appends a random suffix to secret names, so omitting it can cause access failures.
secretstore:
type: secretstores.azure.keyvault
version: v1
metadata:
- name: vaultName
value: "<your-keyvault-name>"
- name: azureTenantId
value: "<your-tenant-id>"
- name: azureClientId
value: "<your-client-id>"
- name: azureClientSecret
value: "<your-client-secret>"
Azure Key Vault supports multiple auth methods: client secret (shown), certificate (azureCertificateFile), or managed identity (omit the auth fields).
secretstore:
type: secretstores.gcp.secretmanager
version: v1
metadata:
- name: type
value: "service_account"
- name: project_id
value: "<project-id>"
- name: private_key_id
value: "<private-key-id>"
- name: private_key
value: "<private-key>"
- name: client_email
value: "<client-email>"
- name: client_id
value: "<client-id>"
secretstore:
type: secretstores.hashicorp.vault
version: v1
metadata:
- name: vaultAddr # Optional
value: "https://127.0.0.1:8200"
- name: caCert # Optional. This or caPath/caPem
value: "[ca_cert]"
- name: skipVerify # Optional
value: "false"
- name: vaultTokenMountPath # or vaultToken
value: "[path_to_token_file]"
- name: vaultToken # or vaultTokenMountPath
value: "[vault_token]"
- name: vaultKVPrefix # Optional
value: "dapr"
- name: enginePath # Optional
value: "secret"
- name: vaultValueType # Optional
value: "map"
secretstore:
type: secretstores.local.env
version: v1
Image source — mirrored / rebuilt (in <package>.yaml)
Replicate the image to your registry, then set app_image in your per-app YAML to the mirrored reference. Use the image and tag from the app_image field of your downloaded config.
docker pull atlanhq/<image-name>:<tag>
docker tag atlanhq/<image-name>:<tag> \
registry.mycompany.com/atlan/<image-name>:<tag>
docker push registry.mycompany.com/atlan/<image-name>:<tag>
app_image: "registry.mycompany.com/atlan/<image-name>:<tag>"
Poll the latest-releases endpoint so new images are mirrored before they're needed, and verify each image with Cosign before pushing.
curl -sS -H "Authorization: Bearer $ATLAN_API_TOKEN" \
"https://<your-tenant>.atlan.com/api/service/marketplace/latest-releases"
Deploy runtime
./docker-compose-generator/generate --app <package>.yaml --config config.yaml
cd {app_name}-deployment
docker compose up -d
Verify
docker compose ps
docker logs <package> --tail=50 -f
Look for Uvicorn running on http://0.0.0.0:8000, dapr initialized. Status: Running, and GET /server/ready 200 in the logs.
Verify registration in Atlan
Once deployed, the app registers itself with your tenant. In Atlan, go to Workflows > Agent and confirm an entry named <app_name>-<deployment_name> shows as Active (takes a couple of minutes).
There's no auto-update in single-app mode. Poll the latest-releases endpoint to learn when a new version ships, then pull the new image and redeploy. (In-UI surfacing of outdated versions is planned.)
curl -sS -H "Authorization: Bearer $ATLAN_API_TOKEN" \
"https://<your-tenant>.atlan.com/api/service/marketplace/latest-releases"
Next steps
- Configure workflow execution: set up secret retrieval for your runtime.
- Verify container images: confirm image signatures with Cosign.
When a new version ships, follow the guided update steps for this same profile — your selections carry over.
Your install guide: Single-app (you manage) · Kubernetes · Public Atlan Docker Hub
Install a connector app on Kubernetes
These steps are identical for every connector. The Helm chart name, image, and tag come from the config you download from the Marketplace (the image tag is also shown in the Atlan UI). For connector-specific requirements, see that connector's own documentation.
Prerequisites
kubectland Helm v3+ with admin access to the target cluster.- A Docker Hub Personal Access Token (PAT) from Atlan.
- The connector's Helm chart name (find it in that connector's documentation or the Marketplace).
- Object storage and a secret store with appropriate permissions.
- The connector's system requirements — see that connector's documentation.
For security reasons the Docker Hub PAT is regenerated periodically. If the token is embedded in automation or CI/CD, those jobs may fail. Contact your Atlan representative for the latest token.
Download required files
Pull the Helm chart, then download your Marketplace-generated values.yaml:
helm pull oci://registry-1.docker.io/atlanhq/<chart> --untar
In Atlan, open Workflow center > Marketplace, select the app, click Download config for Self-Deployed Runtime, choose Kubernetes (Helm), and Generate. Replace the default values.yaml inside ./<chart>/ with the downloaded one. Make all further edits there.
Modify values.yaml
Object storage (in values.yaml)
Self-Deployed Runtime needs a store for reading and writing files. Configure the object store that matches your environment.
If your preferred object or secret store isn't listed, reach out to Atlan support. Dapr supports additional stores beyond those shown here.
- AWS S3
- Google Cloud Storage
- Azure Blob Storage
objectstore:
enabled: true
spec:
type: bindings.aws.s3
version: v1
metadata:
- name: accessKey # optional, empty for IAM auth
value: ""
- name: secretKey # optional, empty for IAM auth
value: ""
- name: bucket
value: "<bucket-name>"
- name: region
value: "<bucket-region>"
- name: forcePathStyle
value: "true"
objectstore:
enabled: true
spec:
type: bindings.gcp.bucket
version: v1
metadata:
- name: bucket
value: "<your-gcs-bucket-name>"
- name: type
value: "service_account"
- name: project_id
value: "<your-gcp-project-id>"
objectstore:
enabled: true
spec:
type: bindings.azure.blobstorage
version: v1
metadata:
- name: accountName
value: "<your-storage-account-name>"
- name: accountKey
value: "<your-storage-account-key>"
- name: containerName
value: "<your-container-name>"
Secret store (in values.yaml)
Self-Deployed Runtime fetches source-system credentials from a secret store. Configure the one that aligns with your security infrastructure.
- AWS Secrets Manager
- Azure Key Vault
- GCP Secret Manager
- HashiCorp Vault
- Environment variables
secretstore:
enabled: true
spec:
type: secretstores.aws.secretmanager
version: v1
metadata:
- name: region # required
value: "<secret-region>"
- name: accessKey # optional, empty for IAM auth
value: ""
- name: secretKey # optional, empty for IAM auth
value: ""
Leave accessKey/secretKey empty for IAM role / IRSA authentication. For an IAM user, set them to the user's keys and grant:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret"],
"Resource": "arn:aws:secretsmanager:<region>:<account-id>:secret:<secret-name>*"
}
]
}
Include the trailing * in the secret ARN — AWS appends a random suffix to secret names, so omitting it can cause access failures.
secretstore:
enabled: true
spec:
type: secretstores.azure.keyvault
version: v1
metadata:
- name: vaultName
value: "<your-keyvault-name>"
- name: azureTenantId
value: "<your-tenant-id>"
- name: azureClientId
value: "<your-client-id>"
- name: azureClientSecret
value: "<your-client-secret>"
Azure Key Vault supports multiple auth methods: client secret (shown), certificate (azureCertificateFile), or managed identity (omit the auth fields).
secretstore:
enabled: true
spec:
type: secretstores.gcp.secretmanager
version: v1
metadata:
- name: type
value: "service_account"
- name: project_id
value: "<project-id>"
- name: private_key_id
value: "<private-key-id>"
- name: private_key
value: "<private-key>"
- name: client_email
value: "<client-email>"
- name: client_id
value: "<client-id>"
secretstore:
enabled: true
spec:
type: secretstores.hashicorp.vault
version: v1
metadata:
- name: vaultAddr # Optional
value: "https://127.0.0.1:8200"
- name: caCert # Optional. This or caPath/caPem
value: "[ca_cert]"
- name: skipVerify # Optional
value: "false"
- name: vaultTokenMountPath # or vaultToken
value: "[path_to_token_file]"
- name: vaultToken # or vaultTokenMountPath
value: "[vault_token]"
- name: vaultKVPrefix # Optional
value: "dapr"
- name: enginePath # Optional
value: "secret"
- name: vaultValueType # Optional
value: "map"
secretstore:
enabled: true
spec:
type: secretstores.local.env
version: v1
Image source — public Docker Hub
The chart pulls the app image from Atlan's Docker Hub. Create a pull secret:
kubectl create secret docker-registry atlan-docker-secret \
--docker-server=docker.io \
--docker-username=YOUR_USERNAME \
--docker-password=YOUR_PAT_TOKEN \
-n <namespace>
The downloaded values.yaml already references this secret under imagePullSecrets. The secret and the release must live in the same namespace, or the pod fails with ImagePullBackOff.
Deploy app
helm install <chart>-release ./<chart> -n <namespace>
Verify
kubectl get pods -n <namespace>
kubectl logs -n <namespace> -l app.kubernetes.io/name=<chart> --tail=50 -f
The pod should be Running with 1/1 ready.
Verify registration in Atlan
Once deployed, the app registers itself with your tenant. In Atlan, go to Workflows > Agent and confirm an entry named <app_name>-<deployment_name> shows as Active (takes a couple of minutes).
There's no auto-update in single-app mode. Poll the latest-releases endpoint to learn when a new version ships, then pull the new image and redeploy. (In-UI surfacing of outdated versions is planned.)
curl -sS -H "Authorization: Bearer $ATLAN_API_TOKEN" \
"https://<your-tenant>.atlan.com/api/service/marketplace/latest-releases"
Next steps
- Configure workflow execution: set up secret retrieval for your runtime.
- Verify container images: confirm image signatures with Cosign.
When a new version ships, follow the guided update steps for this same profile — your selections carry over.
Your install guide: Single-app (you manage) · Kubernetes · Mirrored to your registry
Install a connector app on Kubernetes
These steps are identical for every connector. The Helm chart name, image, and tag come from the config you download from the Marketplace (the image tag is also shown in the Atlan UI). For connector-specific requirements, see that connector's own documentation.
Prerequisites
kubectland Helm v3+ with admin access to the target cluster.- A Docker Hub Personal Access Token (PAT) from Atlan.
- The connector's Helm chart name (find it in that connector's documentation or the Marketplace).
- Object storage and a secret store with appropriate permissions.
- The connector's system requirements — see that connector's documentation.
For security reasons the Docker Hub PAT is regenerated periodically. If the token is embedded in automation or CI/CD, those jobs may fail. Contact your Atlan representative for the latest token.
Download required files
Pull the Helm chart, then download your Marketplace-generated values.yaml:
helm pull oci://registry-1.docker.io/atlanhq/<chart> --untar
In Atlan, open Workflow center > Marketplace, select the app, click Download config for Self-Deployed Runtime, choose Kubernetes (Helm), and Generate. Replace the default values.yaml inside ./<chart>/ with the downloaded one. Make all further edits there.
Modify values.yaml
Object storage (in values.yaml)
Self-Deployed Runtime needs a store for reading and writing files. Configure the object store that matches your environment.
If your preferred object or secret store isn't listed, reach out to Atlan support. Dapr supports additional stores beyond those shown here.
- AWS S3
- Google Cloud Storage
- Azure Blob Storage
objectstore:
enabled: true
spec:
type: bindings.aws.s3
version: v1
metadata:
- name: accessKey # optional, empty for IAM auth
value: ""
- name: secretKey # optional, empty for IAM auth
value: ""
- name: bucket
value: "<bucket-name>"
- name: region
value: "<bucket-region>"
- name: forcePathStyle
value: "true"
objectstore:
enabled: true
spec:
type: bindings.gcp.bucket
version: v1
metadata:
- name: bucket
value: "<your-gcs-bucket-name>"
- name: type
value: "service_account"
- name: project_id
value: "<your-gcp-project-id>"
objectstore:
enabled: true
spec:
type: bindings.azure.blobstorage
version: v1
metadata:
- name: accountName
value: "<your-storage-account-name>"
- name: accountKey
value: "<your-storage-account-key>"
- name: containerName
value: "<your-container-name>"
Secret store (in values.yaml)
Self-Deployed Runtime fetches source-system credentials from a secret store. Configure the one that aligns with your security infrastructure.
- AWS Secrets Manager
- Azure Key Vault
- GCP Secret Manager
- HashiCorp Vault
- Environment variables
secretstore:
enabled: true
spec:
type: secretstores.aws.secretmanager
version: v1
metadata:
- name: region # required
value: "<secret-region>"
- name: accessKey # optional, empty for IAM auth
value: ""
- name: secretKey # optional, empty for IAM auth
value: ""
Leave accessKey/secretKey empty for IAM role / IRSA authentication. For an IAM user, set them to the user's keys and grant:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret"],
"Resource": "arn:aws:secretsmanager:<region>:<account-id>:secret:<secret-name>*"
}
]
}
Include the trailing * in the secret ARN — AWS appends a random suffix to secret names, so omitting it can cause access failures.
secretstore:
enabled: true
spec:
type: secretstores.azure.keyvault
version: v1
metadata:
- name: vaultName
value: "<your-keyvault-name>"
- name: azureTenantId
value: "<your-tenant-id>"
- name: azureClientId
value: "<your-client-id>"
- name: azureClientSecret
value: "<your-client-secret>"
Azure Key Vault supports multiple auth methods: client secret (shown), certificate (azureCertificateFile), or managed identity (omit the auth fields).
secretstore:
enabled: true
spec:
type: secretstores.gcp.secretmanager
version: v1
metadata:
- name: type
value: "service_account"
- name: project_id
value: "<project-id>"
- name: private_key_id
value: "<private-key-id>"
- name: private_key
value: "<private-key>"
- name: client_email
value: "<client-email>"
- name: client_id
value: "<client-id>"
secretstore:
enabled: true
spec:
type: secretstores.hashicorp.vault
version: v1
metadata:
- name: vaultAddr # Optional
value: "https://127.0.0.1:8200"
- name: caCert # Optional. This or caPath/caPem
value: "[ca_cert]"
- name: skipVerify # Optional
value: "false"
- name: vaultTokenMountPath # or vaultToken
value: "[path_to_token_file]"
- name: vaultToken # or vaultTokenMountPath
value: "[vault_token]"
- name: vaultKVPrefix # Optional
value: "dapr"
- name: enginePath # Optional
value: "secret"
- name: vaultValueType # Optional
value: "map"
secretstore:
enabled: true
spec:
type: secretstores.local.env
version: v1
Image source — mirrored / rebuilt
Mirror the Atlan image to your registry and point values.yaml at it. Because you author the reference yourself, a changed prefix, name, tag, or SHA is handled the same way.
docker login -u atlanhq # enter the Atlan-provided PAT
docker pull atlanhq/<image-name>:<tag>
docker tag atlanhq/<image-name>:<tag> \
registry.mycompany.com/atlan/<image-name>:<tag>
docker push registry.mycompany.com/atlan/<image-name>:<tag>
image:
repository: "registry.mycompany.com/atlan/<image-name>"
tag: "<tag>"
imagePullSecrets:
- name: my-registry-secret
Poll the latest-releases endpoint so new images are mirrored before they're needed, and verify each image with Cosign before pushing.
curl -sS -H "Authorization: Bearer $ATLAN_API_TOKEN" \
"https://<your-tenant>.atlan.com/api/service/marketplace/latest-releases"
Deploy app
helm install <chart>-release ./<chart> -n <namespace>
Verify
kubectl get pods -n <namespace>
kubectl logs -n <namespace> -l app.kubernetes.io/name=<chart> --tail=50 -f
The pod should be Running with 1/1 ready.
Verify registration in Atlan
Once deployed, the app registers itself with your tenant. In Atlan, go to Workflows > Agent and confirm an entry named <app_name>-<deployment_name> shows as Active (takes a couple of minutes).
There's no auto-update in single-app mode. Poll the latest-releases endpoint to learn when a new version ships, then pull the new image and redeploy. (In-UI surfacing of outdated versions is planned.)
curl -sS -H "Authorization: Bearer $ATLAN_API_TOKEN" \
"https://<your-tenant>.atlan.com/api/service/marketplace/latest-releases"
Next steps
- Configure workflow execution: set up secret retrieval for your runtime.
- Verify container images: confirm image signatures with Cosign.
When a new version ships, follow the guided update steps for this same profile — your selections carry over.