Treating a cloud VICIdial box as rebuildable

On physical hardware, losing a server is a serious event. On a cloud VPS, it can be a five-minute operation — if you designed the setup to allow it. The key shift is treating the server as disposable and keeping everything that matters either in version control, in a Server snapshot, or in off-box storage.

This post covers the practical steps to make a VICIdial cloud box fully rebuildable, what to store where, and how the Factory reset concept fits into normal operations.

What makes a box hard to rebuild

Most VICIdial boxes accumulate undocumented configuration over time. A Trunk was added directly in the VICIdial web UI and never captured in a config file. A custom Dialplan extension was pasted into extensions_custom.conf and never backed up. An agent Phone registration string was hand-edited. The Conf file for a carrier was tweaked in pjsip.conf directly rather than through VICIdial's admin interface. Each of these undocumented changes makes the box harder to reproduce.

The goal is to eliminate this drift by ensuring that everything needed to rebuild is either in the database (which gets backed up nightly) or in a tracked configuration file.

What to keep off-box

flowchart TD
  A[VICIdial Box] --> B[VICIdial DB]
  A --> C[Call recordings]
  A --> D[Custom conf files]
  A --> E[SSL certs]
  B --> F[Nightly mysqldump to object storage]
  C --> G[Daily sync to object storage]
  D --> H[Git repo or config backup]
  E --> I[Let's Encrypt auto-renews on rebuild]
  F --> J[Off-box backup]
  G --> J
  H --> J
  J --> K[Rebuild from scratch in minutes]

Three categories of data need to be off the box before you can treat it as disposable. First, the VICIdial database: a nightly mysqldump to an S3-compatible bucket covers campaigns, agent records, leads, and call logs. Second, Call recording files: the /var/spool/asterisk/monitor/ directory should sync to object storage continuously or on a short schedule. Third, any custom configuration that is not regenerated on install: extensions_custom.conf, custom MOH files, and any scripts in /usr/local/bin/ that your center depends on.

The rebuild path

With the above in place, a full rebuild from scratch looks like this: Provisioning a new VPS with the standard VICIdial install (on VICIfast, this takes under 40 seconds), then restoring the database from the nightly backup, syncing recordings back from object storage, and applying any custom configs from your backup. The box comes back to the same functional state it was in at the time of the last backup.

This is different from restoring a Server snapshot, which is faster but keeps everything on the same provider's storage. A from-scratch rebuild is slower (30 to 90 minutes including data restore) but survives a datacenter-level event and works across providers. The two approaches are complementary: use snapshots for quick recovery from routine failures, and use the from-scratch rebuild path for worst-case Failover.

Factory reset in VICIfast

VICIfast includes a Factory reset operation that wipes the server and reprovisioning it from scratch, retaining the same Branded subdomain and DNS record. This is useful when a box has drifted too far from a known-good state and a clean install is faster than diagnosing the issue. Before triggering a factory reset, the platform takes a final snapshot so you have a fallback. For a deeper look at snapshot and backup strategy, see snapshots and backups for a cloud VICIdial box.

The Single tenant Managed hosting model on VICIfast means each customer has their own isolated box, so a reset on your server never affects anyone else. The broader case for running VICIdial in the cloud is covered in the VICIdial cloud guide.

If you want a managed setup where backup, snapshot, and factory-reset are built in from day one, see the options on the pricing page.