Deployment Options

The Thirdlane Platform supports two deployment modes: All-in-One, where one server carries everything, and Cluster, where the platform is spread over several servers. You select the deployment mode during the Initial Wizard and it determines the available features and menu options in Configuration Manager.

These are two independent questions, and it is worth separating them before reading further:

• How much the platform has to carry decides between All-in-One and a cluster. That is what most of this page is about.
• Whether the platform survives losing a server is a different decision with its own arrangements, covered under Surviving the loss of a server.

One of those arrangements is called an HA cluster, and it is not the same thing as the cluster deployment mode. An HA cluster is two servers sharing one mirrored disk so that one can take over from the other. A cluster deployment is several servers dividing the work between them. Where either could be meant below, it is said explicitly.

Product editions

Thirdlane is a single product: Thirdlane Multi Tenant PBX. A service provider hosts many tenants; a single business simply runs the platform with one tenant. There is no separate “Business PBX” product to choose - the same feature set applies at any scale, and deployment is decided by topology (All-in-One vs Cluster) rather than by edition.

Legacy Single Tenant edition. Older installations use a separate single-tenant package (getpbx-ste, historically branded “Business Phone System”). It is still supported for existing installs but is not recommended for new deployments. Its behavior differs from Multi Tenant in a few places: DIDs and number patterns can be entered directly on Inbound Routes and Inbound Messaging Routes (in Multi Tenant, DIDs are restricted to those assigned to the tenant and patterns are not used), and Caller ID Number/Name can be entered directly (in Multi Tenant these follow the tenant’s Caller ID policy). New single-tenant deployments should install the Multi Tenant package and run a single tenant.

All-in-One

All services run on a single server: Configuration Manager, database, PBX engine, Kamailio (SIP routing), and all supporting components.

┌─────────────────────────────────────────┐
│            All-in-One Server            │
│                                         │
│  ┌──────────┐  ┌──────────┐            │
│  │ Config   │  │ Database │            │
│  │ Manager  │  │ (MySQL)  │            │
│  └──────────┘  └──────────┘            │
│  ┌──────────┐  ┌──────────┐            │
│  │  PBX     │  │ Kamailio │            │
│  │ Engine   │  │ (SIP)    │            │
│  └──────────┘  └──────────┘            │
│  ┌──────────┐  ┌──────────┐            │
│  │ Connect  │  │  Nginx   │            │
│  │ (XMPP)   │  │ (Web)    │            │
│  └──────────┘  └──────────┘            │
└─────────────────────────────────────────┘

When to use:

• Small to medium installations (up to a few hundred users)
• Development and testing environments
• Organizations with their own backup/recovery strategy
• Starting point — can be upgraded to a cluster later

Characteristics:

• Simple to set up and maintain
• Can run on bare metal, VM, or cloud (AWS, Google Cloud, Azure)
• Configuration changes apply immediately on the same server
• No automatic failover on its own - see Surviving the loss of a server for the two ways to add it

Surviving the loss of a server

An All-in-One server on its own has no failover. If the machine is lost, recovery means installing a replacement and restoring a backup onto it, which is measured in hours and loses whatever happened after the backup was taken.

There are two ways to avoid that. They are different arrangements built on different mechanisms, not two settings of the same one.

A replicated standby is a second server that receives a continuous copy of the first one’s configuration, call records, chat history and voicemail, and is deliberately held unable to answer anyone until an administrator promotes it. Because the copy arrives continuously, the platform can report at any time whether a switchover would succeed. The two servers can be in different data centers. This is set up from General Settings & Tools > Standby Server and needs nothing outside the platform. See Standby Server.

An HA cluster is two servers sharing one copy of the data on a disk that is mirrored between them, with cluster software moving the services and the address clients use to the surviving machine on its own. Nothing that was committed is lost and nobody has to be present for the switch, but both servers have to be close together on a fast local network. An HA cluster is built for a site by the Thirdlane services team rather than configured from the Manager. See HA Cluster.

Two things are true of both:

• Neither replaces backups. A mistake, a bad change or corrupt data is copied to the second server like anything else.
• Do not configure both on the same servers. Each arrangement has to be the only thing deciding which machine is in charge.

Two ways to run a second server compares them in full, including what each one does not protect against.

Both of these apply to a single All-in-One server. Making a cluster survive the loss of a server is arranged tier by tier and is not set up from the Manager - contact Thirdlane to discuss it.

Cluster

In a cluster the platform is divided between servers by function, and the part that handles calls can then be scaled on its own. Every server has one of four types, and the type decides both what is installed on it and what configuration it is sent.

