Where does a vulnerability scanner actually put the data it collects about a client's environment? For Vexta, the answer is simple: in a local database on the machine running the scan, not in a cloud service somewhere else. Vexta is VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, and because it stores everything locally by design, only a license key and a hardware identifier ever talk to VITI Security's license server; scan data and findings stay exactly where they were collected.
Why this matters for the data a hunter collects
A scan against a real target produces sensitive material fast: open ports, software versions, exposed credentials, confirmed vulnerabilities, screenshots of admin panels. All of that belongs to whoever authorized the test, and a lot of programs and client engagements have explicit rules about where that data is allowed to sit. A scanner that quietly ships findings to a vendor's cloud, even to power a dashboard, adds a party to that data's custody chain that nobody signed off on.
Self-hosted, local-first storage sidesteps the question entirely. There is no vendor backend holding a copy of a client's findings, because there is no vendor backend in the data path at all. That also removes an entire category of question from a client conversation: nobody has to ask what a vendor's retention policy is, how long they keep a copy of the scan, or who at that vendor could theoretically see it, because the answer is that the data never went anywhere to be asked about.
How does Vexta actually store scan data?
Vexta uses an embedded SQLite database that lives on the same machine the scan runs on. It runs in WAL mode, write-ahead logging, which lets the dashboard read live data while a scan is still writing to the database, so a hunter watching a scan in progress is not stuck waiting for it to finish before seeing anything. Foreign key constraints keep related records, a scan, its assets, and their findings, consistent with each other, and a short busy timeout handles the normal case of multiple parts of the application touching the database at once without one write blocking another indefinitely.
The schema itself is embedded in the binary and applied automatically the first time Vexta runs, and any schema changes in a later version are applied through numbered migrations that run on startup. There is no separate database to install, configure, or patch. Whatever version of the binary is running already knows how to bring its own database up to date.
What does write reliability actually mean here?
Every write goes through transaction support with automatic rollback on error, so a scan that gets interrupted mid-write, a process killed, a machine losing power, does not leave the database in a half-updated state. Either a batch of changes fully lands or none of it does, which matters for something that might be running unattended overnight against a large scope.
That reliability, combined with everything being local, means the database backing a scan is something a hunter can reason about directly: it is a single file on a single machine, it does not depend on a network connection to stay consistent, and it does not depend on anything reachable from outside that machine to keep working. Moving a scan's results to another machine, or archiving them once an engagement closes, is a file operation rather than an export from a service that might change its format or its API later.
What this changes for handling client engagements
For work that comes with a data residency requirement, a client that wants everything kept on infrastructure they control, or a program that specifically forbids sending scan results to third parties, local-first storage is not a nice-to-have, it is often the condition that makes using an automated scanner possible at all. The findings a hunter reports on came from the same machine that ran the scan, full stop.
It also means an engagement's data footprint is exactly as big as the hunter makes it: back up the database file, wipe the machine, hand over the results, and there is nothing else sitting somewhere else that also needs to be accounted for when the engagement closes out. Exact storage and retention behavior can vary by license; see plans on the pricing page for specifics.
Key takeaways
What local-first storage means for the data a Vexta scan produces:
- Scan data, findings, and assets are stored in a local database on the machine running Vexta, not sent to a cloud backend.
- Only a license key and hardware identifier communicate with VITI Security's license server; scan results never do.
- WAL mode lets the dashboard read live data while a scan is still writing, so progress is visible without waiting for completion.
- Transactions with automatic rollback on error keep the database consistent even if a scan is interrupted mid-write.
- The database schema is embedded in the binary and updated automatically through numbered migrations, with no separate database server to install or patch.
Frequently asked questions
Does Vexta send scan findings to the cloud?
What database does Vexta use to store findings?
Can I watch a Vexta scan's results while it's still running?
What happens to Vexta's data if a scan is interrupted?
Do I need to install a separate database for Vexta?
Keep client findings on infrastructure you control
See how Vexta stores every scan and finding locally, with nothing sent to a cloud backend but a license check.