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 walks through the setup, and the feature page 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 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 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.

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.

Highlights

  • Tenants - deploy one release to each of your customers from one project, each with its own settings, machines and deployment history.
  • Tenant variables - per-customer values, for all environments or per environment, read when a deployment is created.
  • Machines and cloud targets for tenants - dedicate them to tenants by name or tag.
  • Deploy to many tenants - one deployment per tenant, with tenants that can't go listed with the reason.
  • Tenant grids on the release page and the project overview, and tenant filters for deployments in the UI, REST API and MCP.
  • Turn customer environments into tenants - copy a workspace into a new one with tenants; the original is left unchanged.
  • Move machines to another workspace without setting the agent up again.
  • Delete a workspace, for organization admins.
  • Changed - one searchable picker for choosing many items, and MCP tools say whether they read or change something.