• Manager - runs Configuration Manager, holds the database, and is where the cluster’s own description is written and published from.
• User Access server - serves the user portal, Thirdlane Connect and the REST API.
• Telephony frontend - the entry point for call traffic. Runs Kamailio and a front Asterisk, and passes configuration on to the workers behind it.
• Telephony worker - processes calls. This is the tier you add to as call volume grows.

A cluster holds one manager, one User Access server and one telephony frontend, and as many telephony workers as it needs.

Compact and expanded

How those functions are spread out is the cluster’s shape, and there are two.

• Compact - the manager also carries user access and the telephony frontend. Only the workers are separate servers.
• Expanded - user access and the telephony frontend each run on their own server.

Both shapes put the workers on their own servers, so the shape is not about how many servers there are. What differs is whether one server carries several functions.

The shape is fixed when the cluster is installed, because it decides what software went onto each machine. It is reported on Cluster Configuration and cannot be changed from the Manager - changing it means rebuilding servers.

                 ┌──────────────────────────┐
                 │        Manager           │
                 │  Configuration Manager   │
                 │  Database                │
                 │  Publishes the cluster   │
                 │  description             │
                 └───────────┬──────────────┘
                             │
           ┌─────────────────┴─────────────────┐
           │                                   │
┌──────────┴───────────┐          ┌────────────┴─────────┐
│  User Access         │          │  Telephony frontend  │
│  User portal         │          │  Kamailio (SIP)      │
│  Thirdlane Connect   │          │  Front Asterisk      │
│  REST API            │          └────────────┬─────────┘
└──────────────────────┘                       │
                                   ┌───────────┴───────────┐
                                   │           │           │
                              ┌────┴───┐  ┌────┴───┐  ┌────┴───┐
                              │ Worker │  │ Worker │  │ Worker │  ...
                              │Asterisk│  │Asterisk│  │Asterisk│
                              └────────┘  └────────┘  └────────┘

In a compact cluster the two middle boxes are the Manager itself.

When to use:

• Large installations (thousands of users)
• Service providers (MSPs, UCaaS)
• Call volume that one server cannot carry
• Organizations needing updates without taking calls offline

Characteristics:

• Capacity scales by adding telephony workers
• If a worker is lost, the telephony frontend routes calls to the remaining workers
• The cluster’s own description - which servers exist, what each one is, where the shared services are - is written on the Manager and published to every server. See Cluster Configuration
• Configuration changes reach the other servers by data sync, which is a separate mechanism from publishing the description
• Updates can be applied a tier at a time rather than to everything at once

Choosing Your Deployment

	All-in-One	Cluster
Setup complexity	Low	Higher, and installed by the Thirdlane services team
Surviving the loss of a server	Restore a backup, add Standby Server for a standby you promote, or an HA cluster that switches on its own	Losing a worker is absorbed by the frontend. Protecting the other tiers is arranged per tier with Thirdlane
Scalability	One server’s limit	Add telephony workers
Updating a tier at a time	No	Yes
Geographic spread	With Standby Server using the DNS move method, the standby can be at another site. An HA cluster expects both servers in one location	The servers do not have to share a site
Best for	Small/medium orgs	Service providers, large orgs

You select the deployment mode during the Initial Wizard. Starting with All-in-One and moving to a cluster later is a supported path as your needs grow.

In cluster mode, additional menu items appear in Configuration Manager under Infrastructure: Servers, which registers the machines in the cluster and shows them as either a diagram or a list, and Cluster Configuration, which publishes that description to every server. Data Sync diagnostics are available in both modes.

Best practices

• Start with All-in-One unless you already need scale. It is simpler to run, and moving to a cluster later is a supported path - so do not build a cluster before your user count or call volume demands it. Surviving the loss of a server does not require one: an All-in-One server can have a standby or be part of an HA cluster.
• Choose a cluster when one server cannot carry the load. That is the question it answers. It is not the way to get failover.
• Scale the worker tier, not the others. Telephony workers are the tier meant to be added to; the manager, user access and frontend are one server each.
• Whatever the topology, keep tested backups (or snapshots). They are your safety net before any update, and they protect against mistakes that Standby Server does not - a bad change is copied to a standby like any other.
• Use the Multi Tenant package even for a single business and run one tenant - it keeps you on the current, recommended code path.

Related documentation

• Initial Setup Wizard - where deployment mode is selected
• Standby Server - add a standby server to an All-in-One deployment
• HA Cluster - two servers sharing a mirrored disk, and how the two failover arrangements compare
• Data Sync - how configuration propagates in a cluster
• Servers - register the servers that make up a cluster
• Cluster Configuration - publish the cluster description
• Updates and Maintenance - rolling updates and backups