Multi-tenant PBX hosting lets a single Asterisk installation serve multiple independent organizations/customers with genuine isolation between them — relevant for hosting providers or organizations with genuinely separate business units. This guide covers the architecture.
What Multi-Tenancy Requires
Beyond just multiple extensions (which any PBX supports), genuine multi-tenancy requires isolation — Tenant A shouldn't be able to see, call, or interfere with Tenant B's extensions, configuration, or call data, similar isolation principle to How to Set Up Network Segmentation on a Single VPS applied at the PBX application layer.
Using FreePBX's Multi-Tenant Capabilities
Some FreePBX distributions/modules provide dedicated multi-tenant functionality — verify whether your specific FreePBX setup includes this, since base FreePBX doesn't inherently provide strong tenant isolation without additional configuration or specialized modules.
Using Separate Asterisk Contexts Per Tenant
[tenant-a-internal]
exten => 1001,1,Dial(PJSIP/1001@tenant-a)
[tenant-b-internal]
exten => 2001,1,Dial(PJSIP/2001@tenant-b)Asterisk's context system can provide dialplan-level isolation — extensions in one tenant's context can't directly dial extensions in another tenant's context unless explicitly routed, providing a foundational isolation mechanism.
Using Separate PJSIP Endpoint Namespacing
[1001-tenant-a]
type=endpoint
context=tenant-a-internal
[1001-tenant-b]
type=endpoint
context=tenant-b-internalEnsure extension numbers don't collide across tenants (or use a prefix/namespace scheme), and that each endpoint's context correctly scopes it to the appropriate tenant's dialplan.
Isolating Voicemail and Recordings Per Tenant
Ensure voicemail boxes, call recordings, and other tenant-specific data are stored with clear tenant separation (separate directory structures, at minimum) — both for genuine isolation and to simplify eventual data export if a tenant relationship ends.
Considering Full VM/Container Isolation (Stronger Alternative)
For genuinely strong isolation guarantees (particularly if tenants are external customers rather than internal business units), running entirely separate Asterisk instances per tenant (in separate containers or VMs) provides stronger isolation than shared-instance context separation — trades resource efficiency for genuine security/isolation strength.
Setting Up Per-Tenant Billing/Usage Tracking
If billing tenants based on usage, ensure your CDR (Call Detail Record) data is properly tagged/separable by tenant — essential for accurate usage-based billing across multiple tenants sharing infrastructure.
Managing Tenant Onboarding/Offboarding
Establish a clear, ideally automated process for adding new tenants and cleanly removing departed ones — manual, ad-hoc tenant management becomes increasingly error-prone as tenant count grows.
Securing Against Cross-Tenant Access
See How to Secure a VoIP Server Against Toll Fraud for general VoIP security — specifically verify (through actual testing, not just configuration review) that tenants genuinely cannot access or interfere with each other's extensions/data.
Common Errors
A tenant discovers they can somehow reach another tenant's extension — treat this as a genuine security/isolation failure requiring immediate investigation; review your context/dialplan isolation configuration thoroughly, since this represents a fundamental breach of the multi-tenancy promise.
Continue Reading
- How to Set Up Network Segmentation on a Single VPS
- How to Secure a VoIP Server Against Toll Fraud
- How to Configure Extensions and Voicemail in Asterisk
Browse more articles in VoIP & Communication Servers.
