> 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/tenant-admin/tenant-admin.md).

# Tenant Admin overview

The role that runs a Tenant day to day: resources, access, governance, and health.

A Tenant Admin runs a Tenant day to day. After an Operator creates the Tenant and hands it over, the Tenant Admin becomes responsible for making the Tenant usable for teams: setting up resources, managing access, and watching Tenant-level health.

## Tenant Admin vs Data Admin

Both are senior Tenant roles, but their responsibilities are different:

* **Tenant Admin** has administrative control over the Tenant's resources and users. If the task is *who can use this Compute or data source, or who belongs to this Tenant*, it is the Tenant Admin's responsibility.
* **Data Admin** has control over the Lakehouse, including its namespaces, schemas, tables, views, and data governance. If the task is *how Lakehouse data is structured or governed*, it is the [Data Admin's](/operate/data-admin/data-admin.md) responsibility.

## Your authority

Your authority is the Tenant boundary, and it is broad within it. You can:

* Invite users and assign Tenant roles.
* Create resources such as Compute, Secrets, and Depots.
* Grant or revoke access on any resource in the Tenant, including ones you did not create (useful when a creator leaves or is unavailable).

What you do **not** get by default is silent access to Compute, Depots, Minerva, or Secrets; like everyone else you self-grant `Can Use`, and that grant is audited. The [Access control](/operate/access-control/roles-and-permissions.md) explains why.

## What you cannot do

* **Act outside your Tenant:** Creating or deleting Tenants, attaching the Data Plane, or managing Instance-level setup is the [Operator](/operate/dataos-operator/operator.md)'s job. Your authority stops at the Tenant boundary.
* **Export data from DataOS applications, or manage metadata directly:** Both belong to the [Data Admin](/operate/data-admin/data-admin.md), not to you. Being the highest-privileged Tenant role does not mean you automatically inherit every capability the other roles hold.

## Day-to-day responsibilities

Your work falls into four recurring tasks, each with its own runbook:

* [Create compute](/operate/tenant-admin/create-compute.md): provision the node pools Data Product workloads run on.
* [Add data sources and secrets](/operate/tenant-admin/add-data-sources-and-secrets.md): connect the Tenant to external systems with Secrets and Depots.
* [Manage access](/operate/tenant-admin/governance.md): onboard users, grant developers `Can Use` on Compute and data sources, and set up the ApplicationUser and `runAsUser` mechanics.
* [Monitoring](/operate/tenant-admin/monitoring.md): watch the Tenant's Compute and resource health, and how to check it.

A good first pass after a Tenant is handed to you:

1. Confirm the Compute and data sources you were given.
2. Invite the rest of the team and assign roles.
3. Grant developers or the Roles they belong to the Can Use permissions they need to start building.

Start with [Create compute](/operate/tenant-admin/create-compute.md), or jump straight to [Manage access](/operate/tenant-admin/governance.md) if the resources are already in place and you are onboarding people.


---

# 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/tenant-admin/tenant-admin.md?ask=<question>&goal=<user_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.