Changelog

The terms of service now say two things publishing already does, so publishers know what they agree to.

• An image you push to the registry’s mirror with ot publish --image is hosted and served by the registry, not only kept as a backup, and publishing allows that.
• A namespace made on the registry with ot namespace create is deleted if it has published nothing 30 days after it was created and is still waiting for review.

This page is new: one list of what changed in ot, otlite, the website and the registry, newest first, with Atom and JSON feeds. New tools and their releases stay on What’s new.

• The blog has longer write-ups, starting with an introduction to OTInstaller.
• Both have Markdown versions for agents: /changelog.md and /blog.md, or send Accept: text/markdown.

Every tool page has a Report a problem button. It asks what is wrong and sends it where it can be fixed: signed in, “It doesn’t work”, “It shows an error”, “It’s out of date” and “Something on this page is wrong” each open the right kind of issue.

• Without an account, broken and out of date are counted, once per address a day, with no text. Three reports in a week open an issue for the maintainers, together with the reports ot sends after a failed run.
• Before you write anything, the page lists the open issues of that kind, so you can add yourself to one instead.
• Malware, abuse and legal problems still go privately to the registry’s reviewers.

ot report <tool> opens the same page. See report a problem.

Signed in, you can follow what you care about and hear when it changes, in your inbox and by email as your notification settings say.

• Follow releases on a tool’s page tells you each time a new version becomes its latest.
• Follow publisher on a publisher’s page tells you about every release of its packages, and when it publishes a new one.
• Follow new tools on an input type’s page, such as domain, tells you when a new tool or guide that takes it is published.
• When one release matches several things you follow, you get one item. Nobody else sees what you follow.

Without an account, the same news is in the Atom feeds of a tool, a publisher or an input type.

The registry checks every community wrapper against the project it packages each night, and now acts on it: a wrapper that has been behind an upstream release for three days gets an outdated issue, which closes itself once a version with that release is published. An upstream that was archived, removed, renamed or relicensed gets an issue too.

• First-party tools’ Python dependencies are checked against PyPI the same way, and the tool page lists the ones behind.
• The registry also records the base image each community Docker build starts from, so it can tell when a newer base is out.

See keeping community packages current.

The one-line installer no longer needs Python or pipx on the machine: without them it downloads a pinned uv, checked against its SHA-256, and installs otlite on a Python 3.12 that uv keeps in your home directory, never with sudo.

• otlite check-updates and otlite update say when a newer otlite is out, with the upgrade command for how you installed it (pipx, uv or pip). OTLITE_NO_UPDATE_CHECK=1 turns this off.
• A failed update keeps the version you had, even after Ctrl-C. Before, it left the tool uninstalled.
• Registry entries can carry short notes, such as why a tool needs a particular Python; otlite info lists them.
• check-updates no longer reports an unpinned git tool as outdated when it is at upstream’s latest commit.

On PyPI

ot now tells you when your tools are behind. 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. It never does this in CI, under ot mcp, with JSON output or with OT_NO_UPDATE_CHECK=1.

• Installing an exact version, such as ot install <tool>@1.2.0, holds it there: ot update --all leaves it alone, and naming it with ot update <tool> moves it on and releases the hold.
• ot outdated and ot list mark held packages, and agents never move a version you held.
• The check downloads one list of every package’s latest version, the same for everyone, so it tells the registry nothing about what you have installed.

See keeping tools up to date. Release and downloads

ot publish uploads a release straight to the registry, from your computer or from CI, and ot namespace creates a namespace and manages its trusted publishers. See publishing.

• ot publish --image, --build and --sign push and sign a Docker image on the registry’s mirror; --oidc publishes from GitHub Actions or GitLab CI without a stored token.
• ot issues <tool> lists a package’s issues, and ot report <tool> --works or --broken says whether the version you have works for you.
• When a single ot run fails at a terminal, ot offers to report it as broken. It sends the tool, version, exit code, OS and ot version, never your inputs or output, and asks at most once a week per version.
• ot request <repo-url> asks for a tool to be packaged, or votes for an existing request.
• ot changelog <tool> shows the release notes newer than your version, and ot info shows the latest one’s.
• ot outdated notes when an update is in its first week, with what people have said about it.

Release and downloads

Missing a tool? Tool requests is where you ask for an open-source project to be packaged, and vote for what others asked for. Give the repository’s GitHub or GitLab URL and, if you like, a note on what it finds.

• The registry checks it at once: a project that is already packaged or requested, has its own otinstaller.yaml, can’t be redistributed or is archived gets an answer straight away.
• Each request has a discussion. The person who asked, anyone who replies and anyone who follows it hear about replies and decisions.
• When a package from that repository is published, the request is marked published and everyone who voted is told.

From the terminal: ot request <repo-url>, and --vote for an existing request. See community.

A package page shows what changed in its latest version under “What’s new”, and the Versions tab shows the notes of every version. The registry reads them from the tag’s GitHub or GitLab release, or from the version’s section of CHANGELOG.md; see release notes.

