> 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/core-concepts/tenant.md). # Tenant A **Tenant** is an isolated workspace inside a DataOS Instance. It gives a team or project a scoped environment to manage users, create and run resources, and connect to data sources without touching the resources of any other Tenant on the same Instance. Multiple Tenants share a single Instance but stay operationally separate. A user in one Tenant cannot see, modify, or consume resources in another Tenant unless they hold explicit cross-Tenant access. *** ### Tenant and Dataplane Every Tenant runs on a **Dataplane**. The Dataplane is the execution layer that provides the Kubernetes cluster where all workloads (Services, Workflows, Workers, Stacks) run. In the current DataOS deployment model, **one Dataplane is shared across all Tenants on an Instance**. Each Tenant attaches to the same Dataplane and draws Compute resources from it. This keeps infrastructure costs low and simplifies operations while preserving resource-level isolation between Tenants. ``` DataOS Instance └── Dataplane (shared) ├── Tenant A ── Compute A ── Resources (Secrets, Depots, Stacks, Workflows …) ├── Tenant B ── Compute B ── Resources (Secrets, Depots, Stacks, Workflows …) └── Tenant C ── Compute C ── Resources (Secrets, Depots, Stacks, Workflows …) ``` {% hint style="info" %} The Dataplane is created once at the Instance level. Operators do not create a separate Dataplane per Tenant. {% endhint %} *** ### What a Tenant contains Once a Tenant is provisioned and a Compute is attached, you can create and manage these resources in it: | Resource category | Examples | | ----------------- | ---------------------------- | | Credentials | Secrets | | Data connections | Depots | | Execution stacks | Vulcan, Nilus, custom Stacks | | Workloads | Workflows, Workers, Services | | Storage | Lakehouses | | Query layer | Minerva clusters | | Data products | Vulcan-powered Data Products | {% hint style="info" %} All resources in a Tenant are namespace-scoped. A resource named `postgres-cred` in Tenant A is a different object from `postgres-cred` in Tenant B even if the YAML is identical. {% endhint %} *** ### Compute within a Tenant A Tenant does not own the Dataplane. It owns one or more **Compute** resources that represent node pools within that shared Dataplane. Each Compute points to a set of Kubernetes nodes identified by `nodeSelector` labels. Workloads reference a Compute by name, and the platform schedules them on matching nodes. A Tenant can have multiple Computes: one for standard data pipelines, another for GPU-intensive workloads. The Operator provisions and attaches Computes during Tenant setup. ```yaml # Workload referencing a Compute spec: compute: ``` *** ### Resource isolation Tenant-level isolation works at three layers: * **Namespace isolation**: Every resource applied inside a Tenant lives in a Kubernetes namespace that belongs only to that Tenant. Platform components resolve resource names within the Tenant boundary. * **Credential isolation**: Secrets are Tenant-scoped. A Depot in Tenant A that references `postgres-cred` only resolves that name if the Secret exists in Tenant A. There is no implicit inheritance across Tenants. * **Access isolation**: Policies and Grants are Tenant-scoped. A user with the Developer role in Tenant A holds no permissions in Tenant B unless explicitly granted. *** ### Roles in a Tenant Two primary roles operate within a Tenant: | Role | Responsibilities | | ------------ | --------------------------------------------------------------------------------------------------------------------------- | | Tenant Admin | Provisions platform resources (Stacks, Secrets, Depots), manages user access, attaches Compute, and monitors Tenant health. | | Developer | Creates and operates Data Products within the Tenant. | The **Operator** role sits above the Tenant level. An Operator creates Tenants, provisions the Dataplane and Computes, and holds unrestricted access to the Instance. Tenant Admins and Developers cannot create or modify Tenants. *** ### Tenant lifecycle The Operator Journey has three phases. A Tenant moves through all three before it is ready for developer use. ``` Phase 1: Deploy DataOS └── Provision Dataplane │ ▼ Phase 2: Setup Tenant └── Create Tenant, attach Dataplane and Compute │ ▼ Phase 3: Validate tenant readiness ├── Install Stacks (Vulcan, Nilus) and MCP ├── Apply data source Secrets and Depots └── Run sanity validation │ ▼ Tenant ready. Developers create workloads and data products. ``` A Tenant is ready for developer use when: * The Dataplane and at least one Compute are attached. * The Vulcan and Nilus Stacks are healthy. * At least one data source Secret and Depot are active. * The sanity data product deploys and runs without errors. For the step-by-step runbook, see the Operator Journey. *** ### Tenant-scoped resource naming Resources within the same Tenant reference each other by short name: ```yaml connectionSecret: - name: postgres-cred # resolved within the same Tenant ``` When a resource in one Tenant references a resource in another Tenant, or when a Stack references a Secret by fully qualified name, the format is: ``` : ``` For example: ```yaml secret: se-sandbox:dataproduct-mcp-secrets ``` *** --- # 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/core-concepts/tenant.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.