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.

Multi-Tenant VoIPSaaS VoIPHosted PBXWhite-Label VoIPCPaaSFreeSWITCH

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.

By Kaushik Parmar— Founder & VoIP Architect, CelloIP Technologies·25 min read·June 9, 2026·≈ 3,000 words

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

Multi-tenant VoIP SaaS platform architecture for startups — Kamailio SIP proxy, FreeSWITCH media server cluster, REST provisioning API, CDR billing engine, white-label React admin portal with three tenants: enterprise, SMB, and startup each with own domain and extensions
Fig 1: Multi-tenant VoIP platform core with three tenant tiers (enterprise, SMB, startup). Each tenant has its own SIP domain, isolated configuration, and billing account on shared infrastructure.

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.

VoIP tenant isolation strategies comparison — Shared FreeSWITCH instance with domain-based routing supports 1000 plus tenants at lowest cost, Dedicated dialplan context per tenant for 50-500 tenants with custom configuration, Dedicated FreeSWITCH container per tenant for full HIPAA GDPR isolation enterprise tier
Fig 2: Three tenant isolation patterns. CelloIP recommendation: start with shared instance (supports 1,000+ tenants), add dedicated containers as a premium tier for enterprise/compliance customers.

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.

xmlconf/directory/tenant123.xml — per-tenant domain config
<!-- 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:

xmlconf/autoload_configs/xml_curl.conf.xml — dynamic config from DB
<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:

javascriptNode.js — tenant provisioning API (POST /api/tenants)
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

Month 1

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

Month 2

Provisioning API & Tenant Management

REST API for tenant CRUD

DID provisioning integration

Extension management API

Admin portal scaffolding (React)

Month 3

Features: IVR, Queues, Recording

Drag-and-drop IVR builder

Call queue with hold music

Per-tenant call recording to S3

Voicemail with email delivery

Month 4

Billing & Payments

CDR collection pipeline

Rate engine and rate tables

Stripe subscription integration

Invoice generation and PDF delivery

Month 5–6

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

ComponentMVPFull 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 tierNot 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.