Can VICIdial run on a VPS? An honest answer

Short answer: yes. VICIdial runs on a VPS, and a large share of the VICIdial installs in production today are running on one.

The advice you will still find in forum threads — that VICIdial will not virtualize and you need bare metal — was correct when it was written. It is now mostly out of date, but not entirely, and the part that is still true is worth knowing before you buy the cheapest VPS you can find. This page separates the two: what changed, what did not, and what actually determines whether a given VPS can carry a dialing floor.

Where did "VICIdial will not virtualize" come from?

It came from a real problem in a real era — roughly 2008 to 2015, when "VPS" usually meant a shared-kernel container, Asterisk conferences needed a timing source, and hosts oversubscribed CPU without telling anyone.

Three things were true at once:

• Conferences needed a timing source. A VICIdial agent session is built on a conference, and Asterisk's app_meetme required a timing source to run one. On a machine with no telephony card that meant a dummy driver — ztdummy, later dahdi_dummy — a kernel module that manufactured a tick from the kernel clock. On container virtualization you shared the host's kernel and often could not load a module at all. Where you could, the tick was at the mercy of the host's scheduler.
• CPU was oversubscribed and invisible. Providers packed many guests onto each physical core, and the guest had no clean way to see it. Audio breaks up when the process that must hand a 20 ms frame to the network does not get scheduled for 60 ms.
• Disk was shared spinning rust. Recording writes from dozens of concurrent calls, plus MySQL, on a platter shared with strangers.

Notice that every one of those is a complaint about a specific product and a specific era, not about virtualization as a concept. That is why the answer changed as both the hosts and the software changed.

Does VICIdial still need DAHDI for timing?

No — not on a current build. Modern Asterisk takes its timing from res_timing_timerfd, which uses a standard Linux kernel timer interface. It needs no telephony hardware and no kernel module of its own.

The chain that made DAHDI load-bearing broke at both ends:

• Asterisk 22 removed app_meetme entirely. VICIdial conferences run on ConfBridge instead.
• ConfBridge takes its timing from res_timing_timerfd, which Asterisk autoloads.

On the servers we build this is explicit rather than incidental. We compile Asterisk 22.5.1 from source without chan_dahdi, and the DAHDI kernel modules are not installed on a customer box at all. Nothing in the dialer notices, because nothing in the dialer asks for them any more.

One honest caveat: if you are running an older Asterisk that still uses app_meetme, the old requirement genuinely still applies to you. You need a working timing source, and on a virtualized box that historically meant dahdi_dummy. That is an argument for upgrading, not an argument for buying bare metal.

Is your vCPU dedicated or shared, and why does it matter more than anything else?

This is the single biggest variable, and it is the one VPS listings are vaguest about.

A "vCPU" is not a unit of hardware. It is a scheduling entitlement, and it comes in two shapes:

• Shared vCPU. Your guest competes with other guests for time on a physical core. This is fine when the provider's oversubscription ratio is conservative, and bad when it is not — and you generally cannot see the ratio from the outside.
• Dedicated vCPU. A physical core, or a hyperthread of one, is assigned to your guest and nothing else runs on it.

For a dialer, the thing that hurts is not average throughput. It is scheduling latency. Asterisk has to hand RTP packets to the kernel on a fixed cadence for every call leg it is carrying. Being fast on average and occasionally late is worse for a phone call than being consistently a bit slower, because the lateness is audible and the throughput is not.

You can measure contention from inside the guest. The st column in vmstat 1 or top is steal time — time your vCPU was runnable but the hypervisor gave the physical core to somebody else. On a healthy box it sits at or near zero. Sustained non-zero steal during your busiest dialing hour is the signal to move to dedicated cores.

We are deliberately not giving you a threshold percentage here. What matters is whether steal is sustained under your real load, not what number it touches once during a backup. Measure it on your own box, during a real campaign.

Are timing, jitter and clock drift the same problem?

No. Three different things get called "timing" in VICIdial threads, they fail in three different ways, and the fix for each is different.

