ShadowBroker: A Self-Hosted Map for Public OSINT Telemetry
Open-source intelligence for the global theater. Track everything from the corporate/private jets of the wealthy, and spy satellites, to seismic events in one unified interface. Hook an AI agent up to have it parse through data and find previously unseen correlations. The knowledge is available to all but rarely aggregated in the open, until now.
At a glance
- What is it?
- ShadowBroker aggregates aircraft, maritime, satellite, seismic and CCTV feeds into one self-hosted map with an optional AI agent channel. The design is broad and the licence is AGPL-3.0, but the documentation is a feature list rather than a deployment guide.
- Who is it for?
- ShadowBroker suits engineers and researchers who already run Docker or Python services and want public telemetry on one self-hosted map without accounts. Skip it if you need a hosted service, guaranteed uptime, or a stable protocol for the InfoNet mesh, which the README calls an experimental testnet.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap ShadowBroker fills: scattered public feeds, one screen
Aircraft ADS-B broadcasts, maritime AIS signals, satellite orbital data and earthquake sensors are all public. They are also spread across dozens of separate tools and APIs. ShadowBroker's stated purpose is aggregation: the README describes it as a platform that combines 60+ live intelligence feeds into a single map interface, and explicitly says the project does not introduce new surveillance capabilities. The intended users are analysts, researchers, radio operators, and anyone who wants public signals on one screen. The scope is unusually wide. The README lists 40+ toggleable data layers covering aircraft, 25,000+ AIS vessels, satellites, CCTV networks, GPS jamming zones, power plants, data centers, wildfires, and trains. A project that tries to cover this much surface area usually pays for it in depth somewhere, and the documentation does not make it easy to tell where.
Architecture: Next.js and MapLibre in front, FastAPI and Python behind
The stack is split in two. The front end is Next.js with MapLibre GL for rendering; the back end is FastAPI and Python. The README says the dashboard talks to your self-hosted backend, and that the project has no accounts, product telemetry, or analytics. Two data paths matter. For Shodan and the recon toolkit, the browser calls self-hosted routes such as /api/osint/* and /api/tools/shodan/*, and the backend makes the outbound request after SSRF validation. Recon requires local-operator access, which the README describes as the same trust model as layer toggles and admin routes. Separately, an HMAC-signed agent command channel exposes the same recon backends plus telemetry search, so an agent does not need a separate API integration. The README names OpenClaw and says any agent speaking the protocol (Claude, GPT, LangChain, custom) can connect with full read and write access to the layers, including compact search calls such as search_telemetry and search_news. Read and write access is the part to think about: an agent on this channel can place pins and control the map, not just read it.
Getting it running: what the README does and does not give you
This is where the documentation is weakest. The README names the components and one configuration key, SHODAN_API_KEY, for operator-supplied Shodan access. It does not show a docker compose file, a git clone command, an .env template, or the port the FastAPI service listens on. It does not state Node or Python version requirements. It does mention that SAR ground-change detection needs a NASA Earthdata account, and that live OSINT features make outbound requests to whichever public data providers you enable or query. Treat the repository itself as the setup guide: the file layout will tell you more about how the services start than the README does. If you cannot find the startup path quickly, that is a signal about the project's documentation discipline, not about your ability. One thing the README does make clear: the backend is yours, and operator keys stay in your local deployment.
The InfoNet testnet is the riskiest part of the pitch
The README describes InfoNet as a decentralized intelligence mesh with obfuscated messaging, gate personas, Dead Drop peer-to-peer exchange, and a terminal CLI, and it calls this the first such mesh built into an OSINT tool. It also states plainly that privacy is not guaranteed yet and that this is an experimental testnet. That is an honest disclosure, and it should shape how you treat the feature. A messaging layer whose privacy properties are not yet guaranteed is not a place for sensitive traffic, whatever the obfuscation language suggests. If you adopt ShadowBroker for the map and the recon toolkit, you can leave InfoNet alone. If you adopt it for InfoNet, you are running testnet software and should plan accordingly. The two use cases have very different risk profiles and the README does not separate them.
Where ShadowBroker is the wrong tool
Three cases stand out. First, if you need a hosted service, this is not one: the README says the dashboard talks to your self-hosted backend, so you own the deployment and its uptime. Second, if your work depends on a single feed with deep historical querying, a dedicated tool for that feed will usually beat a general aggregator, because ShadowBroker's value is cross-layer correlation rather than per-feed depth. Third, if you need to hand an agent a narrow, auditable interface, the agent channel's full read and write access to all layers is broader than many security reviews will accept, even with HMAC signing and local-operator auth on the recon routes. The README is also candid that live features make outbound requests to public providers, so an air-gapped deployment is not what this is. The project's own framing is aggregation of existing public data; judge it on that, not on capabilities it says it does not add.
Alternatives and the actual difference in approach
The obvious comparison is to single-domain viewers. Flight tracking sites such as ADS-B Exchange focus on aircraft, marine trackers such as MarineTraffic focus on AIS, and orbital tools such as N2YO focus on satellites. Each does its domain with more depth than a general aggregator can, and none of them tries to put a police scanner, a KiwiSDR node, and a wildfire layer on the same screen. ShadowBroker's difference is the correlation layer: right-click a point for a country dossier and a Sentinel-2 image, or use the agent channel to run search_telemetry and search_news across layers in one call. The trade-off is operational: you assemble and run the stack yourself, and the README does not hand you a deployment recipe. If your question is about one domain, a specialist tool is the better answer. If your question crosses domains, that is the case ShadowBroker is built for.
Maintenance, releases, and the AGPL-3.0 licence
The repository shows a recent release cadence: v0.9.82 in June 2026, v0.9.83 later that month, and v0.9.84 in August 2026, with the last push in September 2026. Version numbers below 1.0 are a fair description of the project's own framing, which includes an experimental testnet and a long feature list. Expect upgrade work: the stack spans Node and Python dependencies, and the README mentions integrations with external providers such as NASA Earthdata and Shodan, each with its own terms. On licensing, the project is AGPL-3.0. That matters if you plan to modify ShadowBroker and expose it to users over a network, because the AGPL's network clause is broader than the GPL's. This is not legal advice; if you intend to run a modified version as a service, read the licence text and talk to someone qualified. For internal use, the practical question is whether your organisation's policy on AGPL dependencies allows it.
Who should adopt it, and what to verify first
Adopt ShadowBroker if you are comfortable running a self-hosted Next.js and FastAPI stack, you want public telemetry from many domains on one map, and you value the agent channel enough to accept its broad access. Do not adopt it if you need a managed service, if you need per-feed depth, or if you want a mesh with guaranteed privacy today. Before committing, verify the pieces the README leaves out: the exact environment variables beyond SHODAN_API_KEY, the Node and Python versions, how the services start, and whether the operator auth on the recon routes is enabled by default in your deployment. Then decide about the agent channel separately from the map. The map is the mature part of the pitch; the mesh is the experiment.
Editorial conclusion
ShadowBroker suits engineers and researchers who already run Docker or Python services and want public telemetry on one self-hosted map without accounts. Skip it if you need a hosted service, guaranteed uptime, or a stable protocol for the InfoNet mesh, which the README calls an experimental testnet. Before adopting, verify the exact environment variable names (the README shows SHODAN_API_KEY but the rest are unconfirmed), the Node and Python versions, and whether the API routes expose operator auth by default.
Community notes