Skip to content
Telebyte

13 May 2026 · 11 min read · By Telebyte Solutions

Hosting ViciDial on Contabo VPS in 2026: A Complete Guide

A practical, opinionated walkthrough of running production ViciDial on Contabo VPS infrastructure — sizing, hardening, SIP trunk configuration, call-recording compliance, and the gotchas Telebyte sees most often in UK deployments.

ViciDial is twenty-five-year-old technology, and that is part of why it still wins. It runs on commodity Linux, talks SIP to any sensible carrier, scales horizontally when it has to, and — crucially — there is no SaaS vendor sitting between the operator and the dialplan. For UK contact centres that want predictable cost, predictable behaviour, and a stack they can actually fix at 2am, self-hosting on a dedicated VPS is the cleanest answer.

This article walks through the exact configuration Telebyte runs in production for its own reference deployment and for client installations. Every recommendation here is in use today on at least one live UK contact centre floor.

Why Contabo

Contabo is not the only credible VPS provider, but it is the one Telebyte defaults to for new ViciDial deployments. The reasoning is mundane:

  • Dedicated vCPU, not shared. ViciDial workloads are bursty — the call-load curve in a UK outbound campaign is steep — and a noisy-neighbour problem on a shared-CPU host shows up as transcoding stutters and call quality complaints.
  • NVMe storage at sane prices. Recording archives accumulate quickly; an 8-agent floor will generate roughly 60–90GB of WAV per month at default ViciDial settings, before any compression.
  • UK-adjacent data centres. Contabo's Düsseldorf and London regions both put SIP RTT into the 15–30ms band from most UK carriers, which is comfortably below the threshold where call quality starts to be perceived as off.
  • Honest pricing. The advertised price is the price. No "starting from" footnotes hiding setup fees.

There are credible alternatives — Hetzner is a strong like-for-like, OVH works fine if you accept the worse support experience, and a properly-specified UK Bytes box will do the job too. The pattern below works on any of them.

Sizing the box

ViciDial's resource appetite is dominated by three things: concurrent calls, concurrent agents, and call-recording write throughput. The CPU draw of the dialler service itself is modest; the cost centre is Asterisk handling RTP streams and writing recordings.

Telebyte's recommended starting specs:

| Concurrent calls | vCPU | RAM | Storage | Suggested Contabo plan | |---|---|---|---|---| | Up to 10 | 8 | 30GB | 1.2TB NVMe | Cloud VPS L | | Up to 25 | 12 | 48GB | 2TB NVMe | Cloud VPS XL | | Up to 50 | 16 | 60GB | 2.4TB NVMe | Cloud VPS XXL | | 50+ | Separate dialler and recording servers | — | — | Two boxes, splitMariaDB |

The 50+ case is the point at which a single-box deployment stops being the right shape. Beyond that, Telebyte splits the dialler floor and the recording archive into separate machines, with the database either on a dedicated MariaDB instance or, for larger floors, on a managed Postgres-fronted MariaDB cluster.

Provisioning Ubuntu 24.04

ViciDial supports several base distributions. Telebyte standardises on Ubuntu 24.04 LTS for the obvious reason: long support window, sane systemd integration, security updates that ship reliably, and no surprises with Asterisk 18 packaging.

Two practical points at provisioning time:

  • Partition layout matters. Default Contabo images give you one big root partition, which is fine until the recording archive eats the disk and takes the dialler down with it. Telebyte's standard is a 40GB root and the remainder mounted at /var/log/asterisk/recordings as a separate ext4 volume, so a runaway archive can't take out /.
  • Set swap to RAM size, not half. ViciDial's MariaDB workload occasionally spikes well past steady-state; a generous swap stops the OOM killer reaching for asterisk first, which is exactly the wrong outcome.

Once the OS is installed, run the standard preliminaries before anything else: apt update && apt full-upgrade, set the hostname to something memorable, configure UK locale and Europe/London timezone, and enable unattended security updates with unattended-upgrades. The full configuration Telebyte uses is in the AUP as far as policy goes; the operational details are below.

Hardening before ViciDial goes near it

Every Telebyte-managed box gets the same hardening pass before a single line of ViciDial code is downloaded:

# SSH: key-only, non-standard port, no root login
sed -i 's/^#Port 22/Port 22022/' /etc/ssh/sshd_config
sed -i 's/^#PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i 's/^#PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart ssh

# UFW firewall: deny by default, allow SSH and SIP only from known origins
ufw default deny incoming
ufw default allow outgoing
ufw allow 22022/tcp
ufw allow from <SIP-TRUNK-IP> to any port 5060 proto udp
ufw allow from <SIP-TRUNK-IP> to any port 10000:20000 proto udp
ufw enable

# fail2ban: stop the SSH and SIP brute-force baseline
apt install -y fail2ban

