> 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/readme.md).
# Architecture
DataOS Architecture
DataOS runs Data Products while keeping data inside the customer cloud. The architecture separates orchestration from execution across two planes.
## Two planes
* **Control Plane** — the centralized intelligence layer hosted in The Modern Data Cloud
* **Data Plane** — the execution layer hosted inside the customer cloud
The split is deliberate: platform intelligence lives centrally, while data and workload execution remain inside the customer's infrastructure boundary.
## Control Plane
The Control Plane provides the operational capabilities required to govern and coordinate Data Products across distributed environments. It operates independently from data execution.
The Control Plane exchanges only metadata, operational telemetry, policies, and execution instructions with the Data Plane. Customer data does not leave the customer environment.
### What the Control Plane 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 platform
* **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 Control Plane 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 at the Instance level 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/readme.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.