Reader setup
Before you choose
List your constraints, required evidence and stop rules before you score options.
- A workload description
- Whoever will operate the server day to day, even if that is only you
- A recovery objective
- What you will prove
- A testable hosting decision record.
- Safety boundary
- No pricing, capacity, availability, or security outcome is inferred.
Reader path
How to use this article
- Use it when: You are comparing options and need decision evidence before approval.
- Expected result: Turn options into explicit acceptance criteria and documented stop conditions.
- Start here: Score what is mandatory, keep unknowns visible, then decide only when risks are understood.
Choose the operating model from measured requirements
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.
A recovery objective is the agreed time and data-loss boundary after a failure. This publication's lab evidence covers a ViciBox 12 lab install and selected CLI/browser checks — see vicibox-12-phase-one-lab-checklist. 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.
- 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.
Visual walkthrough
Follow three real demo screens
Captured on an isolated VICIdial demo: Administration screens on September 24, 2026, and the idle Agent screen on August 11, 2026. Each caption states its own capture time, and every sanitized image helps you recognize a related screen; none proves that this article's call, command, or result occurred.Start at Administration home
Use the Administration menu as a map
Confirm version and system-wide context
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.
- Diagram dependencies and trust boundaries.
- Identify single points of failure and owner-controlled recovery actions.
- Confirm provider network and carrier edge requirements.
COMPONENT: databaseOWNER: platform teamDEPENDENCY: backup + restoreTEST: isolated restore rehearsalFAILURE ACTION: invoke approved recovery procedureSTOP: owner or recovery action unknownThis sample is a template or reading aid, not a terminal command. There is no output to show.
- Before you run it
- Copy for each dependency; replace component and owner with non-sensitive operational labels.
- Success looks like
- Each component has an owner, recovery action and isolated test.
- Stop if
- Stop selection when a required dependency has no accountable recovery path.
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.
- Keep quote date, currency, term and exclusions in the decision record.
- Use a load-test plan approved for the carrier and environment.
- Review growth and exit/migration constraints.
MODEL: cloud or dedicatedQUOTE DATE: current written offerTERM: stated termINCLUDED: compute | storage | supportEXCLUSIONS: list from quoteSTATUS: VERIFIED | UNKNOWNSTOP: unlike terms or unknown exclusionsThis sample is a template or reading aid, not a terminal command. There is no output to show.
- Before you run it
- Copy from a current written quote; use labels only and keep actual prices in the private procurement record.
- Success looks like
- Comparable terms and exclusions are verified for both options.
- Stop if
- Stop comparison when a material inclusion, exclusion or term is unknown.
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.
Evidence ledger
Verification basis
- This publication's evidence includes a repeatable ViciBox 12 lab build and selected Agent and WebRTC checks on that lab; no capacity benchmark is implied.
- No capacity benchmark, price comparison, SLA assessment or production hosting test supports a universal recommendation.
Primary references
Sources
- VICIdial DocumentationVICIdial · accessed September 23, 2026
- VICIdial PJSIP SupportVICIdial · accessed September 23, 2026