Docs

Keeping tools up to date

How the registry follows upstream projects, how ot tells you about newer versions, and how to update, hold a version, go back and update on a schedule.

OSINT tools change often: the sites they query change, and their authors fix them. Keeping up has two halves. The registry follows each tool’s upstream project and publishes new versions, and ot tells you when the copies on your machine are behind and updates them through the same checks as a first install.

How the registry follows upstream

• Publishers’ own tools are released from their repositories: a tag or a release upload becomes a new version within minutes, after it is validated and security-scanned.
• Community wrappers (tools packaged under osintverse-community from someone else’s project) pin one upstream release. Every night the registry compares that pin with upstream’s latest release, and the tool’s page says when upstream has moved on. When it is switched on, an outdated issue is filed and a pull request bumps the pin, which a maintainer releases.
• First-party tools (written by the project) pin their Python dependencies in requirements.txt. Every night the registry compares each pin with PyPI’s latest release, the same way, and updates them with a pull request.
• Base images: every night the registry also looks up the base image each build in osintverse-community starts from (python:3.12-slim, alpine:3.22, …). When it has changed since the build and the build’s scan found fixable critical or high vulnerabilities, the registry can rebuild the tool on the newer base, unchanged otherwise, as a new patch version.
• Every new version is built, signed, scanned and smoke-tested before it is published, and the nightly health check runs each tool’s test input again. For a week after a release, its page and ot outdated say how many people found it working or broken.

Finding out

From ot 0.16, ot tells you itself. At most once a day, at a terminal, after a command’s output, it notes how many installed packages have newer versions, and whether a newer ot is out:

note: 2 installed packages have newer versions; `ot outdated` lists them, `ot update --all` installs them

The note never appears in CI, under ot mcp, with JSON output or without a terminal. OT_NO_UPDATE_CHECK=1 turns it off.

To look yourself:

Signed in on the website, Follow on a tool’s or guide’s page, Follow publisher on a publisher’s page and Follow new tools on an input type’s page send you an inbox item and an email for each new version (following). Following a package also tells you when it is yanked, deprecated, taken down or moved, and about security warnings. Without an account, subscribe to a feed: /<namespace>/<tool>/feed.atom (feeds).

Updating

ot update --all
ot update osintverse-community/sherlock

An update goes through the same digest pinning, signature check and trust warnings as ot install. A package that moved is installed under its new name. ot update exits 1 when an update failed.

Holding a version, and going back

Installing an exact version holds it there:

ot install osintverse-community/sherlock@0.15.0

ot update --all leaves a held package alone, and ot outdated and ot list mark it held. Naming it, with ot update <tool> or ot install <tool>, moves it to the latest version and releases the hold. Agents never hold or release a version, and never move one you held.

To go back after an update, find the version you had with ot changelog <tool> --all and install it: that also holds it until you move it on. Only packages installed at an exact version from ot 0.16 on are held; install an older one again to hold it.

Updating on a schedule

ot update --all --json needs no terminal and prints one row per package. It exits 1 only when an update failed, so a scheduled job can alert on that. Docker or Podman must be running when it starts.

With cron on Linux or macOS, give the full path to ot:

0 7 * * 1 /usr/local/bin/ot update --all --json >> ~/ot-update.log 2>&1

On Windows, Task Scheduler runs it while you are signed in:

$a = New-ScheduledTaskAction -Execute "ot" -Argument "update --all --json"
Register-ScheduledTask -TaskName "ot update" -Action $a -Trigger (New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday -At 7am)

In CI, run it on a runner that keeps ot’s data folder between jobs; a fresh runner has nothing installed to update. Results record the version that produced them, so a case can always say which version found what.

Agents

Through ot mcp, list_installed gives each tool’s latest version and whether an update is available, and install_tool on an installed tool updates it after asking: “Update x from 1.2.0 to 1.3.0?”. Approving an install for the session covers that version only.

Privacy

The daily check downloads one list of every package’s latest version, the same for everyone (GET /v1/latest), so it tells the registry nothing about what you have installed. ot outdated, by contrast, asks about each installed package by name, anonymously, without your token.

This page as Markdown.