# Deploying to Many Customers with Tenants Source: https://www.jawsdeploy.net/guides/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. 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. > **// What a tenant is - Release 1.4 to Production for Acme** > > A tenant is one of your customers (or a site or region) that gets its own copy of a project. Each tenant has its own variable values, can have its own machines, and has its own deployment history. A deployment can be for a tenant or, if the project allows it, for no tenant. ## 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: ## The project's Tenants setting **Off** Deployments are never for a tenant. The project works exactly as before. **Allowed** A deployment can be for a tenant or for no tenant. **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. ## 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 ## 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} ``` > **// No new release needed - Tenant values are read when a deployment is created** > > A release snapshots the project's variables, but not tenant values. They are read when the deployment is created, so onboarding a customer or changing one customer's password doesn't need a new release that goes through every environment again. A tenant with a required value missing can't be deployed - the screens show what is missing, for example *Missing: DbName*. ## 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. > **// Lifecycle - Each tenant moves through the lifecycle on its own** > > A tenant can go to the next phase once it has finished the earlier one, whatever the other tenants have done. Acme can be in Production while Globex is still testing. Automatic environments deploy each tenant as soon as it is ready. ## 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](https://www.jawsdeploy.net/pricing). - **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 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](https://www.jawsdeploy.net/guides/environments-and-targets), [Variable Resolution Rules](https://www.jawsdeploy.net/guides/variable-resolution-rules) and [Release Progression with Lifecycles](https://www.jawsdeploy.net/guides/release-progression-with-lifecycles).