Skip to main content

Multi-Tenant Design

EmberNet is multi-tenant at every layer. Data, configuration, network identity, and access are separated between tenants by the platform itself rather than by convention. A tenant is one organization: a customer, a partner, or a business unit.

How isolation works​

Data​

Every device, site, alert, app, and audit record belongs to a tenant, and the server checks that ownership on every request. Asking for another tenant's data is refused, not quietly filtered, which is why hand-crafting a different tenant into an API call returns 403 instead of an empty result.

Network​

Tenant workloads carry their own network identities on Flux, and each tenant has its own ArcNet address range. Collectors that reach devices directly are held to the tenant's own recorded site subnets. Cross-tenant traffic is denied by default. See Zero-Trust Networking.

Messaging​

On AnvilMQ, each tenant's credentials reach only that tenant's topics.

Access​

People hold a role in each tenant separately, and a role in one tenant never raises what they can do in another. The tenant roles are Admin, Engineer, Operator, and Viewer, and each lands in an EmberCORE view built for it. How roles are granted is covered in SSO Integration.

RoleScopeWhat they do
Global CommandEvery tenantFireball's platform role: tenants, global configuration, cross-fleet oversight
AdminOwn tenantUsers, sites, devices, apps, storage, and network
EngineerOwn tenantDay-to-day monitoring and diagnostics, and deploying apps
OperatorOwn tenantLive status, device health, and alert acknowledgement
ViewerOwn tenantA read-only view of nodes and sites

Global Command is the only place aggregate, cross-tenant data is ever shown. Every other role is confined to its own tenant, and that confinement is enforced on the server rather than by hiding controls in the interface.

Tenant lifecycle​

Onboarding​

  1. Fireball creates the tenant and connects its sites and nodes.
  2. Fireball invites the first Admin.
  3. Admins invite their people and give each one a role, or Fireball maps their directory groups to roles.
  4. Devices are registered to the tenant, and collectors and SNMP are set up against them.

Enterprises bringing their own cluster follow a different path; see External Tenants.

What each tenant controls​

  • Its users and the role each one holds
  • Its sites, buildings, and devices
  • The apps it deploys, and which apps its catalog offers
  • Its device collectors and SNMP credentials
  • Whether its audit trail is also exported to its own storage

Retention of the audit log is a platform-level setting, kept for seven years by default. See Configuration Reference.

Leaving​

To remove a tenant, contact Fireball.

Operating many tenants​

Platform staff work from Global Command, where the Client Switcher is the single control for scope. Leave it on All Clients for the aggregate picture, or select a client to drill the entire console into that one tenant.

Day-to-day fleet work happens in Ops & Clusters, which covers cluster health and deployment status across everything you can see.

Scale​

New tenants are added without affecting existing ones, and edge clusters scale independently based on what each tenant's workload actually needs. A single control plane supports hundreds of tenants.

Next steps​