# Customer tenants

Create, inspect, retry, and offboard organization tenants from the Console or CLI.

A tenant is where agents run and their data stays. Your organization can own several customer tenants and a sandbox tenant for testing. Each tenant belongs to one organization.

## Create and inspect tenants

An organization owner or admin can open **Settings → Organization → Tenants** in the Console to
create a tenant and inspect its progress. The equivalent CLI commands use a human login:

```bash
tanomis org tenants create bluewater-bank
tanomis org tenants ls
tanomis org tenants get "$TENANT"
```

Use `--org ORGANIZATION` to choose an organization explicitly. Creation returns before provisioning
finishes. A tenant is usable when its status is `active` and its organization attachment state is
`ready`; inspect both with `tanomis org tenants get "$TENANT" -o json`. Provisioning can take several
minutes. Deployment policy controls the tenant limit and supported provisioning modes.

If provisioning fails, inspect the tenant and retry after the underlying issue is resolved:

```bash
tanomis org tenants retry "$TENANT"
```

## Grant access

Owners and admins see attached tenants. Developers and viewers need a tenant grant; see
[Organization members and access](/guides/manage/organization-members). Use `tanomis workspace ls`
to see the workspaces available to your human login.

Organization-owned [automation clients](/guides/deploy/automation-credentials) automatically reach
all active, ready tenants in the organization, including a newly created tenant as soon as it is
ready. They do not use per-tenant grants. A sandbox CI job's tenant selection is therefore
not a restriction on the underlying credential.

## The default tenant

The default tenant is granted to new members when they accept an invitation. It can also supply
a default selection when a tenant is omitted. An organization with no default auto-grants nothing.
Creating a tenant does not automatically make it the default. Changing the default or attaching
an existing deployment tenant remains an operator operation.

A self-hosted installation starts with a default organization. The operator configures the
installation and its initial access; owners and admins then use the same organization management
flow as hosted customers.

## Sandbox and customer tenants

Grant developers access to the sandbox and only the access they need in customer tenants. Set tenant
policy independently. With a tenant-owned automation deployment, deploy the reviewed source to
each tenant's own agent registration; do not assume a version owned by one tenant belongs to the
other. See [Deploy from CI](/guides/deploy/deploy-from-ci).

## Offboard a tenant

Offboarding immediately withdraws machine access and starts asynchronous resource cleanup. It is
irreversible. Review the tenant and preserve any data you need before confirming in the Console,
or supply its exact ID to the CLI:

```bash
tanomis org tenants offboard "$TENANT" --confirm "$TENANT"
```

Inspect the tenant until cleanup completes. The resources removed depend on the deployment's
provisioning mode. An automation client cannot create, retry, or offboard tenants; these operations
require a human owner or admin.

## Where to go next

- [Organizations and tenants](/concepts/organizations-and-tenants)
- [Tenant CLI reference](/cli/org/tenants)
- [Organization management API](/reference/organization-management-api)