Multi-Tenant Or Multi-Instance Cloud PBX: What Service Providers Should Know

Every provider that sells cloud phone systems to more than one business has to answer the same question early: does each customer get its own copy of the PBX, or do all customers share one platform that keeps them apart? The first approach is usually called multi-instance, the second multi-tenant. Both can work. They lead to very different costs, operations and limits, so it is worth understanding them before you commit to a vendor.

Multi-Instance: One PBX Per Customer

In a multi-instance design, every customer runs on a separate PBX instance, usually a virtual machine or container, often managed from a central console. Isolation is easy to explain: one customer's configuration, load or fault cannot touch another's because they do not share a process.

The cost is operational. Each instance needs resources even when the customer is idle, and every upgrade, certificate, backup and security patch is multiplied by the number of customers. At a few dozen customers this is manageable. At a few thousand it becomes most of the work.

Multi-Tenant: One Platform, Many Workspaces

In a multi-tenant design, one platform serves every customer, and the software keeps them apart. Done properly, each customer has its own identity on the platform, its own users and numbers, its own call routing and its own limits, and nothing in one customer's configuration can be reached from another.

Resources are shared, so an idle customer costs almost nothing, and an upgrade is done once for everyone. The risk is weak isolation: if the platform was built for one company and stretched to many, things like extension numbers, dial plans and recordings can leak between tenants.

What Real Isolation Looks Like

Whichever model you choose, ask how each of these is separated per customer:

• Identity: can two customers both have extension 1001 without any clash?
• Call routing: is each customer's dial plan its own, so a mistake in one cannot route another's calls?
• Capacity: does each customer have its own concurrent-call limit, so one busy customer cannot starve the rest?
• Administration: can a customer administrator ever see another customer's users, numbers or recordings?
• Billing and fraud: are charges, wallets and fraud limits held per customer?

How Capacity Grows

Multi-instance platforms grow by adding instances. Multi-tenant platforms grow by adding capacity to the shared platform, which is simplest when the voice servers hold no customer configuration of their own and fetch it from a database at call time. Then any voice server can handle any customer, and capacity grows by adding servers behind a load balancer instead of moving customers around.

How The TechVision365 Platform Does It

The TechVision365 platform takes the multi-tenant approach. Each customer workspace is its own SIP domain and its own dial plan with its own concurrent-call limit, so customers can reuse extension numbers without ever meeting. Directory, routing and IVR configuration live in a database and are served to the voice core when a call arrives, which is the basis for adding voice nodes as you grow. Today each region runs on one voice node, load-tested at 500 concurrent calls.

Providers manage everything from one console: workspace lifecycle, licences and menu access, branding, platform roles, billing and fraud limits, and an audit log of every change.

Questions To Ask Any Vendor

• How are customers separated at the SIP and dial-plan level, not just in the web portal?
• What happens to other customers when one customer's traffic spikes?
• How long does an upgrade take for all customers, and does it need a maintenance window per customer?
• Can I run the same platform on my own servers if a customer needs data kept in-country?
• Who owns the customer relationship and the pricing?