The single biggest mistake Telebyte sees on inherited installations is leaving SIP on 0.0.0.0:5060 open to the internet. UDP/5060 attracts thousands of registration attempts per hour from the public internet; even when those attempts fail, the parse load on Asterisk is non-trivial and the log volume is brutal. Lock SIP down to your carrier's IP ranges. Every reputable UK SIP provider — VoipTalk, Gradwell, Magrathea, Sipgate — publishes its egress IPs.

The agent web interface goes on a separate port (typically 443, behind Let's Encrypt) and is allowed only from operational IP ranges where practical.

Installing ViciDial

There are two routes: the ViciBox installer ISO, which gives you a complete Vicidial-tuned OS image, or a from-scratch install on Ubuntu using the official upgrade scripts. Both are valid. ViciBox is faster; the from-scratch route gives more control over baseline OS state.

Telebyte uses the from-scratch route on production deployments because:

  1. The OS hardening above has to be applied either way; doing it on a clean Ubuntu install is simpler than retrofitting onto ViciBox.
  2. Future kernel and security updates from Ubuntu come through cleanly.
  3. There's less surprise about what packages are installed.

The from-scratch route involves installing MariaDB, Apache, PHP, Asterisk 18, then pulling the latest stable ViciDial release and running the install scripts in order. The current scripts are well-maintained and largely just work. The two things to watch are PHP version compatibility (8.1 is the sweet spot at time of writing) and the database character set — set utf8mb4 from the outset rather than retrofitting later.

Asterisk 18 specifics

ViciDial supports several Asterisk versions; Asterisk 18 LTS is the right choice in 2026. It is supported through 2027, has a mature codec set, and the SIP-channel driver behaviour is well understood by every UK SIP provider.

Three configuration points that Telebyte changes on every install:

  • maxfiles in asterisk.conf — increase to at least 16384. The default leaks file descriptors on busy floors.
  • RTP port range — keep it tight (rtpstart=10000, rtpend=20000 is a sensible default) so the firewall rules above remain manageable.
  • sip.conf peer trust settings — trust_id_outbound=yes and sendrpid=pai are required for most UK carriers to honour an outbound CLI. Without them, your dialplan-set CLI gets rewritten by the carrier and dispatched callees see your trunk's headline number instead.

SIP trunk configuration: VoipTalk

VoipTalk is Telebyte's default SIP provider for UK outbound — sane pricing, responsive support, and they have done enough UK ViciDial integrations not to need walking through the basics. The same pattern applies to other UK providers; the directive names are the same.

A working VoipTalk sip.conf peer looks like this:

[voiptalk]
type=peer
host=sip.voiptalk.org
fromuser=  ; leave blank — dialplan sets the From URI
fromdomain=sip.voiptalk.org
defaultuser=YOUR_USERNAME
secret=YOUR_PASSWORD
context=trunkinbound
insecure=invite,port
canreinvite=no
nat=force_rport,comedia
qualify=yes
disallow=all
allow=alaw
allow=ulaw
trust_id_outbound=yes
sendrpid=pai
register => YOUR_USERNAME:YOUR_PASSWORD@sip.voiptalk.org

Three points on this configuration that trip up most installs:

  • fromuser= is blank by deliberate choice. Many install guides set it to the trunk username, which then locks the outbound From URI to that username and prevents per-campaign CLI rewriting. Leave it blank and let the ViciDial dialplan stamp the correct CLI for each campaign.
  • canreinvite=no is required for any deployment where the recording engine needs to see all RTP. ViciDial's recording is built on RTP capture; if Asterisk re-INVITEs to bridge the call media end-to-end, recording silently breaks.
  • disallow=all then allow=alaw, ulaw is the right codec stance for UK calls. G.722 and Opus are sometimes available but cause more headaches than they're worth for a contact-centre context where call quality is already gated by mobile-network conditions.

Call recording and FCA compliance

ViciDial records to WAV at 8kHz mono by default. For an FCA-regulated operation, the raw recording is only the start; what makes recording compliant is everything around it.

Telebyte's standard call-recording stack:

  1. Recording stored on a separate volume, mounted with noatime to reduce write amplification.
  2. Encryption at rest using LUKS on the recording volume, with the unlock key in HashiCorp Vault or AWS Secrets Manager (not on the host).
  3. Retention policy — recordings older than the configured retention window are purged on a nightly cron, with a separate "legal hold" flag in the database that prevents purge for any specific call under active complaint, FOS, or regulatory request.
  4. Indexed by phone_number, agent_id, disposition, call_date in the recording_log table — this is what makes the "find that call from 2021" lookup take seconds rather than hours.
  5. Transcript indexing (optional but recommended) — Whisper transcription against a MariaDB FULLTEXT index turns "find any call where the customer said 'cancel'" into a SQL query. Telebyte runs this across 9 million recordings on roughly £200/month of GPU-accelerated VPS capacity.

The FCA's expectation for regulated firms is that any specific call can be produced within minutes for a compliance request. The above stack meets that bar. A recording archive on a NAS without indexing does not.

For a deeper treatment of the regulatory side, see the FCA Call Recording Checklist — fourteen pages, free, no signup wall.

SSL on the agent interface

The ViciDial agent web interface defaults to plain HTTP. That is fine for a development install and indefensible for production. Telebyte's standard is Let's Encrypt with Certbot, auto-renewing weekly, on a vanity domain (agents.yourcompany.co.uk) pointing at the dialler:

apt install -y certbot python3-certbot-apache
certbot --apache -d agents.yourcompany.co.uk \
  --non-interactive --agree-tos -m ops@yourcompany.co.uk

If the agent interface is exposed to the public internet at all (rather than via VPN), enable HTTP basic auth on top of the application login as belt-and-braces against credential-stuffing attacks. ViciDial's session handling is fine; defence in depth costs nothing.

Backups

ViciDial state lives in three places: the MariaDB database, the recording archive, and /etc (Asterisk and ViciDial configuration). All three need backing up; the cadences differ.

Telebyte's standard:

  • Database: full mysqldump every night, plus binary log shipping during the day. Recovery objective is no more than 15 minutes of data loss.
  • /etc: full snapshot weekly, plus a diff every time the configuration is touched.
  • Recordings: rsync to Contabo Object Storage (S3-compatible) nightly, with server-side encryption. Local recordings older than 90 days are then purged from the dialler host to reclaim NVMe.

All three live in a separate region from the dialler. The Contabo Object Storage in their EU2 region works well for a Düsseldorf-hosted primary; for a London primary, use the Hetzner Storage Box in Helsinki or AWS S3 in eu-west-2.

What to monitor

Most ViciDial outages do not begin as outages. They begin as quiet degradation — a slow SIP timeout, a database lock contention, a recording disk filling up — that eventually crosses the threshold into a customer-visible incident. Catching the early signal is what makes the difference between a non-event and a Friday-afternoon scramble.

Telebyte's monitoring baseline for every managed dialler:

  • Server-level: CPU, RAM, swap, disk on every mountpoint, load average. Alert when any disk is above 80%.
  • MariaDB: connections, slow queries, replication lag (if applicable). Alert on slow-query count rising sharply.
  • Asterisk: registered peers, active channels, RTP streams. Alert when registered peers drop unexpectedly.
  • ViciDial: agents logged in, calls in queue, hopper depth. Alert when hopper is empty mid-campaign.
  • Network: SIP RTT to each configured carrier. Alert when sustained RTT crosses 80ms.

Prometheus plus Grafana, with a small Asterisk AMI exporter, covers all of the above for under an hour of setup time per box.

Common gotchas

A short list of the issues Telebyte sees most often when picking up an inherited ViciDial install:

  • CLI being rewritten by the carrier. Nine times out of ten it's fromuser set in the SIP peer config, locking the From URI. Drop it.
  • Silent calls being recorded. Nearly always canreinvite=yes on the SIP peer, which lets Asterisk bridge media end-to-end and bypass the recording engine.
  • Dropped calls under load. Usually maxfiles not raised. The Asterisk process leaks file descriptors and the kernel eventually starts denying new opens.
  • Outbound calls connecting then dropping after 2 seconds. Almost always an RTP firewall problem — UFW rules need to permit the carrier's RTP range, not just SIP signalling.
  • Hopper running dry. Usually a list-loader misconfiguration rather than a dialler problem. ViciDial's hopper-feeder cron must be running, and the campaign filter must actually match contacts in the list.

When to managed-host instead

This article is a working playbook for self-hosting. It does not cover everything you need to operate a managed ViciDial install — incident response, on-call rotation, FCA-aware change control, multi-region failover, recording-archive lifecycle management. For UK firms that want the technical outcome of a self-hosted dialler without the operational overhead, Telebyte's Managed Dialler tiers exist for exactly that reason.

The deciding factor tends to be team composition. If you have a Linux-comfortable engineer with at least working Asterisk knowledge, self-hosting on the spec above is straightforward and saves the management margin. If you don't, the cost of building that capability in-house is almost always higher than the managed tier — and the failure modes during the build-up period are exactly the ones where regulated firms can least afford to be learning.

Either way, the underlying stack is the same. The decision is about who runs it day-to-day, not about whether the foundations are sound. They are.

Want help applying any of this to your own installation? Tell Telebyte what you're working with — one working day to a straight answer.

vicidialcontaboubuntuasteriskhosting
← Back to all articles

Want help applying this to your own stack?

Tell Telebyte what you’re trying to do. One working day to a straight answer.

Start a conversation