Skip to main content

App management

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:

📦

App deployment

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

🔌

Source system type

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)

💾

Data source

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

⚙️

Workflow

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:

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:

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:

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:

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​