VICIfast
Feature · Full Server Access

Full Server Access.

Root SSH, your crontab, your recordings folder. You see and touch every file on the box. The platform sets things up; nothing is locked away. If you want to install something we did not anticipate, you install it.
See pricing

7-day free trial · Cancel anytime · Pay with card or USDT

vicifast - full-server-access
$ ssh root@your-sub.vicifast.com
Last login: Fri May 16 14:22 from 198.51.100.5

# you have actual root
[root@your-sub ~]# id
uid=0(root) gid=0(root) groups=0(root)

# your crontab
[root@your-sub ~]# crontab -l
*/5 * * * * /usr/share/astguiclient/ADMIN_keepalive_ALL.pl
* * * * * /usr/share/astguiclient/AST_VDauto_dial.pl
# (you can add your own)

# your recordings, on your disk
[root@your-sub ~]# ls /var/spool/asterisk/monitor | head
20260516-122209_1747142329.0-all.wav
20260516-122214_1747142334.0-all.wav
...
Full Server Access
40smedian deploy time
99.94%fleet uptime · last 30d
6regions live
Auditedevery state change

What you get

The full full server access surface, end-to-end.

Every card below is a shipped capability. Hover for emphasis; click any matching feature for the deep page.

Real root, real SSH

Not a jailed shell. Not a sudo wrapper. Actual root access, with your SSH key, on a regular Ubuntu server. Port 22 answers only addresses you give Admin access in the firewall.

A root console in the browser

Open a root shell from the dashboard without setting up a key. It is an SSH session signed with a short-lived certificate the platform issues, so it helps when your own key or address is the problem - not when SSH itself is down.

Console sessions are recorded

Every session opened from the browser console is saved as a replayable asciinema cast and tied to the dashboard user who opened it. Sessions from your own SSH client with your own key are not recorded - it is your server.

Managed SSH keys, instant revoke

Paste a public key in the dashboard and it is written to /root/.ssh/authorized_keys right away. Keys expire after 30 minutes and can be extended twice, to 90; the owner can mark a key for automation so it stays until revoked. Revoking rewrites the file on the box immediately.

Your crontab survives

Standard VICIdial cron entries are there. You add yours. The platform never overwrites root's crontab - the personalize script no longer reruns on reboot (we fixed that one painfully).

Recordings on your disk

/var/spool/asterisk/monitor - same path VICIdial has always used. We do not pull recordings off the box. If you want them offsite, opt into the External Backups feature.

apt + yum work

Install whatever you need. The platform keeps the VICIdial stack patched; what else is on the box is your call.

Database access on your terms

MariaDB is on localhost:3306 with the asterisk user. Connect mysql / DataGrip / a BI tool. The platform never proxies your DB through itself; reads + writes happen on your box.

Customise dial-plan freely

Drop AGI scripts into /var/lib/asterisk/agi-bin, add includes to extensions.conf. We never touch your custom contexts; only the vicidial_* and outbound_<n> contexts the platform owns are protected from overwrite.

Cloud-init disabled after first boot

No surprise re-running of the install script when you reboot. The platform sets vendor-data to never re-fire - the box stays exactly as you customised it.

Bring your own monitoring agent

Datadog, New Relic, Prometheus node-exporter, custom syslog forwarder - install whatever your ops team standardises on. The platform monitoring runs alongside; conflicts are extremely rare.

No vendor lock-in

Migrate out as easily as you migrated in. Read access to your full vicidial_* schema; we publish the migration-export tooling. You leave with everything, no exit penalty.

A real SSH session. Real root. Your crontab is yours to edit; we will not stomp on it. Your recordings are on your local disk where Asterisk wrote them.

FAQ

Questions worth answering

Your problem to fix - same as a self-hosted box. The browser console gets you a root shell when your own key or address is the problem; it is an SSH session, so it cannot help if SSH itself is down. The daily snapshot is there if you want a fast roll-back.

Every session opened from the dashboard’s browser console is recorded and can be replayed. Sessions from your own SSH client with your own key are not - they go straight to your server.

Restore replaces the whole disk with the snapshot. Anything you did after the snapshot is gone. The daily snapshot timing (03:00 server local) matters here - schedule your risky changes after it.

No, unless you ask us to. The provisioner writes it once at first boot. After that, edits are yours. Trunk-management changes write back via SSH but only touch the specific stanzas they own.

Yes. crontab -e. They are your jobs. We do not run anything against your box that you cannot see in your own crontab.

Real root. Your crontab. Your recordings.

Start the trial. Day-zero SSH access with your own public keys, or a recorded root console in the browser. Customise dialplan, install monitoring agents, query MariaDB directly - the box is yours.

All features