Guide

Self-Hosted Secret Scanning, Done Right

Your code contains credentials. Your scanners need to see that code to find them. If a SaaS tool can't, won't, or isn't allowed to — regulated industry, air-gapped network, plain old data policy — you don't have to choose between scanning and control. You can run the whole stack yourself.

Self-hosted secret scanning used to mean a trade: a thin CLI tool that matched regexes and dumped a list of "maybe" findings on an engineer's desk. The real capabilities — AI triage, credential verification, dashboards, governance — lived in hosted platforms, because vendors kept them there. That trade is no longer forced. A modern self-hosted platform can ship every feature in one repository, run its AI on models you control, and even operate with no outbound network at all. This guide explains what self-hosted secrets detection should look like in practice, what to look for when choosing one, and how to get Vooda running on your own hardware.

Why teams self-host secrets detection

The reasons differ by organization, but they converge on one thing: control over where code and credentials go.

What a self-hosted scanner should actually include

Self-hosting the shell of a product while the interesting parts stay cloud-side is the old trick — the "community edition" with the ee/ directory locked away. When you evaluate a self-hosted secrets platform, the questions below separate a real product from a hosted demo that runs on your hardware.

Running Vooda self-hosted

Vooda is built for exactly this. Every feature is in the repository — the full scan engine with 900+ rules across 53 detector modules, AI triage with confidence scoring, credential verification, NHI governance, SSO, compliance reporting. There is no ee/ directory and no license key. You need Docker. That's it.

# clone the repository
$ git clone https://github.com/virantisofficial/vooda.ai
$ cd vooda.ai
# run the installer
$ chmod +x install.sh && ./install.sh
✓ Vooda installed & running

The installer brings up the web UI, API, and CLI. Prefer scanning from the command line? The CLI ships as a container — build it once, alias it, and scan your working tree, full git history, or emit SARIF for CI:

$ vooda scan . # working tree
$ vooda scan . --history # full git history
$ vooda scan . --format sarif # for CI

AI triage without sending code anywhere

AI triage is the difference between a queue of findings and a queue of decisions. It reads each hit in context and classifies it as a true or false positive with a confidence score, then learns from your team's triage to suppress the noise patterns you've already seen. The question for self-hosters is where that model runs. Vooda answers with bring your own model:

If Vooda runs in Docker and your model runs on the same host, reach it as http://host.docker.internal:11434, not localhost — a small detail that saves an afternoon of debugging.

Going fully air-gapped

For a genuinely isolated deployment, two settings matter. First, point triage at a local model, as above. Second, switch off outbound credential verification:

VERIFICATION_ENABLED=false
# scans still complete; findings stay "not_validated"

Verification is a real capability — a revoked key and a live production key are not the same emergency — but in an air-gapped network, no outbound call is the correct default. The scanner still detects; the findings just carry an honest "not validated" label until a human (or a jump box) confirms them.

The license, in plain terms

Vooda is source-available under FSL-1.1-ALv2 — the Functional Source License 1.1 with an Apache 2.0 future grant. We don't call it open source because technically it isn't, and pretending otherwise would be dishonest. What it actually means:

Self-hosting is a legitimate way to use Vooda forever — free, in production, at a company of any size. What's sold is the operational burden of running it: managed hosting, continuously delivered detection updates, hosted verification at scale, and SLA-backed support.

Frequently asked questions

Can secret scanning run fully self-hosted?

Yes. A self-hosted secrets platform runs detection, AI triage, and verification on infrastructure you control. With Vooda, every feature ships in one repository — there is no crippled community edition — and AI triage can run against a model you host, so no code leaves your network.

Can secrets detection work in an air-gapped environment?

Yes, with two configuration choices. Point AI triage at a locally hosted model such as Ollama or vLLM, and set VERIFICATION_ENABLED=false so the scanner makes no outbound credential checks. Scans still complete; findings are marked as not validated.

What is bring-your-own-model secrets detection?

BYOM means the AI layer that classifies findings runs on a model you choose and host — Ollama, vLLM, LM Studio, LocalAI, or any OpenAI-compatible server — instead of a vendor's cloud model. Frontier APIs and gateways such as Azure OpenAI or AWS Bedrock are also supported.

Is self-hosted secret scanning actually free?

With Vooda, yes. The FSL-1.1-ALv2 license allows use at work, in production, at any company size, for free, forever. Commercial licenses apply only to reselling it or offering it as a hosted service. Every release converts to Apache 2.0 two years after publication.

What do I need to run Vooda self-hosted?

A machine with Docker. Clone the repository, run the install script, and the platform is up: web UI, API, and CLI. For AI triage you can connect a local model such as Mistral Small 24B through Ollama, or a frontier API key.

Run it on your own hardware tonight

Every feature, one repository, no license key. Clone it, install it, and scan your first repo in minutes — your code never leaves your network.