App Lifecycle Modes
SDR requires additional enablement and licensing. Contact your Atlan representative for details.
Self-Deployed Runtime (SDR) connector apps run in one of two lifecycle modes. Both modes run entirely on your infrastructure and share the same core architecture. The difference is who owns install, start, stop, and upgrade after the initial deployment.
Use orchestrator mode unless you have a specific reason to manage app lifecycle yourself. The SDR Orchestrator is the default path for new SDR deployments—it automates credential provisioning, installs, upgrades, and automatic updates for every app, and scales to multiple connectors without repeating manual setup.
Orchestrator mode (recommended)
You deploy the SDR Orchestrator once. After that, every connector app is installed, upgraded, and automatically updated from the Atlan UI—no per-app terminal work. The orchestrator handles credential provisioning, health checks, and lifecycle management for each app it manages.
See SDR Orchestrator for the detailed reference, including what SDR handles automatically for every app.
Single-app mode
You own the full lifecycle of each app. Every connector is a separate deployment unit that you install, upgrade, and stop yourself using docker compose or helm install. This mode fits environments that require full manual control or where app versions and rollouts must be managed through existing IaC or GitOps pipelines.
See Single-App Deployment for the detailed reference.
Side-by-side comparison
| Aspect | Orchestrator mode (recommended) | Single-app mode |
|---|---|---|
| Lifecycle owner | SDR Orchestrator | You |
| Per-app setup | One bootstrap; apps deployed from Atlan UI | Manual (compose/helm) for every app |
| Install | One docker compose up or helm install for the orchestrator | docker compose up / helm install per app |
| Upgrade | Triggered from Atlan UI; orchestrator handles | Pull new image, redeploy per app |
| Self-update | Orchestrator updates itself (blue-green on Docker, rolling on Kubernetes) | Not applicable—you control the version |
| Credential provisioning | Automatic—shared OAuth credentials, orchestrator provisions per app | Manual OAuth per app |
| Terminal access after install | No—UI-driven | Yes, for every app |
| Best for | Multi-app deployments, automated lifecycle, minimizing ops overhead | Single-app evaluations, full manual control, existing IaC/GitOps |
| Platforms | Docker/Podman VM, Kubernetes | Docker Compose, Kubernetes |
Which mode to choose?
Start with orchestrator mode. It's the recommended default: one bootstrap, UI-driven installs and upgrades for every app, automatic credential provisioning, and self-updates. If you're deploying more than one connector or want to minimize ops overhead, this is the path.
Choose single-app mode only if you have a specific constraint: evaluating a single connector with the fewest moving parts, requiring app versions to be pinned and rolled out through existing IaC or GitOps pipelines, or needing version-by-version manual control.
You can start in single-app mode and move to orchestrator mode later—both modes use the same app images and core architecture.
See also
- SDR Orchestrator: Reference for the recommended automated lifecycle mode.
- Single-App Deployment: Reference for the per-app deployment pattern.
- Core Architecture: Shared architecture for both modes.
- Deployment options: Platform choices (Docker Compose, Kubernetes) across both modes.