1. Asterisk's internal frame timer. This is the res_timing_timerfd story above. It is virtualization-safe on any modern kernel. Its failure mode is loud and immediate — conferences do not work at all — rather than an intermittent audio problem.
2. Jitter. Variation in the arrival time of RTP packets, absorbed by the jitter buffer. It is produced by the network path and by scheduling delay at either endpoint. A contended VPS can contribute, because your process hands packets off late. So can the agent's home Wi-Fi, the carrier's route, and an overloaded softphone. Choppy audio gets blamed on the VPS far more often than the VPS deserves.
3. The wall clock. VICIdial writes timestamps into vicidial_log from the system clock. Drift here corrupts call durations, reports and compliance records — it does not touch your audio at all. Our provisioning turns NTP on, re-syncs hourly from cron, and prints a warning during the build if no NTP daemon came up.

Keeping these three apart saves a lot of wasted debugging. Upgrade for the first, look at the network and at CPU contention for the second, check timedatectl for the third.

How much disk does VICIdial need, and what shape is the I/O?

More capacity than most people plan for, but a friendlier I/O pattern than they fear: sequential writes while calls are up, plus a scheduled compression pass.

• Asterisk records through MixMonitor into /var/spool/asterisk/monitor, and VICIdial's cron chain moves and mixes the files into /var/spool/asterisk/monitorDONE.
• Sizing rule of thumb: about 250 KB per minute of mono recording. A hundred agents at four talk-hours a day, 250 days a year, is roughly 360 GB of raw audio per year.
• On our build the audio cron chain runs every three minutes — move and mix, compress to MP3, then archive — and a nightly job deletes the original uncompressed files after a day. Steady-state disk therefore holds MP3s, not WAVs, which is most of the difference between "recordings are expensive" and "recordings are fine".
• The I/O shape is many small sequential writes during calls, and a CPU-heavy compression pass on a schedule. On local NVMe the write volume is not the constraint. On a VPS with network-attached or burst-credit storage it can be, and that is one of the places the old advice still bites.
• Recordings stay on disk until you prune them. Retention is a policy decision, not a default — the call recording and retention doc covers the industry minimums.

What changed, and what did not?

The honest scorecard:

Where does the old advice still hold?

On a cheap, heavily oversubscribed VPS, "do not run VICIdial on it" is still correct. The era changed; that particular product did not.

Concretely, avoid:

• Burstable CPU with credits. Credits are designed for spiky web traffic. Dialing is a sustained load for eight hours, so the credits run out and the box gets throttled at exactly the wrong moment in the shift.
• Burst-credit or network-attached disk with a low IOPS floor. Recording writes are constant, and the compression pass is not gentle.
• Container virtualization that shares the host kernel. OpenVZ and similar. You cannot load modules, you often cannot reliably raise ulimits, and your neighbours' load lands inside your kernel. Full virtualization — KVM — is what you want. systemd-detect-virt will tell you which you have.
• Under-provisioned RAM. Our servers deliberately run with no swapfile; provisioning removes one if the base image created it. On a real-time workload, swapping is worse than failing loudly, so RAM has to be sized correctly rather than rescued after the fact.
• Anything that requires a physical card. T1/E1 termination, an on-prem recording appliance, a hardware echo canceller. This part of the old advice never expired.

And plainly: a VPS with one vCPU and one gigabyte of RAM will not run VICIdial well, whoever sells it. Our floor for a customer-supplied box is 4 vCPU, 4 GB RAM, 40 GB free disk and Ubuntu 22.04 on x86_64 with a 5.15 or newer kernel — and that is a floor for a small floor, not a target.

How many agents will a given VPS tier actually carry?

On our own ladder, shared-CPU tiers are rated from 5 to 100 simultaneous agents, and dedicated-core tiers from 30 to 400. CPU and RAM ranges below span our US, EU and Singapore regions, which use different provider SKUs.

Read those as ratings for a normal outbound mix, not as physical ceilings. Note the shape of it: a dedicated core is rated for meaningfully more agents than a shared vCPU at a comparable count, and the gap is the contention allowance made explicit rather than hidden.

What actually binds, roughly in the order you hit it:

