Skip to main content

Deployment options

Connect docs via MCP

Self-Deployed Runtime uses containerization to run across any OCI-compliant environment. Each connector or application is packaged as a container image, so you can deploy on your existing infrastructure without changing your operational practices.

Did you know?

SDR requires additional enablement and licensing. Contact your Atlan representative for details.

Deployment models​

Atlan provides three deployment models. Each targets a different operational context—from quick evaluation to production scale to fully automated management.

Docker Compose is the simplest path. Atlan generates a docker-compose.yaml and environment configuration for each connector. You run the compose file on any Docker host. This is the right choice for evaluating a connector, running a single app, or environments where you want full manual control over every deployment step.

Kubernetes is for production workloads. Atlan provides Helm charts compatible with both managed clusters (EKS, AKS, GKE) and self-hosted Kubernetes. You get horizontal scaling, high availability, and the full Kubernetes operational model. This is the right choice if you already operate Kubernetes and need enterprise-grade reliability and orchestration.

SDR Orchestrator is for managing multiple connector apps on a Linux VM or Kubernetes cluster without repeating manual setup steps for every app. You run one container (or pod)—the orchestrator—and it manages the full lifecycle of all your connector apps: install, upgrade, and autoupdate. After the one-time bootstrap, every app is installed and managed from the Atlan UI with no per-app terminal work. This is the right choice if you're deploying several connectors and want automated lifecycle management. See Install SDR Orchestrator on Docker/Podman and SDR Orchestrator.

For Docker Compose and Kubernetes, the generated deployment artifacts include sections where you can modify infrastructure-specific attributes like security context, resource constraints, labels and annotations, and environment variables.

Docker/Podman vs Kubernetes​

Both Docker/Podman and Kubernetes run the same Self-Deployed Runtime app images and share the same core architecture. The platform you pick changes only the operational wrapper—how the runtime is hosted, scaled, and maintained—not what SDR can do. Here is Atlan's recommendation for deciding between them.

Atlan's recommendation​

Make the decision in this order—stop at the first step that gives you a clear answer:

  1. Match how you already host similar vendor solutions. Look at how other third-party or vendor-provided software (data agents, connectors, collectors, ETL workers) is deployed in your environment today. If those run on VMs, host SDR on Docker/Podman; if they run on your Kubernetes clusters, host SDR on Kubernetes. Reusing your established pattern means you inherit the security review, networking, monitoring, patching, and on-call practices you already have—this is usually the deciding factor.
  2. Then weigh enterprise requirements. If your organization mandates high availability, centralized RBAC, policy enforcement, GitOps/IaC-managed rollouts, or already has a platform team operating Kubernetes, lean Kubernetes. If you need the fewest moving parts, a single VM you fully control, or you're evaluating SDR, lean Docker/Podman.
  3. Then consider scale and the differences below. The more connectors you run and the higher the throughput, the more Kubernetes' scheduling, autoscaling, and self-healing pay off.

If none of these considerations points decisively one way, start on Docker/Podman on a single VM—it's the simplest path to a working runtime, and you can move to Kubernetes later since both use the same images.

Differences at glance​

DimensionDocker / PodmanKubernetes
Best fitVM-based hosting, evaluation, full manual controlProduction scale, HA, existing K8s platform team
High availabilitySingle-node; you add redundancy yourselfBuilt-in rescheduling, multi-node, self-healing
ScalingManual (resize VM, add hosts)Horizontal autoscaling, scheduling across nodes
Operational modeldocker/podman + ComposeHelm releases, namespaces, RBAC
Ops overheadLow to startHigher, but amortized if you already run Kubernetes

For platform-level comparisons from the official project documentation, see the Docker, Podman, and Kubernetes docs.

Container images​

Each connector app container image includes four key components that work in collaboration:

  • Dapr sidecar process for service interaction
  • Temporal Python SDK for connecting to Atlan's orchestrator
  • FastAPI server for handling requests
  • Core application logic implemented as Temporal workers

For more details about how these components interact, see the Core Architecture - Components reference.

How Atlan publishes images to Docker Hub​

Atlan builds and publishes every connector app—and the SDR Orchestrator itself—as OCI container images to Docker Hub, under the private atlanhq/* namespace (for example, atlanhq/atlan-oracle-app). This is the source of truth for SDR images:

  • Private and authenticated. The atlanhq/* repositories are private. Pulling an image requires the Docker Hub Personal Access Token (PAT) that your Atlan representative provides. The PAT is rotated periodically.
  • Versioned per release. Each app and orchestrator release is published as an immutable, tagged image (for example, atlanhq/atlan-oracle-app:main-ec46120). You can discover the current images for your tenant via the latest-releases endpoint.
  • Signed. Every image is signed with keyless Cosign, so you can confirm it was built by Atlan's official pipeline and hasn't been modified.

Pulling directly from Docker Hub is the default and recommended path—no replication pipeline to operate, and you always get the exact published image. If your environment can't reach Docker Hub or your policy requires images to pass through an internal registry, see Image procurement approach for when and how to mirror them instead.

See also​