Updating Exovo
Exovo updates the whole stack together — telephony core, web console and supporting services move as one set of container images, so versions can never drift apart. Updates are checked and applied from the web console; the heavy lifting happens on the host using the same deploy script an operator would run by hand.
How updates work
Every day (and whenever you click Check for updates) the system compares the image digests running on your host against the Exovo registry. Access to the registry is authenticated with your license key — the same credential the installer used — so an active license is what enables updates.
When newer images exist, a banner appears on the admin dashboard.
Checking for updates
Admin → Dashboard → Updates lists each service with its running and latest version (build revision and date). A service can be:
- Up to date — running image matches the registry.
- Update available — the registry has a newer image.
- Pending apply — a newer image was pulled but the container hasn't been recreated yet (finishing the update resolves this).
Applying an update
Click Update and review the confirmation dialog. It tells you what the restart will actually mean for calls:
- If the telephony core is in the changed set, active calls will drop — the dialog shows the live active-call count so you can pick your moment.
- If only the web console or supporting services changed, existing calls continue; new calls may fail for roughly 15 seconds while the console restarts.
If remote backup storage is configured you can tick back up first, which runs a backup before anything is touched.
The update then runs on the host, not inside a container: the console drops a request marker, and the host-side updater (installed during onboarding) refreshes the deployment configuration, pulls the new images, recreates the changed services and prunes old images.
Monitoring update progress
The Updates page tails the update log live. When the web console itself is replaced mid-update,
your browser briefly loses connection and reconnects to the new version — the page picks the
status back up and finishes the story. The full log is kept at /var/lib/exovo/update/update.log.
If the update sits queued for more than about 90 seconds, the host watcher isn't running — SSH to
the host and run sudo ./install.sh from /opt/exovo once to (re)install it.
If an update fails
The update aborts before touching running services if an image pull fails, so a failed update leaves the previous version running — check the log on the Updates page for the reason (usually the host can't reach the registry, or the license has lapsed). An update that applied but misbehaves is rolled back by restoring a backup onto the previous images; this is rare, and the back up first option exists exactly for it.
Updating manually from the command line
The console flow is a wrapper around the standard deploy script. On the host:
cd /opt/exovo
./deploy.sh
That authenticates to the registry with your license key, refreshes the compose file and host scripts from the release bundle, pulls the latest images and recreates changed services — safe to run at any time.