# Tenants: deploy one release to every customer Source: https://www.jawsdeploy.net/changelog/tenants Add each customer as a tenant with its own settings, machines and deployment history - and turn customer environments you already have into tenants. ## Tenants If you run the same software for many customers, sites or regions, you no longer need a project or an environment per customer. Add each customer as a **tenant**, and Jaws deploys the same release to all of them - each with its own settings, its own machines and its own deployment history. A deployment becomes "release 1.4 to Production for Acme". The [tenants guide](https://www.jawsdeploy.net/guides/tenants) walks through the setup, and the [feature page](https://www.jawsdeploy.net/features/tenants) has the overview. ### Tenants and projects Create tenants on the new **Tenants** page, with tags such as `eu` or `canary` to pick many at once. A project's **Tenants** setting is *Off* (the default, so existing projects don't change), *Allowed* or *Required*. On the project's **Tenants** tab, connect tenants and choose which of the project's environments each one uses. ### Tenant variables A project's **Tenant variables** tab defines values that differ per customer - a database name, a URL, a licence key - with an optional default. Each tenant fills them in for all environments or per environment, and secrets stay encrypted. Scripts and step properties read them like any other variable, `#{VAR.DbName}`, and a deployment for a tenant also gets `#{CONTEXT.Tenant.Name}`, `#{CONTEXT.Tenant.Id}` and `#{CONTEXT.Tenant.Tags}`. Tenant values are read when a deployment is created, not stored in the release, so changing one doesn't need a new release. A tenant with a required value missing can't be deployed. ### Machines and cloud targets A machine's or cloud target's **Tenant deployments** setting is *Not used for tenants* (the default), *Only for tenants*, or *For tenants and non-tenant deployments*, and it serves the tenants you pick by name or by tag. A deployment for a tenant only goes to the machines meant for it. ### Deploying The release page of a project that uses tenants is a grid: a row per tenant, a column per environment. Deploy from a cell, tick several tenants and use **Deploy to selected**, or deploy a whole phase. On the Deploy screen, pick tenants by name or tag; Jaws creates one deployment per tenant, gives each one only the chosen environments it uses, and lists the tenants that can't go yet with the reason. **Show the plan for** previews the steps for any one of them. Each tenant moves through the lifecycle on its own, and automatic environments deploy each tenant as soon as it is ready. ### Seeing what's deployed where The project overview has the same tenant-by-environment grid, with **Group by channels** for one grid per channel. Deployment lists and the dashboard filter by tenant and by tenant tag, and so does listing deployments over the REST API and MCP (`tenantIds`, `tenantTag`, `includeNoTenant`). ### REST API and MCP Tenants, their project connections and tenant variables have REST endpoints under `/api/tenant` and `/api/project`. AI assistants connected through [MCP](https://www.jawsdeploy.net/features/mcp) get tools to create, update, archive and restore tenants (`create_tenant`, `update_tenant`, `archive_tenant`, `restore_tenant`), connect them to projects (`connect_tenants_to_project`, `update_tenant_project_environments`), manage tenant variables (`create_tenant_variable_template`, `set_tenant_variables`), and dedicate machines and cloud targets to tenants (`set_machine_tenants`, `set_cloud_target_tenants`). `preview_deploy` and `trigger_deploy` take a tenant. ### Plans Professional includes 10 tenants, then €2 per tenant per month. Fleet includes 50, then €1 each, and Dedicated has no limit. Starter has no tenants; the [14-day Professional trial](https://app.jawsdeploy.net/signup?return_url=%2Fsubscribe%2Fpremium%2Fmonth) includes them. Only active tenants count: archive the ones you no longer deploy to. Over the limit, deployments stop until you archive tenants or add them to your plan - the same as for machines and projects. See [pricing](https://www.jawsdeploy.net/pricing). ## Turn customer environments into tenants If you modelled customers as environments - `Customer1-Prod`, `Customer2-Prod`, `Customer1-Test` - organization admins can now convert them. In the workspace settings, **Customers as tenants** → **Copy to a new workspace with tenants** copies the workspace into a new one where each customer is a tenant and they share one `Prod`. - **Your workspace isn't changed.** Everything is copied into a new workspace, so the old one keeps deploying until you switch over. To start again, delete the copy and run it again. - **Map, then preview.** Pick the customer environments and a naming pattern (`{tenant}-{environment}` by default); Jaws suggests the tenant and new environment for each one, and you can edit every row. The preview shows what the new workspace will contain and lists anything that must be fixed first. Nothing is saved until **Create workspace**. - **Variables become tenant variables.** A project variable with values scoped only to customer environments becomes a tenant variable, with each customer's value moved to its tenant. Secrets are copied still encrypted. - **Not copied:** releases, deployments and their logs, and packages in the built-in feed. Machines are moved, not copied (below). - **Plan limits for 30 days.** The old workspace is marked as being replaced, and for 30 days its projects and cloud targets don't count towards your plan, so both workspaces keep deploying while you switch over. New tenants must fit your plan from the start. ## Move machines to another workspace Organization admins can move machines between workspaces from the **Machines** page (**Move machines**, or **Move to another workspace** in a machine's menu). Environments and tags belong to a workspace, so you pick them again for the target; after a conversion they are filled in for you. The agent keeps working without being set up again, and moving a machine back is just another move. Before you move, Jaws lists the steps and variable values that will stop matching the machine. A machine that is running a deployment can't be moved. ## Delete a workspace Organization admins can now delete a workspace from its settings (**Danger zone** → **Delete workspace**), except the organization's last one. Everything in it is deleted with it, including its machines. It can't be undone, so you type the workspace name to confirm, and it is refused while any deployment in that workspace hasn't finished. ## Changed ### One picker for choosing many items Screens that let you pick several environments, machines, tags, tenants or projects now use one searchable picker in place of Ctrl+click lists. ### MCP Every MCP tool now has a title and says whether it only reads or changes something, so AI clients can label the tools and treat the two kinds differently. The MCP server also rejects requests sent from an untrusted web page.