1. CPU, mostly for RTP handling and any transcoding. Our endpoints are offered opus, ulaw, alaw and g722, with G.729 available. If your carrier delivers one codec and your agents use another, every leg pays for a transcode. Matching codecs end to end is the cheapest performance work you will ever do.
2. RAM, mostly for MariaDB. VICIdial's hot tables — vicidial_log, vicidial_list — are MyISAM, so the key buffer is what matters, not the InnoDB pool. Provisioning sizes key_buffer_size to 30% of RAM and the InnoDB pool to 15%, with floors and caps, because stock Ubuntu MariaDB defaults are sized for a light web app and will stall a dialer under load.
3. File descriptors. Each call consumes roughly five to ten of them — SIP socket, RTP socket, AGI socket, recording handle. The default systemd cap of 1024 starts logging "Too many open files" somewhere around a hundred concurrent calls, which is why we raise it to 131072 on every box.
4. Web workers. The VICIdial UI runs under mod_php on the prefork MPM. Ubuntu ships a flat 150 workers, which is too few on a big box and an out-of-memory risk on a small one; we compute the limit from RAM, core count and the database connection ceiling instead.
5. Disk, last, and usually as a capacity problem rather than a throughput one.

There are also dialer-side ceilings that are configuration rather than hardware. Each of our servers ships with max_vicidial_trunks at 200 and outbound_calls_per_second at 6, and both are adjustable in the VICIdial admin. If a box is not dialing as hard as the hardware allows, check those before you buy a bigger tier.

Should you use a VPS or a dedicated server?

Use a VPS until CPU contention or core count becomes the binding constraint, then move to dedicated cores. That is the whole decision.

• Shared vCPU is the right default for most floors, provided your provider is not overselling. It is also the cheaper way to find out how much box you actually need.
• Dedicated cores buy predictability rather than raw speed. Worth paying for when your floor is large, when your codec mix forces transcoding, when you run heavy reporting on the same box, or when you have measured steal time and it is not zero.
• Bare metal is for hardware you must physically attach, or for a compliance regime that requires custody of the machine.

You can compare the tiers on our VPS hosting plans and the dedicated-core plans, or see the whole plan grid in one place. If you already have a VPS you like, we will install and manage VICIdial on a box you own instead of selling you another one.

What should you check before trusting a VPS with a floor?

Seven checks, and only the last one settles it.

1. Is the CPU shared or dedicated, and will the provider state its oversubscription ratio in writing?
2. Is it full virtualization or a shared-kernel container? Run systemd-detect-virt and look for kvm.
3. Is the CPU burstable or credit-based? Dialing is sustained load, so credits are the wrong shape.
4. Is the disk local NVMe or network-attached, and is its throughput credit-based?
5. Can you raise ulimits and set LimitNOFILE on a systemd unit? If the platform blocks that, it will block you around a hundred concurrent calls.
6. Is NTP running? Check timedatectl, and remember this protects your reports, not your audio.
7. Load-test it. Dial a real campaign at your expected concurrency, watch the steal column in vmstat 1, and listen to the calls.

Anything a provider will not let you test before you pay, assume you cannot rely on.

So, can VICIdial run on a VPS?

Yes — on a VPS that is honest about what it sells you, with dedicated or lightly-subscribed CPU, local disk, full virtualization and enough RAM that you never think about swap. That describes a large part of the market today, which is exactly why the old blanket advice has aged out.

The advice that has not aged out is narrower and still worth repeating: a $5 oversubscribed burst-credit VPS is a bad place to put a call center, and if you terminate PSTN circuits on a card, you need a machine with a slot for it.

If you would rather not evaluate the underlying box yourself, that is what we sell — managed VICIdial on a VPS from $49/mo, built in about 40 seconds with root SSH and your own SIP carrier. If you are still deciding whether to change hosts at all, our VICIdial alternatives hub and the head-to-head comparisons are the honest version of that question, including the ViciBox comparison for teams coming off a self-installed box and the Ucartz comparison for anyone weighing a self-managed dedicated server instead. There is also a vendor-neutral checklist for evaluating any VICIdial host you can take to all of them.