Scaling Vicidial® beyond a single server — when and how to split

A single-server Vicidial® / ViciBox® VPS handles roughly 50-150 concurrent agents depending on call complexity, list activity, and how aggressive the predictive dialer is. Past that, you start seeing MariaDB bottlenecks, Asterisk® thread contention, and database-locking that slows everything. This article covers when to scale out and the realistic migration path.

Signs you've outgrown single-server

• Database queries from the agent UI starting to take seconds (admin → real-time reports lagging).
• Asterisk-side audio quality degrading during peak — DB I/O competing with media handling.
• Predictive dialer making "too few" or "too many" calls compared to its targets (CPU saturation slowing the calculation loop).
• Disk I/O queue depth (iostat) sustained above 5-10 for long periods.
• Frequent "Vicidial process locked" warnings in logs.

You'll typically hit ONE of these before the others. The fix is the same: split.

The classic split: database + telephony

Vicidial's reference multi-server architecture separates roles:

• Database server — runs MariaDB only. Holds all leads, lists, agent state, CDRs.
• Web / admin server — runs Apache + the agent/admin PHP UIs.
• Asterisk / telephony servers — one or more. Each runs Asterisk + the Vicidial dialing daemons. All connect to the central DB.
• Archive server (optional) — receives call recordings off the Asterisk boxes for long-term storage.

Each role on its own VPS. Predictive dialer's call-target calculations remain centralized in the DB; the Asterisk servers just execute the dial-and-route work.

The order of splitting

You don't have to split everything at once. The progression that usually makes sense:

1. Step 1: single server (50-150 agents). When you hit the limit, …
2. Step 2: split the DATABASE off to its own VPS. Telephony stays where it is, points at the new DB host. Often gets you to 200-300 agents.
3. Step 3: add a SECOND Asterisk server. Agents distributed across the two via the web UI (each agent's session pins to a specific Asterisk server for the shift). DB remains centralized. Gets you to 400-600 agents.
4. Step 4: add more Asterisk servers + a dedicated web/admin server. Now you're firmly multi-server.

What's painful about scaling out

• The database becomes the bottleneck again. Many MariaDB tuning parameters that worked at single-server load break under the additional connection count from multiple Asterisk boxes. Plan time for DB tuning specifically.
• Time sync becomes critical. Every Vicidial box needs identical time (within milliseconds) for predictive-dialer timing to work. Make sure chrony is configured everywhere with a common upstream.
• File-system sync. Some assets (call recordings, audio prompts) need to be available on every Asterisk box. NFS, GlusterFS, or rsync-based replication patterns all work; pick one and document.
• Network between servers. Inter-server latency matters. Co-locating the Vicidial cluster nodes on the same LYLIX hypervisor (or at least same region) is much better than cross-region.

The migration path from single-server

1. Stand up the new DB VPS. Install MariaDB, copy the asterisk database via mysqldump.
2. Update the existing single-server config to point at the new DB host (Vicidial's /etc/astguiclient.conf + Asterisk's cdr_mysql.conf etc.).
3. Test thoroughly during a low-traffic window. Roll back if anything's off.
4. Once stable on the split DB, add the second Asterisk box. Configure it to register against the central DB, assign a subset of agents to it via the admin UI.
5. Move agents over gradually, watching DB load.

What you don't need to split

• Recording storage. NFS-mount a shared recordings volume from the DB box (or a dedicated storage box) onto each Asterisk box. Don't run a separate recording server until storage volume justifies it.
• The webserver. Until agent UI response times degrade, the web server can live on the database VPS or one of the Asterisk boxes.

HA considerations

Multi-server doesn't equal high-availability. Each role is still a single point of failure unless you add replication / failover:

• Database: MariaDB master-slave or Galera cluster for read replicas; failover via keepalived or app-level.
• Asterisk: agents move to a different Asterisk box when their current one fails — no in-call survival, but new logins go elsewhere.
• Web: round-robin DNS or load balancer.

HA is a separate project from scaling and can wait until you have a real reason. Most operations live with "the cluster has SPOFs and a multi-hour maintenance window is acceptable" indefinitely.

When to consider NOT scaling Vicidial out

If you're at 150 agents and growing, the multi-server path is correct. If you're at 150 agents and stable, evaluate whether further growth is realistic — sometimes the right answer is splitting into two SEPARATE call centers (different business lines, separate databases, separate audit boundaries) rather than one large cluster.