• What’s new lists every new tool and guide, release, yank and deprecation across the registry, newest first.
• Follow the same in a feed reader: /feed.atom (or /feed.json) for everything, or add /feed.atom to a publisher’s address, a tool’s address (its releases, with their notes) or an input type’s page.
• The activity is also an API: GET /v1/activity (registry API).

/learn is a starting point for people new to open-source intelligence: how an investigation runs, keeping yourself safe while you work, the legal and ethical basics, and a reading order through the guides and docs, from beginner playbooks to publishing your own tools.

The guide osint-fundamentals is published alongside it, and the page has a Markdown version, /learn.md.

Every package has a public Issues tab for broken, outdated and wrong-information reports, feature requests and questions. Reading needs no account; posting needs a GitHub, GitLab or OSINTverse sign-in.

• The form asks for version, platform, engine and exit code as separate fields, so you never paste a command line with your target in it.
• It works for me and It’s broken for me count by version and platform. A tool’s status line puts the last 30 days’ counts next to the registry’s nightly health check, in words, never as a rating.
• For a week after a release, the tool page, the versions list and What’s new show what people said about the new version next to the one before it.
• The community board lists what needs a hand, and everyone who takes part has a profile at /people/<handle>.
• Replies and status changes on issues you follow arrive in your inbox, by email within 15 minutes or once a day.

See community and the community guidelines.

You can now publish a tool or guide straight from your computer with ot publish, with no GitHub App, GitLab connection or tag. It uploads the manifest, README, pages and images, and the registry validates, scans and publishes it like any other release.

• ot namespace create <name> makes a namespace to publish into; any signed-in account can have up to three.
• ot publish --image, --image-archive or --build pushes a Docker image to the registry’s own mirror and pins its digest for you, so the image needs no other home. --sign signs it with cosign.
• The first signed version pins its signer, and every later version must be signed the same way.
• A package published this way can move to a repository later: the first tag from a repository in the namespace claims it.

See publish directly.

A release workflow on GitHub Actions or GitLab CI can now publish its own release with ot publish --oidc. The CI’s OIDC ID token proves which repository and workflow it runs in, so there is no GitHub App, GitLab connection or stored token to set up.

• Trust a repository from a namespace you own, on the dashboard or with ot namespace trust <namespace> github:<owner>/<repo>, optionally limited to one workflow, environment or package.
• Set OTINSTALLER_PUBLISH to oidc and the release workflow ot init writes publishes at its last step.
• Each run gets a registry token that lasts an hour and can only publish that package into that namespace.
• ot namespace trusted lists your trusted publishers and ot namespace untrust removes one.

See publish from CI.

A fresh machine gets to a first result faster. When nothing installed takes the target you give ot auto or ot run --all, ot offers the tools of a bundled playbook for that type and installs them on a yes.

• ot install a b c installs several packages in one command and says how to try them.
• New bundled playbooks: email-investigation, phone-investigation and ip-investigation, none of which needs a key. ot playbook --list says what each one takes.
• ot runs lists your saved runs, newest first, or shows one.
• ot outdated flags installs that are deprecated, possibly broken, yanked, moved or whose source is gone, and says when a newer ot is out. ot update installs a renamed package under its new name.
• ot profile shows and edits your publisher profile.

Release and downloads

/otlite lists every tool otlite installs, with filters by what each one takes, and /otlite/tools has a page for each of them.

• A tool’s page shows the install and run commands, and builds the command for a value you type; the value never leaves the page.
• It shows what each typed input becomes on the tool’s command line, any caveats, the keys it needs and how batch runs and playbooks use it.
• When the registry also has the tool as a container package, the page links to it.
• Each page has a Markdown version for agents.

/agents brings together what you need to let an AI agent use the registry: connecting a client to ot mcp or the remote MCP server, what an agent can do, how consent works, and the entry points for programs. Its Markdown version, /agents.md, is written for the agents themselves.

The top navigation now links to otlite and Agents, and the home page no longer scrolls sideways on phones.

openosint and secator take typed inputs, so both work with otlite auto and otlite run --all: u:, e: and d: for openosint, and for secator d: (its domain recon workflow) and u: or e: (its user hunt).

On PyPI

Every namespace has a public profile at otinstaller.com/<namespace>: name, avatar, bio, links, the accounts it publishes from, its numbers, pinned packages and recent releases.

• It fills itself in from the GitHub or GitLab account the namespace belongs to, and refreshes every 6 hours. Email addresses are never copied.
• Owners can change any field, write an About section and pin up to six packages from the dashboard’s Edit profile, or hide the details.
• Agents can read the same profile as Markdown at otinstaller.com/<namespace>.md.

See your publisher profile.

otlite runs on macOS as well as Linux, and installs with one line: curl -fsSL https://get.otinstaller.com/otlite | sh. See otlite.

