VICIdial cloud vs dedicated server: a testable decision framework

Choose the operating model from measured requirements

Compare both options using the same peak agent count, recording retention period and recovery targets. Ask for separate compute, storage, backup, network and support costs, and mark any missing line as unknown.

Fast answer: cloud and dedicated infrastructure can both host VICIdial, but neither is inherently cheaper, faster or more secure for every workload. Select against your measured call path, administrative ownership, recovery requirements and provider constraints.

Write two recovery targets: the maximum acceptable outage in minutes and the maximum acceptable data loss in minutes. During a restore rehearsal, record elapsed recovery time and the timestamp of the most recent restored record; compare both with those targets. This publication's lab evidence covers a ViciBox 12 lab install and selected CLI/browser checks — see ViciBox 12 Phase 1 lab checklist: ISO boot, target disk and first login. It does not establish general capacity, production availability, cloud pricing or a hosted-versus-dedicated performance winner.

Terms are defined in VICIdial terminology for complete beginners: users, phones, campaigns and leads.

• Prerequisite: write a workload description, name operating owners and state a recovery objective.
• Non-goal: do not infer pricing, capacity, security or availability from the lab.
• Identify who owns OS, database, Asterisk, network and incident response.
• Define measurable acceptance and recovery objectives before procurement.

Map the full call and data path

VICIdial coordinates browser, PHP, MariaDB, Perl workers, Asterisk/AGI and carrier paths. The placement decision must include latency and failure behavior for every dependency, not only the web server or database.

Use this dependency card for each component. OWNER is a team role and TEST is a synthetic acceptance action; neither is a hostname, address or credential. A missing recovery owner is a decision blocker.

Map recordings, backups, report delivery, external APIs, DNS, certificates, SBC/firewall policy and observability. State data residency and cross-region requirements with the responsible privacy, security and legal owners rather than inferring them from a hosting label.

COMPONENT: databaseOWNER: platform teamDEPENDENCY: backup + restoreTEST: isolated restore rehearsalFAILURE ACTION: invoke approved recovery procedureSTOP: owner or recovery action unknown

• Diagram dependencies and trust boundaries.
• Identify single points of failure and owner-controlled recovery actions.
• Ask the provider and carrier for the required ports, source restrictions, transport and media settings; compare both answers before testing.

Run the same acceptance gates in each candidate model

Use equivalent version-pinned deployments and a controlled synthetic campaign to test login, registration, manual or ratio call flow where approved, audio, DTMF, disposition, logging and clean teardown. Measure with a stated method and observation window; do not extrapolate a lab slice into capacity planning.

Add failure tests for a worker restart, database access loss, carrier reachability loss, storage unavailability and a restore exercise. Stop a candidate when it cannot meet a required recovery or security control, even if normal calls work.

• Keep test data and routes isolated.
• Capture aggregate timings and failure evidence without caller or recording data.
• Repeat with the actual carrier and network edge before go-live.

Model cost and capacity from quotes and measurements

Request dated provider quotes and list every included/excluded responsibility: compute, storage, egress, backups, support, network controls, licenses and hands-on operations. Do not publish invented prices or compare plans that have different reliability or support boundaries.

Use the comparison card without entering price figures in the article. QUOTE DATE, TERM and EXCLUSIONS come from the candidate's current written offer; UNKNOWN is not a favorable score. Capacity requires a workload test designed for your dial method, codecs, recording, reports and retention.

MODEL: cloud or dedicatedQUOTE DATE: current written offerTERM: stated termINCLUDED: compute | storage | supportEXCLUSIONS: list from quoteSTATUS: VERIFIED | UNKNOWNSTOP: unlike terms or unknown exclusions

• Keep quote date, currency, term and exclusions in the decision record.
• Use a load-test plan approved for the carrier and environment.
• Ask how capacity can be increased, how data can be exported and what notice or fees apply when leaving.

Decide, rehearse rollback and revalidate

Make the decision traceable: assumptions, test evidence, residual risks, owners and a planned review date should all be visible to the decision-maker. An external assessor should be able to reproduce the acceptance criteria without relying on a vendor promise.

Before moving production, rehearse restore and traffic rollback on the approved deployment. A rollback plan must include configuration, database/schema compatibility, media access and carrier routing—not merely a virtual-machine snapshot.

• Independently verify backup restoration and a controlled failback.
• Re-test after version, carrier, region or architecture changes.
• Do not call a lab outcome an SLA, benchmark or production result.