How Vexta's Update System Keeps Your Scanner Current

Vexta is VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, and its over-the-air (OTA) update system is how the single self-hosted Vexta binary stays current without you tracking release notes by hand. Vexta checks for updates in the background every 24 hours, and you choose which channel it checks against: stable, beta, or dev.

How often does Vexta check for updates, and what are the channels?

The background check runs on a fixed 24-hour cycle, so a new build does not go unnoticed for long once it is published. Channel selection is what decides which stream of releases that check is watching: stable, beta, or dev. Picking a channel is an operator decision, not something Vexta decides for you, so a team running Vexta against live client engagements can choose to sit on the channel that matches how much risk they want to take on a given build.

This is a small mechanism, but it is the kind of thing that is easy to overlook until it is missing. A self-hosted scanner that never checks for updates on its own becomes a scanner someone has to remember to update by hand, on top of everything else that already competes for attention during an engagement week. A 24-hour background check takes that off a hunter's mental list without taking the decision of when to apply a build out of their hands.

Why does Vexta separate auto-download from applying an update?

Vexta can auto-download a new build once one is available on the selected channel, but applying it is kept as its own, separate manual step. That split matters more than it sounds for a tool that is often mid-scan against a live, authorized target. A background download landing on disk does not force a restart, and it does not interrupt whatever the binary is doing at that moment. You decide when the moment is right to apply it, which in practice usually means between engagements or during a planned maintenance window rather than in the middle of a scan window a client is paying for.

This is also consistent with how Vexta runs generally: as a single self-hosted binary where scan data and findings stay on the machine it runs on. The update mechanism does not change that model. It only touches the binary itself, on the schedule and channel you set, and only reaches its next state, applied and running, when you tell it to.

How does this relate to keeping vulnerability templates current?

Vexta ships with 10,000+ CVE templates bundled in the binary alongside a local NVD mirror, which is part of what lets it run air-gapped. Keeping that template set current is a related but separate concern from the OTA system: Vexta exposes a template status check and a force-refresh action that pulls a fresh template set independent of a full binary update. In other words, a hunter has two distinct levers, one for the scanning engine and reporting layer itself through OTA channels, and one for the CVE template data those checks run against, rather than a single update that bundles both together on the same cadence.

Which channel should a team running client engagements pick?

The naming does most of the work here. Stable is the channel to run against paying engagements where you want the build that has already been through a full release cycle. Beta and dev exist for teams that want to try a newer build ahead of its stable release, whether that is to get an early look at a fix or a feature, or simply to test it internally before rolling it out to the rest of a team's fleet of Vexta instances. Nothing stops a team from running stable on the boxes doing client work and dev or beta on a separate instance used for internal testing, since channel selection is set per installation rather than globally.

That per-installation control also means a team is never forced onto a single update posture across every environment. A lab machine used to try new checks can track dev, while every box that touches a live scope stays on stable, and the 24-hour check runs independently on each one against whichever channel it was set to.

What does this mean for a restricted or air-gapped deployment?

Because Vexta can run air-gapped, the OTA system and the template refresh are two optional, operator-controlled touches to the outside world rather than something the binary insists on doing. Channel selection decides what a check would find if you let it run; the split between auto-download and manual apply decides whether and when that update actually changes the running binary. For a team operating in a network with restricted outbound access, that combination means the update system does not have to be an always-on background dependency, it is something you can schedule around your own change windows instead of the vendor's release calendar.

Key takeaways