Environments and contexts

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.

At a glance

• 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.

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.

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:

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 for the customer step and Deploy from CI for the pipeline shape.

Where to go next

• Organizations and tenants: how tenants are attached and granted.
• CLI configuration: the config file, contexts, and environment variables.