Tenants

One project, one set of environments, and a tenant for each customer, site or region - each with its own settings, machines and deployment history.

Search guides... Ctrl K

Plenty of teams run the same software for many customers: a hosted product with one instance per client, a line-of-business app installed at each site, or a service run separately in each region. Each copy has its own database, URL, licence key and servers, but the deployment process is the same.

Without tenants there are two usual ways to model that in Jaws, and both get harder with every customer:

  • A project per customer. Every change to the deployment process has to be made in each copy, and the copies drift apart.
  • An environment per customer - Customer1-Prod, Customer2-Prod, Customer1-Test. The lifecycle, the variable scoping and the release page grow with every customer you add.

Tenants keep one project and one set of environments. Each customer is added as a tenant, and Jaws deploys the same release to each of them - with that tenant's own settings, on that tenant's own machines, with its own deployment history.

1. Create tenants

Open the Tenants page and click Add new tenant. Give it a name and, optionally, tags - for example eu or canary. Tags let you pick many tenants at once later: when connecting them to a project, when choosing which tenants a machine serves, and when deploying.

2. Use tenants in a project

In the project, open Settings and choose how the project uses tenants:

01 - the default

Off

Deployments are never for a tenant. The project works exactly as before.

02

Allowed

A deployment can be for a tenant or for no tenant.

03

Required

Every deployment must be for a tenant.

Then open the project's Tenants tab and click Connect tenants. Pick the tenants (or a tag) and the environments they use. A tenant can use only some of the project's environments - for example Prod EU but not Prod US.

3. Give each tenant its own settings

Open the project's Tenant variables tab and click Add tenant variable. Give it a name, an optional default, and choose whether every tenant must have a value (Required - every tenant must have a value (or the default is used)).

Fill in the values on the project's Tenants tab, or on each tenant's page. A value can be for All environments or for one environment. Secret values stay encrypted.

// Which value is used

From most to least specific

  • The tenant's value for the deployment's environment
  • The tenant's value for All environments
  • The tenant variable's default
// In scripts and step properties

Read a tenant value like any other variable

Tenant values sit next to the project's variables, so you reference them the same way. A deployment for a tenant also gets the tenant's name, ID and tags as context values.

# a tenant variable called DbName
#{VAR.DbName}

# only defined when the deployment is for a tenant
#{CONTEXT.Tenant.Name}
#{CONTEXT.Tenant.Id}
#{CONTEXT.Tenant.Tags}

4. Dedicate machines and cloud targets to tenants

In a machine's (or cloud target's) Tenants section, set Tenant deployments:

Tenant deployments

  • Not used for tenants (default) - only deployments without a tenant use it.
  • Only for tenants - only deployments for a tenant use it.
  • For tenants and non-tenant deployments - both.

Then choose which tenants it serves: by name, or with Tenant tags (any tenant with one of these tags) - for example every tenant tagged eu. A deployment for a tenant uses only the machines meant for that tenant. If no machine matches a step, the step is skipped.

5. Deploy

On the release page of a project that uses tenants, a grid shows each tenant's progress per environment. You can deploy three ways:

  • Click Deploy in a cell to deploy one tenant to one environment.
  • Tick several tenants and use Deploy to selected.
  • Use the lightning icon on a phase.

On the Deploy screen, the Tenants box picks one or many tenants - filter by name or tag, then Select all shown. Jaws creates one deployment per tenant and environment, and each tenant only gets the chosen environments it uses. Tenants that can't go yet are listed with the reason, and Show the plan for previews the steps for any one of them.

// Seeing what's deployed where

Where to look

  • Project → Overview - a grid with a row per tenant and a column per environment, showing the latest deployment (version and status) in each cell. Turn on Group by channels for one grid per channel.
  • Project → Deployments and the dashboard - filter by tenants (All tenants) and by tag (All tenant tags).
  • REST API and MCP - list deployments with tenantIds, tenantTag and includeNoTenant.

Plans and limits

  • Professional includes 10 tenants, then €2 per tenant per month. Fleet includes 50, then €1 each. Dedicated has no limit. See pricing.
  • Starter has no tenants. The 14-day Professional trial includes them.
  • Only active tenants count. Archive a tenant you no longer deploy to: it keeps its history and can be restored when you have a free slot. Deleting a tenant can't be undone.
  • Over the limit? If you have more active tenants than your plan allows - for example after a downgrade - deployments stop until you archive some or add tenants to your plan, the same as for machines and projects.

Related reading: Environments and Targets, Variable Resolution Rules and Release Progression with Lifecycles.