VICIdial VPS requirements and cost: separate a lab floor from production capacity

Start with a workload model, not a VM size

Write down peak simultaneous agents, expected calls per hour, recording retention days and target region. Ask each provider for a quote using those same figures; leave unknown items blank until the provider answers.

Fast answer: a small lab host that finishes a narrow, reproducible test demonstrates reproducibility, not production capacity. Neither a specific memory size, virtual CPU (vCPU) count, nor any quoted VPS price can be read off any single host, including the one this publication runs its own demo on. A lab that completes one test call has proven the call path works at all; it has proven nothing about several dozen agents dialing at once, a month of accumulated recordings, or a reporting query run against a full history table.

Use a pilot to measure your own concurrent agents, dial attempts, recording mix, codecs, database growth, reporting queries, carrier behavior, browser mix and recovery objective. This article assumes a new deployment and excludes a promise of calls-per-second, uptime, carrier cost or vendor ranking.

Two VICIdial-specific words matter here — agent and carrier — and this guide assumes you already know them; the companion article “VICIdial terminology for complete beginners: users, phones, campaigns and leads” defines both from scratch.

• Write down estimated agents and call volume, the region and currency, and who will configure the carrier and restore the service.
• Non-goal: this is not a provider quote, benchmark or recommendation.
• Set a recovery-time objective (RTO: maximum acceptable restoration time) and recovery-point objective (RPO: maximum acceptable data loss measured in time) before comparing plans.

What the lab floor actually tells you

This publication runs its own ViciBox 12 demo as a single all-in-one host. The commands below capture that host's live memory, logical CPU count and free root-filesystem space as a record of this lab's footprint at the time of writing — never a stated VICIdial minimum, a recommended size, or a production capacity claim.

Operating-system installation minima are not dialer minima either. Telephony, database cache, PHP/Apache, background workers, logs, media processing and traffic bursts all contend for memory and disk differently from a freshly imaged cloud instance, and differently again from a lab that places no live calls.

The four commands below are deliberately minimal and read-only: none of them modifies VICIdial, Asterisk or the database, so they are safe to run against a live system while you are only trying to characterize the host underneath it. The package query shows whichever Asterisk-related package name and version this specific build actually installed — a fact about this host, not a claim about which package name VICIdial requires everywhere.

free -mnprocdf -h /rpm -qa 'asterisk*'

• Do not use swap as a production performance plan.
• Reserve build, update and rollback disk separately from recordings.
• Test after reboot, not only immediately after installation.

Build a transparent monthly cost model

Ask each provider for a dated quote in the intended region and currency. Plan cost as compute + block/object storage + backup snapshots + outbound transfer + IP/IPv6/DNS + monitoring + support + carrier/SMS/compliance services; tax and commitment discounts may change the total.

This page intentionally gives no dollar figure: provider catalogs, regions, included transfer and taxes are volatile. The cited provider pages are starting points, not an endorsement or a checkout quote.

Two line items are easy to forget until the first invoice: outbound minutes billed by your carrier, which are separate from the VPS itself, and the storage growth curve of recordings you are required to retain. Both belong in the same worksheet as compute and storage, not in a separate estimate nobody reviews.

compute_monthlystorage_monthlybackup_monthlyegress_monthlymonitoring_and_supportcarrier_and_compliancecontingency= total_monthly

Size from measured saturation and failure behavior

Run an isolated pilot with representative but synthetic traffic. Track CPU steal, load, memory pressure, database latency, disk input/output (I/O), Real-time Transport Protocol (RTP) quality, registration churn, worker lag, queue behavior, recording backlog and recovery time while increasing one dimension at a time.

Choose capacity with headroom for failover, updates, reporting and abnormal retry bursts. A dialer that merely survives its median load has no margin for an incident or maintenance window. Fill this worksheet before the pilot; blank or unknown values mean the purchase decision should stop, not be guessed.

concurrent_agents = [estimate]peak_dial_attempts_per_minute = [estimate]recording_hours_per_month = [estimate]target_rto = [duration]target_rpo = [duration]unknowns_to_test = [list]

• Before testing, write down the CPU, memory and disk levels that should trigger an alert.
• Run the same test during the busiest expected hour and again after a reboot; compare the results.
• Retain aggregated metrics, not caller or recording identifiers.

Make the purchase reversible

Begin with an approved small pilot and an explicit scale-out or resize path. Confirm snapshot restoration time, volume resizing constraints, support response process and egress rules before committing.

Stop the rollout if measured latency, packet loss, media quality, backup window or restore exercise misses its objective. The independent verification is a fresh load test plus a restore drill, not a provider status page or a successful VM boot.

• Save the dated provider quote and configuration assumptions.
• Restore a test backup to a separate environment and check the database and a synthetic recording before launch.
• After the first invoice, compare each actual charge with its worksheet estimate and update the next month’s budget.