> 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/architecture.md).
# Architecture
DataOS follows the Control Plane–Data Plane architecture pattern, where the DataOS Instance acts as the Control Plane.
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 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 the following layers:
* **Namespace:** resources are scoped to the Tenant's Kubernetes namespace and do not resolve across Tenant boundaries
* **Data source connections:** Secrets and Depots are Tenant-scoped and carry no implicit inheritance to other Tenants. A Tenant that finds a dataset in the catalog cannot read it without its own Depot and Secret for that source
* **Access:** policies and role grants apply only within the Tenant where they are defined
### Dataset visibility
Ingested dataset metadata is visible across all Tenants on the DataOS Instance. For example, when a Tenant ingests metadata from an external data source, the resulting dataset metadata is available to users in other Tenants. This allows users to discover datasets across the Instance without granting them access to the underlying data.
Access to the data remains Tenant-scoped. A user must have the required Depot, Secret, and applicable access policies within their own Tenant to access a dataset. Workloads and Data Products also remain within the Tenant where they are created.
This means that dataset metadata is discoverable across the Instance, while data access, workloads, and Data Products remain isolated by Tenant.
---
# 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 by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://v2.dataos.info/operate/architecture.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.
