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.

How isolation works​

Data​

Each tenant's data lives in logically separated partitions. Tenant A cannot reach Tenant B's telemetry, configuration, or user records, and backup and restore operations are scoped to a single tenant.

Network​

Tenant workloads carry their own network identities and certificates, their own routing policy, and their own service-discovery namespace. Cross-tenant traffic is denied by default at the policy layer. See Zero-Trust Networking.

Access​

Four roles, each landing in its own dashboard view:

RoleScopeWhat they can do
Global CommandEvery tenantManage tenants, global configuration, cross-fleet oversight
AdminOwn tenantManage users, sites, devices, apps, network, storage, and alerts
EngineerOwn tenantDay-to-day monitoring and diagnostics, read-mostly configuration
OperatorOwn tenantLive status, device health, and alert acknowledgement

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 in the data layer rather than by hiding controls in the interface. A request 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.

Roles are assigned through your identity provider's group claims. See SSO Integration.

Tenant lifecycle​

Provisioning​

  1. Create the tenant with a name, contact, and type
  2. Allocate resources: compute, storage, and network
  3. Bind directory groups so users resolve to the right roles and scope
  4. Enroll devices and assign them to the tenant

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

Configuration​

Each tenant configures independently:

  • Which metrics appear in the console and how they're drawn
  • Alert thresholds and notification channels
  • Device groups and tag hierarchies
  • Role assignments

Data retention is a platform-level setting rather than a per-tenant one. See Configuration Reference.

Decommissioning​

Removing a tenant purges its resources: data is deleted according to retention policy, network identities and certificates are revoked, device enrollments are removed, and user access is withdrawn.

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, resource allocation adjusts dynamically, and edge clusters scale independently based on what each tenant's workload actually needs. A single control plane supports hundreds of tenants.

Next steps​