What is a multi-tenant VoIP platform?
A multi-tenant VoIP platform is a SaaS telephony infrastructure where multiple organisations (tenants) share a common VoIP infrastructure (FreeSWITCH or Asterisk clusters, SIP proxies, billing) while maintaining complete isolation of their phone numbers, extensions, dialplans, call recordings, and billing accounts. Each tenant experiences it as their own hosted PBX, typically white-labelled with the platform operator's branding.
How do you build a multi-tenant VoIP platform?
Build a multi-tenant VoIP platform using: Kamailio/OpenSIPS for SIP registration and routing with domain-based tenant isolation, FreeSWITCH domains for per-tenant dialplan contexts, a Node.js provisioning API that automates tenant onboarding, a CDR-based billing engine for per-tenant usage billing, and a React white-label admin UI. The core design decision is choosing between shared instance, dedicated context, or dedicated container isolation per tenant.
How to Build a Multi-Tenant VoIP Platform: Architecture Guide for SaaS Startups
Building a hosted PBX SaaS is one of the highest-value VoIP projects — and one of the most architecturally complex. The difference between a multi-tenant platform and a single-tenant VoIP deployment is not just scale. It requires fundamental design decisions about tenant isolation, provisioning automation, billing architecture, and white-label capability that are expensive to change later.
CelloIP has built 25+ VoIP platforms — from startup MVPs handling 50 tenants to carrier-grade platforms serving 10,000+ customers. This guide gives you the architecture blueprint we follow, the technology stack decisions we've validated in production, and the timeline and cost reality for building one from scratch.
10k+
Tenants on shared FreeSWITCH cluster
3–4mo
MVP delivery timeline
25+
VoIP platforms built by CelloIP
90%
Cost reduction vs building from scratch twice
What is a Multi-Tenant VoIP Platform?
A multi-tenant VoIP platform is a hosted PBX SaaS where multiple organisations (tenants) share the same telephony infrastructure but have completely isolated phone system configurations. From a tenant's perspective, they have a dedicated phone system: their own DID numbers, extensions, IVR menus, call queues, voicemail, call recordings, and usage billing. They never see or interact with other tenants.
From the platform operator's perspective, a single FreeSWITCH cluster with Kamailio SIP proxy serves all of these tenants — dramatically reducing per-tenant infrastructure cost. The platform profit comes from the margin between wholesale SIP trunk rates (what you pay the carrier) and retail calling rates (what tenants pay you), plus the monthly SaaS subscription fee.
Hosted PBX
SMBs who want a phone system without on-premise hardware. Your platform replaces their office PBX.
UCaaS Platform
Unified Communications: voice + video + messaging + presence in one platform. WhatsApp for businesses.
CPaaS / API Platform
Programmable telephony APIs for developers: call, SMS, conferencing via REST API. Twilio-like platform.
Tenant Isolation Strategies: The Core Architecture Decision
The most important design decision in a multi-tenant VoIP platform is how you isolate tenants. Get this wrong and retrofitting it later costs more than the original build. There are three patterns, each with different trade-offs:
Pattern 1: Shared Instance (Domain-Based Routing)
Pros
Lowest infrastructure cost
Supports 1,000+ tenants per cluster
Easiest to scale horizontally
Cons
· Noisy-neighbour risk (one tenant's high call volume affects others)
· Complex dialplan debugging
· Limited isolation for compliance
Best for: SMB hosted PBX, 50–10,000 tenants, non-regulated industries
Pattern 2: Dedicated Dialplan Context Per Tenant
Pros
Strong configuration isolation
Easy per-tenant customisation
Simple troubleshooting
Cons
· FreeSWITCH memory grows with tenant count
· Reload times increase with many contexts
· Still shares media resources
Best for: Small to mid-scale platforms (50–500 tenants) needing rich customisation per tenant
Pattern 3: Dedicated Container Per Tenant
Pros
Complete resource isolation
HIPAA/GDPR-compliant
Independent scaling per tenant
Cons
· High infrastructure cost
· Complex orchestration (Kubernetes)
· Minimum 500–1,000 MB RAM per container
Best for: Enterprise tenants, healthcare, finance, government. Not cost-viable for SMB tenants.
CelloIP recommendation: Start with Pattern 1 (shared instance, domain-based) for your initial launch. This supports up to 2,000–3,000 tenants without architectural changes. Build Pattern 3 (dedicated containers) as an optional premium tier for enterprise tenants who need full isolation. Pattern 2 is a stepping stone — if you plan properly, you can skip it.
Full Platform Architecture
This is the production architecture CelloIP deploys for hosted PBX platforms targeting SMB and mid-market tenants:
SIP Edge Proxy
Kamailio 5.x
Registration, authentication, topology hiding, STIR/SHAKEN, per-tenant domain routing
SIP Application Routing
OpenSIPS 3.x
Load balancing to FreeSWITCH cluster, LCR, dialplan routing, REST management API
Media & PBX Layer
FreeSWITCH 1.10.x
Multi-tenant domain handling, IVR, call queues, conferencing, voicemail, recording
Provisioning API
Node.js + Express / Python FastAPI
Tenant CRUD, DID provisioning, gateway management, user management, configuration push to FreeSWITCH
Billing Engine
Python + PostgreSQL + Redis
CDR ingestion, rate table lookup, invoice generation, prepaid balance management, Stripe integration
Admin & Tenant UI
React + Next.js
White-label portal: extension management, IVR builder, call recording, usage reports, billing dashboard
Monitoring & Observability
Homer + Prometheus + Grafana
SIP call traces, CDR analytics, infrastructure metrics, alerting on call failure rate and latency
FreeSWITCH Multi-Tenant Domain Configuration
FreeSWITCH domains are the core of multi-tenant isolation. Each tenant gets a domain (e.g., tenant123.yourplatform.com). Extensions register to their domain. Calls are routed within the tenant's domain context.
<!-- Each tenant gets their own XML directory file -->
<!-- Generated by the provisioning API when a tenant is created -->
<include>
<domain name="tenant123.yourplatform.com">
<params>
<!-- Tenant-specific dialplan context -->
<param name="dial-string"
value="{^^:sip_invite_domain=${dialed_domain}:presence_id=${dialed_user}@${dialed_domain}}
${sofia_contact(*/${dialed_user}@${dialed_domain})}"/>
</params>
<variables>
<variable name="record_stereo" value="true"/>
<variable name="default_gateway" value="tenant123-pstn"/>
<!-- Per-tenant call recording path -->
<variable name="recording_path" value="/recordings/tenant123/"/>
</variables>
<groups>
<group name="default">
<users>
<!-- Users are dynamically loaded from PostgreSQL via mod_xml_curl -->
<!-- No need to list each user in static XML -->
</users>
</group>
</groups>
</domain>
</include>Use mod_xml_curl to dynamically serve user and domain configuration from your database — so you never need to restart FreeSWITCH when a tenant adds an extension:
<configuration name="xml_curl.conf" description="cURL XML Gateway">
<bindings>
<!-- Directory binding: fetch user auth from your provisioning API -->
<binding name="directory">
<param name="gateway-url"
value="https://api.yourplatform.com/fs/directory"/>
<param name="bindings" value="directory"/>
<!-- Pass FreeSWITCH's request params to your API -->
</binding>
<!-- Dialplan binding: fetch tenant dialplan from your API -->
<binding name="dialplan">
<param name="gateway-url"
value="https://api.yourplatform.com/fs/dialplan"/>
<param name="bindings" value="dialplan"/>
</binding>
</bindings>
</configuration>Provisioning API: Automating Tenant Onboarding
The provisioning API is what makes multi-tenancy operationally viable. Manually configuring FreeSWITCH for each new tenant does not scale past 20 tenants. The API automates everything:
const express = require('express');
const router = express.Router();
// POST /api/tenants — provision a new tenant
router.post('/tenants', async (req, res) => {
const { companyName, adminEmail, plan, didAreaCode } = req.body;
try {
// 1. Generate tenant ID and subdomain
const tenantId = generateSlug(companyName); // e.g., "acme-corp"
const domain = `${tenantId}.yourplatform.com`;
// 2. Provision DID from SIP trunk provider API
const did = await sipTrunkProvider.purchaseDID({
areaCode: didAreaCode,
routeTo: `sip:${tenantId}@${process.env.FREESWITCH_IP}`,
});
// 3. Create tenant record in PostgreSQL
const tenant = await db.tenants.create({
id: tenantId,
company_name: companyName,
domain,
did_number: did.number,
plan,
status: 'provisioning',
});
// 4. Generate FreeSWITCH domain XML file
await generateFreeSwitchDomainXML(tenantId, domain);
// 5. Create SIP gateway for tenant's PSTN outbound route
await freeswitchESL.api(
`sofia profile internal rescan`
);
// 6. Create default admin extension (1000)
const adminExt = await provisionExtension({
tenantId,
extension: '1000',
name: companyName + ' Admin',
email: adminEmail,
password: generatePassword(),
});
// 7. Set up billing rate table for plan
await billingEngine.createTenantRatePlan(tenantId, plan);
// 8. Send welcome email with SIP credentials
await emailService.sendWelcome({
to: adminEmail,
tenantId,
domain,
extension: '1000',
sipPassword: adminExt.sipPassword,
did: did.number,
});
// 9. Update tenant status to active
await db.tenants.update(tenantId, { status: 'active' });
res.json({
success: true,
tenantId,
domain,
did: did.number,
adminPortal: `https://${domain}/admin`,
});
} catch (error) {
// Rollback provisioned resources on failure
await rollbackTenantProvisioning(tenantId);
res.status(500).json({ error: error.message });
}
});CDR-Based Billing Engine
Billing is the most complex part of a VoIP platform that most startups underestimate. Every call generates a CDR (Call Detail Record) with the raw data for billing. Your billing engine rates these CDRs against per-tenant rate tables and generates invoices.
CDR Ingestion
FreeSWITCH writes CDRs via mod_cdr_csv or mod_xml_cdr. A consumer service reads these, normalises fields (duration, origination, destination, codec), and inserts into PostgreSQL.
Rate Engine
For each CDR, look up the destination prefix in the tenant's rate table. Apply per-second billing: cost = ceil(duration_seconds) × rate_per_second. Store rated CDR with cost.
Invoice Generation
Monthly batch job: aggregate all rated CDRs per tenant, add monthly subscription fee, apply taxes, generate PDF invoice, charge via Stripe API.
Prepaid Balance
Check tenant balance via Redis before allowing call setup (OpenSIPS auth script). Decrement balance in real time as call progresses. Alert at low balance threshold.
Build Timeline & Milestones
Core Infrastructure & SIP Stack
FreeSWITCH + Kamailio cluster setup
Domain-based multi-tenant config
Basic SIP registration and calling
mod_xml_curl for dynamic user config
Provisioning API & Tenant Management
REST API for tenant CRUD
DID provisioning integration
Extension management API
Admin portal scaffolding (React)
Features: IVR, Queues, Recording
Drag-and-drop IVR builder
Call queue with hold music
Per-tenant call recording to S3
Voicemail with email delivery
Billing & Payments
CDR collection pipeline
Rate engine and rate tables
Stripe subscription integration
Invoice generation and PDF delivery
White-Label, Reseller Tier & QA
Custom branding per tenant (logo, colours)
Reseller management tier
Load testing (500 concurrent calls)
Security audit and penetration test
Development Cost Breakdown
| Component | MVP | Full Platform |
|---|---|---|
| VoIP core (FreeSWITCH + Kamailio) | $8,000–$15,000 | $15,000–$25,000 |
| Provisioning API | $6,000–$10,000 | $15,000–$25,000 |
| Billing engine | $5,000–$8,000 | $15,000–$30,000 |
| Tenant admin UI | $8,000–$12,000 | $20,000–$40,000 |
| IVR builder / call features | $5,000–$8,000 | $15,000–$25,000 |
| Reseller tier | Not included | $15,000–$25,000 |
| DevOps / HA cluster | $3,000–$5,000 | $10,000–$20,000 |
| QA, security audit | $3,000–$5,000 | $8,000–$15,000 |
| Total | $38,000–$63,000 | $113,000–$205,000 |
CelloIP rates: $25–$45/hour depending on engineer seniority and engagement type. Engagement typically includes 2 senior VoIP engineers + 1 full-stack developer + 1 DevOps engineer. Fixed-price contracts available for well-defined scopes.
Frequently Asked Questions
What is a multi-tenant VoIP platform?
A multi-tenant VoIP platform is a hosted PBX SaaS where multiple organisations share the same telephony infrastructure but have complete isolation of their numbers, extensions, routing, recordings, and billing. Each tenant has their own white-label phone system interface. The platform operator manages a single infrastructure while tenants self-serve their configuration.
What are the three tenant isolation strategies?
Shared instance: all tenants on one FreeSWITCH/Asterisk instance with domain-based routing (most cost-efficient, handles 1,000+ tenants). Dedicated context: each tenant gets an isolated dialplan context on shared infrastructure. Dedicated instance: each tenant gets their own FreeSWITCH container (maximum isolation — used for large enterprise tenants or compliance-sensitive verticals like healthcare).
Should I use FreeSWITCH or Asterisk for a multi-tenant platform?
FreeSWITCH is generally preferred: it handles 5,000–10,000 concurrent calls vs Asterisk's 1,500–3,000, has cleaner domain-based tenant isolation in sofia.conf, and performs better at high tenant density. Asterisk is viable for smaller platforms (under 500 concurrent calls) where its richer IVR feature set and larger community outweigh the concurrency gap.
How does the provisioning API work?
The provisioning API is a REST service that automates tenant onboarding: creates a FreeSWITCH domain for the tenant, provisions DID numbers from your SIP trunk provider, creates gateway entries for PSTN routing, inserts rate table entries for billing, creates admin users, and sends welcome emails. All of this happens in seconds via API — no manual FreeSWITCH config changes.
How do I implement real-time billing in a VoIP platform?
Use FreeSWITCH's ESL or mod_xml_cdr to capture call events. For postpaid: batch CDRs, run a nightly rating job against rate tables, generate invoices. For prepaid: use OpenSIPS or Kamailio's billing module (or FusionPBX's prepaid logic) to check the tenant's balance before allowing the call and decrement in real time. For accurate billing, capture both connect and disconnect events with exact second-billing.
How long does it take to build a multi-tenant VoIP platform?
An MVP (registration, calling, IVR, billing) takes 3–4 months with a 3–4 person team. A production platform with white-label UI, reseller tiers, call recording, analytics, and HA cluster takes 8–12 months. CelloIP has delivered full platforms in 6 months. The biggest delays are always billing complexity and carrier integration, not the VoIP core.
What is the hosting infrastructure cost?
A small platform supporting 50 tenants and 200 concurrent calls: $500–$1,000/month (2x FreeSWITCH VPS + Kamailio SIP proxy + PostgreSQL + Redis + monitoring). A medium platform (500 tenants, 2,000 concurrent calls): $3,000–$6,000/month. Costs scale roughly linearly with concurrent call capacity.
Can I build a reseller tier into the platform?
Yes. A reseller tier adds a middle layer between the platform operator and end tenants. Resellers have their own branded portal, can provision sub-tenants with their own markup on rates, and see aggregated reporting for all their sub-tenants. This is a core architecture decision — plan for reseller hierarchy from day one because retrofitting it is expensive.
Ready to Build Your VoIP SaaS Platform?
CelloIP has built 25+ multi-tenant VoIP platforms — from 50-tenant hosted PBX products to 10,000-tenant wholesale carrier platforms. We handle the full stack: VoIP core, provisioning API, billing, white-label UI, and HA infrastructure. We can deliver an MVP in 3–4 months or a full production platform in 6–8 months.
Architecture Consulting
2-week engagement: we review your requirements and deliver a detailed architecture document, stack recommendation, and project plan.
MVP Development
Fixed-price MVP: registration, calling, IVR, billing, admin UI. Typically $40,000–$60,000, delivered in 3–4 months.
Full Platform Build
End-to-end platform with reseller tier, white-label, HA cluster, and carrier-grade SIP infrastructure. 6–8 months.