Deploying NuajLens

/opt/nuajlens/
├── bin/          nuajlens + scan engine
├── nuajlens.conf configuration
└── data/         db, scan logs, templates, cert

Copy that directory and you have copied the install: the asset inventory, the schedules, the scan history, the triage decisions your team made and the certificate the console is served with. Move it to another host with the same package installed and the console comes up where you left it.

Removing the package leaves the directory in place, so a reinstall finds your scan history again. Purging takes everything — which is the point of having exactly one path to purge.

Scanners are often deployed exactly where downloads are not welcome: a management network, a segment behind a jump host, a site whose whole point is that it has no route out. Because every part of NuajLens — the scan engine and its templates included — is inside the package, such a host installs the same way as any other, and the first scan can run before the machine has ever spoken to the internet.

What an isolated host gives up is updates arriving by themselves. Templates change daily and the engine every few weeks, and both normally update independently of the package. On a disconnected host they advance when the package does — and engine-updates = off makes that explicit: it pins the install to the bundled binary and makes the API refuse version changes, restoring the property that every executable the service can run is read-only to it.

On a connected host the scan engine can move forward without waiting for a package release. What arrives from the network still has to earn it. Before a fetched build can become the active engine it must:

• arrive over HTTPS — a redirect off TLS aborts the download;
• match the SHA-256 published in the release checksums;
• unpack under a size ceiling, writing only the path intended;
• report a version matching the release tag;
• parse the installed template set.

Only then does the active pointer move, by atomic rename — a scan starting mid-swap sees one version or the other, never a broken link. Any failure discards the download and leaves the running engine untouched. The bundled engine is never garbage-collected and the service cannot write to it, so a rollback target exists even on a host that has been offline since the day it was installed. Version changes are refused while a scan is in flight, and every scan records the engine that produced it.