Fully local (no API key) — requires Ollama runtime: https://ollama.com

ollama pull llama3.2 openosint web

☁️ OpenOSINT Cloud — no install, pay per use

Run OpenOSINT tools with zero install as pay-per-use Apify Actors, in your browser or as MCP tools in Claude, Cursor, and Windsurf.

All three are also available as MCP tools with no server to run: https://mcp.apify.com?tools=complete_analogy/openosint-email-recon,complete_analogy/openosint-username-recon,complete_analogy/openosint-domain-recon

Cloud or self-host? Cloud: zero setup, pay per call, hosted by us — cloud usage funds ongoing development of the self-hosted project. Self-host: free forever, your own API keys, full control.

or: pip install openosint && openosint web

Installation

pip (Python 3.10+)

pip install openosint openosint web

Docker

```bash

Build and run

docker compose up --build

Usage

Start the REPL and investigate any target — the agent decides which tools to run and chains them on findings:

openosint > investigate target@example.com

  -> generate_dorks('target@example.com')
  -> search_email('target@example.com')
  Found: Spotify, WordPress, Gravatar, Office365

  -> search_breach('target@example.com')
  Found in 2 breaches: LinkedIn (2016), Adobe (2013)

  -> search_username('johndoe99')   <- pivoted from email findings
  Found: GitHub, Reddit, Twitter

  Report saved -> reports/2026-05-11_14-32-11_report.md

Want the full investigation workflow behind this? → AI OSINT Complete Kit ($55)

Example Domain

This domain is for use in illustrative examples in documents. ```

Quickstart — web UI in one command

Install uv once. It runs OpenOSINT in its own isolated environment, so there is no Python setup:

```bash

Regenerating the demo GIF/MP4

export OPENOSINT_DEMO_KEY=sk-ant-...   # your Anthropic key — never committed
openosint web &                        # start the web server on :8080
make demo                              # record -> encode -> write docs/assets/demo-web-graph.*
git add docs/assets/demo-web-graph.*

See scripts/record-demo/README.md for full prerequisites and pipeline details.

Graph module (optional)

An additive FollowTheMoney entity graph — statement-level provenance, an append-only store, non-destructive same_as deduplication, and a human review queue — sits alongside the tools above without changing anything about them. The store, the /graph page, the /api/graph/* routes and the graph_neighbors / graph_review_candidates MCP tools work in a plain uvx openosint web install, with no compiler and no extra. The graph extra (pip install "openosint[graph]", builds PyICU) adds the real FollowTheMoney library: graph_export and .ftm export. The graph-dedup extra (Python 3.11+) adds same_as scoring. Without the extra, ids are produced by a vendored copy that a CI test proves byte-identical to FollowTheMoney's, so a graph.db is readable either way. Nothing in the web UI or the agent writes to this store: it is filled through the Python API (see docs/graph.md for the full guide and a worked example); the GRAPH tab in the main UI is a separate, client-side view of the current chat.

The same workflow is shown end to end — including the .ftm export that passes ftm validate — in the terminal demo in docs/graph.md; the web UI walkthrough is the demo at the top of this README.

---

Settings -> Ollama (local) -> model: llama3.2

Settings -> OpenAI API

```

Breaking change (v2.28+): key usage now follows bind address, not an env var. Bound to 127.0.0.1/localhost (the default) — no change: keys in your .env work as before. Bound to any other interface (--host 0.0.0.0, which already requires --allow-remote) — the web UI never uses a key from your environment to serve a request; every caller must supply their own, and breach lookups (search_breach) are disabled outright. This applies regardless of any env var, including OPENOSINT_DEMO_MODE, which can only add restriction, never remove it. If you were exposing the web UI on a LAN with your own keys and no per-caller auth in front of it, that access pattern no longer works. Running behind a reverse proxy? A loopback bind (127.0.0.1) only means the OS accepted the connection from this machine — it says nothing about who can reach it if something in front (nginx, Caddy, a Docker/K8s sidecar, a tunnel) forwards requests to it from elsewhere. By default, a request that carries proxy-forwarding headers (X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Host, Forwarded, CF-Connecting-IP) is treated exactly like a non-loopback bind: your local keys are never used, breach lookups are blocked, and the caller is told why. If you deliberately serve this through a reverse proxy and want it to behave like a normal local instance for requests relayed by that proxy, set OPENOSINT_TRUSTED_PROXY=true. This is a separate variable from the existing TRUSTED_PROXY (which only affects which IP a rate-limit bucket is attributed to — a low-stakes, already-loosely-scoped setting some self-hosters already have on). Reusing that flag here would have silently upgraded an existing rate-limit-only configuration into one that also permits credentialed access, without asking. OPENOSINT_TRUSTED_PROXY gets its own explicit opt-in for that reason. Setting it does not blindly trust the forwarded headers' content — internally inconsistent values (e.g. two disagreeing X-Forwarded-Proto values on one request) are still treated as public regardless. Setting OPENOSINT_TRUSTED_PROXY=true means you are choosing to serve credentialed lookups to whoever your reverse proxy relays to this instance — you are the controller for their queries, the same way OpenOSINT Cloud is for its customers. Put real authentication in front of it if "whoever the proxy relays" is broader than you intend.

Configuration

Easiest: open the web UI. On a local install, Settings saves your keys on this computer by default ("Save on this computer"), as does the first-run panel; "Use only for this browser session" is a secondary option that keeps a key in the tab only. On the public demo, keys stay in the browser. Keys are written to config.env in the data directory (~/.openosint/config.env, or $OPENOSINT_HOME/config.env), never inside the installed package, with user-only permissions (0600) where the OS supports it. Values are never logged or sent back to the browser; the UI only shows which keys are configured and where each value came from.

Precedence, highest first:

1. real environment variables (a saved value cannot override one; the UI says so)
2. config.env in the data directory
3. a legacy .env (the locations below)

An existing .env keeps working. If the file at the package root (a source checkout or Docker image) is the one that would be loaded, its known settings are copied into config.env once, with a notice on stderr that names keys but never values; the old file is left in place and now has lower priority.

For a file you manage yourself, copy .env.example to .env and fill in your keys. .env is read from the directory you run openosint from (searched upward, like git finds .git) — it does not need to be at any particular "project root", and a regular pip install works the same way as running from a source checkout. Set OPENOSINT_ENV_FILE=/path/to/.env to point at an explicit file instead (useful for the MCP server, which is launched by its host with an arbitrary working directory). A real environment variable always takes priority over a value in .env.

Required below means required for that specific tool to run, not for openosint itself — the app starts and every key-less tool works with zero configuration.

On a fresh install with no keys at all, these still work: generate_dorks, search_dns, search_whois, search_domain, search_email, search_username, search_paste, search_phone, search_ip (rate-limited), search_github (rate-limited), and search_gdelt_geo.

Web interface

openosint web

Interfaces

OpenAI-compatible endpoint (LiteLLM, vLLM, LM Studio, ...)

export OPENAI_BASE_URL="http://localhost:4000/v1" openosint web

CLI Reference

Integrations

Alternatives

```bash