> For the complete documentation index, see [llms.txt](https://v2.dataos.info/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://v2.dataos.info/operate/v1/architecture.md). # Architecture
DataOS architecture diagram showing users and access on the left, the DataOS Instance as Control Plane in Modern Cloud, the Data Plane with Tenants and node pools in the customer environment, and connected storage and warehouses on the right

DataOS Architecture

DataOS uses a **Control Plane–Data Plane architecture** to separate DataOS management from workload execution. In DataOS, the **DataOS Instance** acts as the **Control Plane**, while the **Data Plane** executes workloads within the customer's cloud environment. This separation centralizes management while ensuring that customer data and workload execution remain within the customer's infrastructure boundary. ## Architecture overview The architecture consists of two logical components: * **DataOS Instance (Control Plane)**: the centralized management layer, responsible for orchestration, governance, metadata management, access control, observability, and and other DataOS services * **Data Plane**: the execution layer that runs Data Products, manages compute resources, connects to customer data sources, and executes workloads within the customer's cloud environment The DataOS Instance exchanges only metadata, policies, operational telemetry, and execution instructions with the Data Plane. Customer data never leaves the customer's environment. ## DataOS Instance The DataOS Instance serves as the Control Plane for DataOS. It governs, orchestrates, and monitors Data Products across one or more Data Planes without participating in data processing or workload execution. ### What the DataOS Instance provides * **Access control**: authentication, authorization, roles, and policies across Tenants and resources * **Data Product orchestration**: end-to-end coordination including definition, scheduling, execution handoff, and dependency management * **Metadata management**: centralized collection of schema, lineage, profiling, and operational context from Data Planes and connected systems * **Observability**: unified metrics, logs, alerts, telemetry, and runtime monitoring across the DataOS * **DataOS applications**: web-based interfaces for administration, exploration, governance, and Data Product management ## Data Plane The Data Plane runs entirely inside the customer cloud environment. It hosts the runtime infrastructure required to operate Data Products securely at scale. The Data Plane communicates with the DataOS Instance only to receive execution instructions and return operational telemetry. All data processing stays inside the customer boundary. ### What the Data Plane hosts * **Compute and workload execution**: runs pipelines, processing engines, and operational tasks on Kubernetes infrastructure inside the customer cloud * **Runtime services**: operates the Stacks (Vulcan, Nilus, and custom engines) that power Data Products within each Tenant * **Data source connectivity**: manages Depots and credential Secrets that connect workloads to storage and databases within the customer environment * **Workload isolation and scalability**: provides namespace-level resource boundaries and node pool allocation across Tenants through Compute resources ### Multi-tenancy Tenants are created on the DataOS Instance by an Operator. Each Tenant is a logically isolated workspace that attaches to the shared Data Plane for workload execution. In the current DataOS deployment model, **one Data Plane is shared across all Tenants on an Instance**. Each Tenant draws Compute resources from the same underlying Data Plane while maintaining strict isolation at three layers: * **Namespace**: resources are scoped to the Tenant's Kubernetes namespace and do not resolve across Tenant boundaries * **Credentials**: Secrets and Depots are Tenant-scoped and carry no implicit inheritance to other Tenants * **Access**: policies and role grants apply only within the Tenant where they are defined This isolation ensures that one Tenant cannot access another Tenant's data or workloads. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://v2.dataos.info/operate/v1/architecture.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.