Sendense Documentation

Provisioning Topologies

Choose a dedicated tenant appliance VM or single-tenant appliance stacks on a shared host. Both keep one tenant per appliance.

Documents Home

Concept

Provisioning Topologies

Choose a dedicated tenant appliance VM or single-tenant appliance stacks on a shared host. Both keep one tenant per appliance.

ReadyCurrentscacsptopologyprovisioningdensity

Overview

For CSP deployments, SCA (Sendense Central Appliance) can provision tenant appliances in two placement strategies. Both describe where a tenant's appliance runs, not how many tenants it serves.

Each appliance stays dedicated to a single tenant in both strategies. The choice between them is a cost-and-isolation trade the provider makes per tenant, and it never changes the tenancy model.

Placement, not tenancy

Both topologies are strictly one tenant per appliance. Selecting a topology decides only where a tenant's dedicated appliance is placed, never whether an appliance is shared.

Dedicated Appliance VM

Topology A places a dedicated appliance VM for each tenant — the tenant's own SHA (Sendense Hub Appliance) — deployed into that tenant's own cloud account.

Because nothing is shared between tenants at the appliance layer, this strategy gives the strongest isolation and confines any fault to a single tenant. It carries the highest per-tenant overhead, since every tenant runs a full appliance VM, and it is the best fit for larger tenants.

A dedicated appliance VM per tenant

SCA provisions and enrolls a separate appliance VM for each tenant, placed inside that tenant's own cloud account so tenants share nothing at the appliance layer.

A dedicated appliance VM per tenantPROVIDER CONTROL PLANETENANT A CLOUD ACCOUNTTENANT B CLOUD ACCOUNTPROVIDER PLATFORMSCACentral applianceONE TENANTTenant SHA VMDedicated applianceONE TENANTTenant SHA VMDedicated applianceProvision + enrollProvision + enroll
Each tenant gets a dedicated appliance VM in its own cloud account

Strongest isolation

Nothing is shared between tenants at the appliance layer, so a fault is confined to one tenant.

Best fit for larger tenants

A full appliance VM per tenant is the highest-overhead option and suits larger tenants; Topology B carries the long tail.

Shared-Host Appliance Stacks

Topology B runs many single-tenant appliance stacks on one shared host. Each stack is a fully isolated per-tenant appliance; the stacks never share a process, database, or login realm, so one tenant per appliance still holds.

A lightweight host agent runs on the shared host. It performs capacity-checked placement of new stacks and reports signed heartbeats that carry host and per-tenant-stack state to SCA, where a health monitor tracks host state. This strategy trades a small amount of per-tenant isolation for cost-efficient density, and it carries the long tail of smaller tenants.

Many single-tenant stacks on one host

One shared host runs many fully isolated single-tenant appliance stacks. A lightweight host agent places new stacks, manages them, and reports host and stack state to SCA through signed heartbeats.

Many single-tenant stacks on one hostPROVIDER CONTROL PLANESHARED HOSTPROVIDER PLATFORMSCACentral appliancePLACEMENT + REPORTINGHost AgentLightweightONE TENANTTenant A ApplianceIsolated single-tenant stackONE TENANTTenant B ApplianceIsolated single-tenant stackONE TENANTTenant C ApplianceIsolated single-tenant stackSigned heartbeatsManages
Host agent manages each single-tenant appliance stackSigned heartbeats carry host and stack state to SCA

Cost-efficient density

Packing many single-tenant stacks onto one host keeps per-tenant cost low for the long tail of smaller tenants.

Managed by a host agent

A lightweight host agent handles capacity-checked placement and reports signed heartbeats so SCA can track host state.

When to use shared-host placement

Shared-host placement suits the long tail of smaller tenants; larger tenants are typically served by Topology A, a dedicated appliance VM.

When Each Is Used

The provider chooses a topology per tenant, and can run both across one fleet:

  • Topology A suits larger tenants, where a dedicated appliance VM and the strongest isolation are worth the per-tenant overhead.
  • Topology B suits the high-count long tail of smaller tenants, where shared-host density keeps per-tenant cost low.
  • A provider can mix both topologies; the choice is made per tenant, not once for the whole deployment.

Isolation Guarantee

Neither topology changes the isolation model. Every tenant has its own appliance, its own data, and its own login realm, whether that appliance is a dedicated VM or one stack among many on a shared host.

No shared tenant boundary

Even on a shared host, no tenant boundary is ever shared. The host is only a placement detail; the isolation boundary is always the single-tenant appliance.

Scale

One SCA is designed to serve a large tenant fleet across either topology. The exact envelope depends on host sizing and tenant workload, so no fixed tenant count is quoted here.

Scaling is handled by sizing a single SCA to the fleet. Multi-SCA federation is out of scope.

Related Docs