# Environments and contexts

Keep a sandbox tenant that serves no customer, reach customers through rollouts, and keep one CLI context per Tanomis environment.

On Tanomis your customers are tenants, so "environments" means something specific: a **sandbox
tenant** that serves no customer, where developers and the pipeline test, and the customer tenants
that a version reaches through a rollout. On your machine, a CLI **context** names which Tanomis
environment you talk to and holds its login.

- One **sandbox tenant** for testing. Agents, sessions, files, connectors, and policy do not cross
  tenants, so nothing you do there touches a customer.
- Customers are reached by **enabling the same version** for them, a few at a time. Nothing is
  rebuilt.
- One **context** per Tanomis environment on your machine, each with its own login and selected
  workspace.

## The sandbox tenant and the customer tenants

| Tenant | Who deploys | Typical policy |
|---|---|---|
| `northwind-sandbox` | Developers, from their laptops and pull requests | Wider model allowlist, broad egress ceiling, approvals off for speed |
| `bluewater-bank`, `orion-retail`, … | The pipeline or an owner, through a rollout | Each customer's own ceilings, approvals on consequential tools |

A tenant's ceilings narrow what a version's manifest declared, so the same version can be admitted
in the sandbox and refused for a customer if its egress list exceeds that customer's ceiling. You
find out at deploy time, with the entry and the ceiling named. Ask your platform operator to
provision the sandbox tenant; see [Customer tenants](/guides/manage/tenants-and-environments).

## Contexts on your machine

A context is local configuration: which API environment, which authentication mode, and the login
state for it. Most people have one, `saas`, created by `tanomis login`. Add another only for a
different Tanomis environment, not for a different tenant.

```bash title="Terminal"
tanomis login --console https://api.tanomis.com --name saas
tanomis config current-context
tanomis config use-context staging
tanomis config view
```

Workspace selection is stored per context. Switching context can change the API environment, the
cached login, and the selected workspace at once, so check `tanomis workspace show` before a
consequential command.

## Switch tenants, not contexts

Within one Tanomis environment, moving from the sandbox to a customer is a workspace change:

```bash title="Terminal"
tanomis workspace use northwind --tenant northwind-sandbox
tanomis agent deploy ./agents/support-copilot --tenant northwind-sandbox

tanomis workspace use northwind --tenant bluewater-bank
tanomis agent rollout support-copilot --version 0.4.0 --tenants bluewater-bank --canary-share 10
```

Deploy and session-run commands refuse a `--tenant` that differs from the selected workspace, so a
stale selection fails loudly instead of deploying to the wrong customer.

## From the sandbox to every customer

Because a version is immutable, reaching customers is enablement, not a rebuild:

1. Deploy to the sandbox. Test with `tanomis session run` and from your application.
2. Run the evaluation gate against the version customers are on.
3. Canary for one or two customers, graduate to the rest, and keep the previous version
   deprecated for rollback.

See [Roll out and roll back](/guides/deploy/rollout-and-rollback) for the customer step and
[Deploy from CI](/guides/deploy/deploy-from-ci) for the pipeline shape.

## Where to go next

- [Organizations and tenants](/concepts/organizations-and-tenants): how tenants are attached and
  granted.
- [CLI configuration](/reference/cli-configuration): the config file, contexts, and environment
  variables.