Deploying to Many Sites

You have built one system — firmware, dashboards, SCADA screens, workflows — and now you want to install it again and again: at every customer, at every site, perhaps under a partner's brand. This page is the recommended way to set that up with workspaces and tenants so that each new site is configuration, not engineering, and every improvement reaches every site.

The short version:

1. Decide what a tenant is — usually one per site.
2. Make the design site-agnostic — everything that differs between sites becomes a variable.
3. Keep design and production apart — build in one workspace, ship to another as a versioned bundle.
4. Onboard each site with the same checklist.
5. Release updates through the bundle, and firmware group by group.
6. Brand the production workspace, or give each reselling partner their own.

1. Decide what a tenant is

A tenant is a privacy boundary: a set of devices, settings and people that can see each other and nothing else. Variables are filled in per tenant, so a tenant is also the unit of configuration. Pick the boundary before you onboard anyone, because devices cannot move between tenants later.

Your situation	Recommended layout
Each customer has one site	One tenant per customer
A customer has several sites, each run by its own staff	One tenant per site, named Customer – Site
A customer has several sites and head-office staff who must see all of them	One tenant per customer, one device group per site

One tenant per site is the default to aim for: every site gets its own variables (site name, alarm contacts, limits), and site staff see only their own equipment.

Customer logins see one tenant

Tenants are flat — there is no tenant-of-tenants. A customer login that is not a workspace member is placed in a tenant on sign-in and cannot switch, even if it was invited to several. If one person at the customer needs every site, put those sites in one tenant and separate them with device groups instead.

2. Make the design site-agnostic

The test of a resellable design: you can create a fresh tenant, fill in its variables, add a device, and everything works without opening the Designer. If any step needs an engineer, something site-specific has leaked into the design.

What differs	Where it belongs	Example
Per site — names, contacts, thresholds, local endpoints	Tenant variable template	{{tenant.variables.ALARM_EMAIL}}
The same everywhere, especially secrets	Workspace variable	{{workspace.variables.SMS_API_KEY}}
Per device, stored on the device	Device settings, pushed per device group	calibration offset, setpoint
Behaviour of the product	The design itself — one version for everyone	the alarm logic

When building workflows:

• Trigger on Any Device rather than a Specific Device or Device Group. A device trigger started by a site's device already runs with that site's variables and can reach only that site's devices — see How one design serves every tenant.
• In Device Action nodes, act on {{ data.device.deviceId }} instead of a device picked from a list. A picked device belongs to one site.
• Put the recipient, the threshold and the site name in tenant variables, not in the node.

Resist building a second firmware for a customer who wants something slightly different. If it can be a setting or a variable, make it one; every extra firmware is another thing to update at every site.

3. Keep design and production apart

Workspace content is live: edit a dashboard and every tenant sees the edit immediately. That's what makes updates cheap, and also what makes it risky to design in the workspace your customers use. Use two workspaces:

	Design workspace	Production workspace
Holds	The application, dashboards, SCADA screens, workflows	The same, imported from the design workspace
Tenants	One or two test tenants with made-up sites	One per real site
Devices	Your bench and test devices	Customer devices only
People	Engineers as members	Support staff as operators; customers in their tenants
Changes	Made here	Arrive only as a bundle

Ship the first version

1. In the design workspace, open Workspace Settings → Import / Export and click Export Workspace. You get a JSON bundle with the applications, firmware snapshots, device groups, workflows, dashboards and SCADA screens, plus the tenant variable templates. Workspace variable values are replaced with placeholders.
2. In any workspace, click Import Workspace Project, choose the bundle and pick Create a new workspace. Name it for production — you are its owner.
3. In the new workspace, replace the placeholders under Workspace Settings → Variables with the real values.

Ship an update

1. Test the change in the design workspace against a test tenant.
2. Export the design workspace again.
3. In the production workspace, import the new bundle and choose Update existing items in current workspace from bundle.

Items that came from the bundle are replaced with the new version, new items are added, and items you deleted in the design workspace stay unless you tick Remove items no longer in the bundle. Tenants, devices, variable values and people are never touched. Each import is recorded in the audit log, item by item.

