## App management

URL: https://docs.atlan.com/product/connections/self-deployed-runtime/concepts/app-management

> Understand how Self-Deployed Runtime app deployments work and their relationship to connector types, data sources, and workflows.

:::info **Did you know?** 
SDR requires additional enablement and licensing. Contact your Atlan representative for details.
:::

App management in Self-Deployed Runtime defines how applications are deployed, connected to data sources, and organized through workflows. The architecture balances operational simplicity—you deploy once per source system type—with granular control over individual data sources through independent workflows. Understanding these relationships helps you design scalable deployments and minimize operational overhead.

## Core mental model

Self-Deployed Runtime uses four core elements that work together in specific cardinality relationships:

 A containerized application instance that handles one source system type, with DAPR integrated as an internal layer for service communication and state management

 A category of external systems sharing the same data extraction patterns—examples include relational databases (PostgreSQL, MySQL), data warehouses (Snowflake, Redshift), or object storage (S3, GCS)

 A specific instance of a source system type—for example, a particular PostgreSQL server, a Snowflake account, or an S3 bucket—that your app connects to and extracts metadata from

 A configuration in Atlan UI that defines metadata extraction tasks, schedules, and parameters for a specific data source or resource within it

## Cardinality relationships

The four elements follow a hierarchical flow where each level can scale to the next, subject to network connectivity constraints:

```mermaid
graph LR
 A[Source System Type] -->|1:1| B[App Deployment]
 B -->|1:many| C[Data Source]
 C -->|1:1| D[Workflow]

 style A fill:#E8EAF6,stroke:#5752D7
 style B fill:#FFE0B2,stroke:#FB923C
 style C fill:#BBDEFB,stroke:#0047BB
 style D fill:#C8E6C9,stroke:#2E7D32
```

Each app deployment can connect to multiple data sources only if your infrastructure topology, firewall rules, and network routing enable the deployment to reach all target systems.

## Workflow to data source mapping

At the final level, each data source requires its own workflow configuration. This 1:1 relationship ensures you have independent control over extraction settings, schedules, and monitoring for each resource.

To understand how this works in practice, consider these scenarios:

**Example 1: Multiple databases on one PostgreSQL server**

If your infrastructure has a PostgreSQL server hosting multiple databases (analytics and reporting), you create a separate workflow for each:

```mermaid
graph LR
 A["analytics_db"] -->|1:1| B["analytics_db Workflow"]
 C["reporting_db"] -->|1:1| D["reporting_db Workflow"]

 style A fill:#BBDEFB,stroke:#0047BB
 style C fill:#BBDEFB,stroke:#0047BB
 style B fill:#C8E6C9,stroke:#2E7D32
 style D fill:#C8E6C9,stroke:#2E7D32
```

This independent workflow configuration enables different schedules and extraction rules for each database.

**Example 2: Single database on another PostgreSQL server**

A different PostgreSQL server might contain only one database requiring metadata extraction:

```mermaid
graph LR
 A["staging_db"] -->|1:1| B["staging_db Workflow"]

 style A fill:#BBDEFB,stroke:#0047BB
 style B fill:#C8E6C9,stroke:#2E7D32
```

The number of workflows varies based on your environment's structure—not all systems have identical layouts.

**Example 3: S3 organized by logical groupings**

S3 storage can be logically organized by different prefixes or buckets. Each grouping becomes a data source with its own workflow:

```mermaid
graph LR
 A["backups"] -->|1:1| B["backups Workflow"]
 C["logs"] -->|1:1| D["logs Workflow"]

 style A fill:#BBDEFB,stroke:#0047BB
 style C fill:#BBDEFB,stroke:#0047BB
 style B fill:#C8E6C9,stroke:#2E7D32
 style D fill:#C8E6C9,stroke:#2E7D32
```

This same 1:1 pattern applies consistently across all system types. Each workflow is independently managed, scheduled, and monitored, enabling you to configure different extraction frequencies, transformation rules, and error handling policies for each data source.

## See also

- [Deployment options](https://docs.atlan.com/llms/platform/self-deployed-runtime/deployment-options/llms.txt): Learn about different deployment approaches for app management
- [Authentication](https://docs.atlan.com/llms/platform/self-deployed-runtime/authentication/llms.txt): Understand how app deployments authenticate with Atlan
- [Secret management](https://docs.atlan.com/llms/platform/self-deployed-runtime/secret-management/llms.txt): Learn how database credentials are securely managed

---