• otlite keys set NAME saves an API key from a hidden prompt, piped input or --from-env VAR; otlite keys list and otlite keys rm manage them.
• Every run writes <run>.envelope.json, one result shape for every tool: version, input, timing, exit code, status, entities found and the output file.
• The ip: typed input, for SpiderFoot and bbot, and in auto and run --all.
• otlite info shows a runnable example command for each tool.
• otlite doctor ends each problem with the command that fixes it on Debian, Arch, Fedora or macOS.

On PyPI

otlite results lists your saved runs, filtered by tool, target, case, status and age, and sorted by time, tool, target, duration or size, as a table or with --json. The README’s quick start now runs otlite init, not ot init.

On PyPI

The Python tool manager otinstaller is now otlite, the no-Docker edition of OTInstaller for Linux. It installs each tool by name into its own virtualenv and runs it with one command shape; see otlite.

• The package, command, Debian package and man page are called otlite, and its home is ~/.otlite. The first run copies your keys and settings from ~/.otinstaller; install your tools again with otlite install.
• The OTLITE_* environment variables replace OTINSTALLER_*, which are still read until 2.0.
• pip install -U otinstaller keeps working: that name is now a small package that installs otlite.
• otlite is supported, so the end-of-life notice is gone. The ot alias is gone too, since ot is the registry’s CLI.

Versions before 1.0.0 shipped as otinstaller; their notes are in the otlite changelog.

ot keys setup <tool> walks you through the API keys a tool needs: what each one is, what it costs, where to get it, and a prompt that hides what you type. It only runs at a terminal, so an AI agent can hand you the command but never store a key. ot keys set hides typing too.

• For tools that print text or CSV, ot run lists the emails, URLs, IP addresses and domains in the output, marked low confidence, so ot run --all and agents can chain from them.
• ot mcp has a read-only key_setup tool that explains keys without ever showing values, and list_types says what each input type, entity type and category means.
• A consent token that no longer works says why: restarting ot mcp ends them.

Release and downloads

ot mcp is an MCP server for AI agents such as Claude Code, Claude Desktop, Cursor, VS Code, Codex and Gemini CLI. It searches the registry, installs signed tools and runs them in the same sandbox as ot run, and asks you before any run that touches a target, goes online or involves a person. Set it up with ot mcp install <client>; see AI agents and MCP.

• --json (or OT_OUTPUT=json) works on every command that prints data, and errors come as one line of JSON on stderr (scripts, CI and agents).
• ot token makes scoped API tokens, and ot pivot suggests what to run next from a saved run.
• Breaking change for scripts: without a terminal, ot run, ot run --all, ot playbook and ot auto stop with consent_required before running a tool that isn’t passive. Add --yes, or set OT_CONSENT=off where you don’t need the check. Runs at a terminal are unchanged.

Release and downloads

AI agents can now search and read the registry without installing anything. The remote MCP server at https://api.otinstaller.com/mcp answers six read-only tools (search, tool details, input types, pivots and guides); for installing and running, it points agents at ot mcp.

• The agent plugin for Claude Code and Cursor is on GitHub, and both servers are listed in the MCP Registry.
• Every docs, tool and guide page has a Markdown version: add .md to its address, or ask for text/markdown. /llms.txt maps the site for agents.
• The registry API has an OpenAPI description, scoped tokens and rate-limit headers.

Containers now run without a network unless the tool’s manifest says it needs one (network.egress: true). Before, a manifest with no network block ran with the engine’s default network.

• The bundled domain-recon playbook names a tool that is on the registry.
• When Docker is installed but not running, ot install says to start it and exits 5, instead of ending each error with <nil>.

The security model describes the sandbox. Release and downloads

otinstaller.com, the registry API and ot are public, and so is the source code, under the Apache 2.0 licence on GitHub. Anyone can search, install and run what is published, with no account.

• The first tools and guides are published under osintverse-community: tools written for the registry, wrappers of well-known open-source projects, and step-by-step guides.
• Publishers release from GitHub or GitLab with a tag; a new publisher’s first release is reviewed before it goes live. See publishing.
• Every published version is security-scanned and backed up. If the original host later refuses an image or wheel, ot installs the registry’s copy of the same digest instead.
• Bugs and ideas go to OTInstaller/feedback, the feedback page or ot feedback.

The first release of ot, the command-line program that installs and runs tools and guides from the registry the same way on Windows, macOS and Linux. Install it with the one-line scripts in getting started; they check the release’s signature before installing.

• ot search, ot info and ot install find and install tools, pinned by digest and checked with cosign.
• ot run runs a tool in a locked-down container and saves its results. Typed inputs such as u:johndoe or d:example.com pick the right input for you, and --all runs every installed tool that takes them.
• ot auto guesses what a target is and runs the tools that take it; ot playbook runs a named set of tools (domain-recon and username-investigation are bundled).
• ot extract and ot diff read saved results; ot outdated and ot update keep installed tools current.
• ot guide reads guides in the terminal, and ot init, ot validate, ot import and ot release cover publishing.
• ot self-update installs new releases after checking their signature.

Release and downloads