What an update does not carry

• New tenant variable templates. Templates travel only when a bundle creates a new workspace. If the release uses a new key, add the template in production — and fill it in for every tenant — before you import.
• New workspace variables. Add them in production by hand, the same way.

Updating is only offered when the production workspace was itself imported from a bundle of the same design workspace. To label releases with a version number, export through the API with bundleVersion set (POST /api/workspace-projects/export); the version is then shown at the top of the Import / Export page.

4. Onboard a site

The same checklist every time. The Setting up a customer walkthrough shows each step on screen.

1. Create the tenant in the production workspace, under Settings → Tenants. Name it so your support team can find it: Customer – Site.
2. Select the tenant in the sidebar. Everything you create next is assigned to it, permanently.
3. Create the site's device groups inside the tenant, running the current release of your application.
4. Add the devices to those groups — or leave this to the customer.
5. Fill in the tenant variables, or leave them to the customer's admin.
6. Invite the customer's admin into the tenant only, never into the workspace.
7. Check the site as the customer sees it: with the tenant still selected, open the dashboards and SCADA screens and trigger a test alarm.

Keep customer devices out of bundle groups

Device groups that came in a bundle are replaced on every update, including the firmware version they run. Use them as templates at most; create each site's own groups inside its tenant, as in step 3.

5. Roll out firmware

A firmware snapshot built in the design workspace travels in the bundle with its binary, so after an update the new version is available in production. Devices don't move to it until you assign it.

Over-the-air updates go group by group, which is what makes a staged rollout possible:

1. Assign the new version to one pilot site's group — ideally a customer who has agreed to go first.
2. Watch it for a few days: connection state, logs, alarms.
3. Assign it to the remaining sites' groups.

To roll back, assign the previous version to the group again. Updating a whole group at once requires the Pro or Business plan.

6. White labelling

Each workspace has one logo, uploaded under Workspace Settings → General. It replaces the AppBlocks logo at the top of the sidebar for everyone in the workspace, customers included. PNG, JPEG, WebP or SVG, up to 200 KB; available on the Pro and Business plans.

The logo is the only branding setting, and it belongs to the workspace, not the tenant. So branding follows workspaces:

• Selling under your own brand — put your logo on the production workspace. Every customer sees your brand.
• Partners reselling under their brand — give each partner a workspace of their own, created from the same bundle and carrying the partner's logo. The partner's sites become tenants there.

For partner workspaces, keep the ownership and the design with yourself: you own the workspace and apply the bundle updates, while the partner's staff are operators who create tenants, onboard sites and support their customers. Everyone stays on the same release, and no partner can drift from the design.

The device's own web console is part of the firmware. If a partner needs their brand on the device itself, that is a firmware difference: build it as a separate snapshot and roll it out only to that partner's groups.

Plans

Tenants, logos and group updates are paid features. Check the pricing page for current limits.

You need	Available on
Tenants	Pro (limited number) and Business (unlimited)
Devices across all sites	Every plan, up to the plan's device limit per workspace
Workspace logo	Pro and Business
Firmware update for a whole device group	Pro and Business
Audit logs, including the record of each bundle import	Business

Limits and features follow the plan of the workspace's owner, and tenants and devices are counted per workspace. Whoever owns the production and partner workspaces needs the plan that covers them.

Checklist

• Every site-specific value is a tenant variable; nothing site-specific is typed into a dashboard or workflow
• Workflows trigger on Any Device and act on the triggering device
• Design and production are separate workspaces; production changes only by bundle
• New variable templates are added in production before the release that uses them
• One tenant per site (or per customer, with a group per site), named Customer – Site
• Customer devices sit in groups created inside their tenant
• Firmware goes to a pilot group first
• Customers are invited into their tenant only; your staff are operators

See Also

• Workspaces & Tenants — the model this page builds on
• Roles & Permissions — who can do what
• Workflows — triggers and device actions
• Settings — per-device configuration in firmware