World Monitor: self-hosted global intelligence dashboard

What World Monitor actually solves, and for whom

Most monitoring setups end up as a wall of browser tabs: one for wire copy, one for a map, one for market data, one for a ship tracker. World Monitor's stated goal is to collapse those into one interface. The README describes it as a "real-time global intelligence dashboard" combining AI-powered news aggregation, geopolitical monitoring and infrastructure tracking, and the feature list backs that up with curated news feeds synthesized into briefs, a dual map engine, cross-stream correlation across military, economic and disaster signals, a Country Instability Index, and a finance radar covering exchanges, commodities and crypto.

The audience is narrower than the feature list suggests. This is for people who already know which feeds matter and want them in one place: analysts, journalists covering a region, researchers, and engineers building tooling on top of the data. It is not a consumer news app. The panel inventory, the CII scoring and the map-layer catalog assume a user who wants to compare signal sources rather than read a summary.

The single-codebase design is the most interesting structural choice. Six site variants (world, tech, finance, commodity, happy, energy) and the desktop binaries all build from the same repository and release process. The README is explicit that there is deliberately no per-variant download: one Tauri binary, switch variant in-app. That removes an entire class of release drift, but it also means a bug in the shared shell affects every variant at once.

How the data reaches the screen

The architecture visible in the repository is a frontend plus a set of server-side handlers plus external relays. The frontend is vanilla TypeScript built with Vite, using globe.gl and Three.js for the 3D globe and deck.gl with MapLibre GL for the flat WebGL map. There is no React or Vue layer; the UI is hand-built, which is consistent with a map-heavy application where a virtual DOM adds little.

On the server side, API contracts are defined in Protocol Buffers with sebuf HTTP annotations, and TypeScript handlers are compiled into self-contained ESM bundles. The Dockerfile documents the pipeline: install dependencies, run the crawlable-corpus and sitemap builds, regenerate inventory facts, then run node docker/build-handlers.mjs to compile handlers into api/**/*.js alongside the source. That build step matters because the generated inventory modules are intentionally untracked, so a clean image has to recreate them before anything imports them.

Caching is a three-tier arrangement with Redis (Upstash), CDN and service worker. The compose file wires the app to a redis-rest service over HTTP and to an AIS relay on port 3004. AI summarization runs through Groq, OpenRouter or a local Ollama instance, and the README states local AI requires no API keys. The Country Instability Index is described as server-authoritative v8 stress scoring for a Tier-1 registry, which means the score is computed upstream rather than in the browser; a self-hosted instance is consuming that number, not deriving it.

Installing World Monitor and getting a first reading

The README's quick start is four commands and no credentials. Clone the repository, install, run the dev server, and open localhost:3000. The app runs with no environment variables set, which is unusual for a project that pulls from this many external sources.

 git clone https://github.com/koala73/worldmonitor.git
 cd worldmonitor
 npm install
 npm run dev

The README says to open localhost:3000, and that the port can be overridden with DEV_PORT in .env.local. Note that DEV_PORT is deliberately not VITE_-prefixed, so it is read at config time and never injected into the client bundle. If you want a specific variant instead of the default, the README lists dedicated scripts:

npm run dev:tech       # tech.worldmonitor.app
npm run dev:finance    # finance.worldmonitor.app
npm run dev:commodity  # commodity.worldmonitor.app

For a server deployment, the compose file is the documented path. It requires three secrets and refuses to start without them, using the ${VAR:?message} form, so a missing value fails the build rather than silently running with a default.

cp .env.example .env
openssl rand -hex 32   # generate REDIS_TOKEN, WM_SESSION_SECRET, RELAY_SHARED_SECRET
docker compose up -d --build

The compose file maps ${WM_PORT:-3000} on the host to port 8080 in the container, so the container port differs from the dev port. The README points to a self-hosting guide for Vercel, Docker and static deployment options. Data-source keys such as AISSTREAM_API_KEY, FINNHUB_API_KEY and EIA_API_KEY are optional; the .env.example states that all keys are optional and the corresponding features are disabled without them.

The AGPL-3.0-only licence and what it constrains

The package.json declares "license": "AGPL-3.0-only", and the README badge points at the same licence. This is the strongest copyleft in common use for web applications. If you modify World Monitor and let users interact with it over a network, the AGPL's network clause is generally understood to require offering those users the corresponding source. That is a real constraint for anyone planning to fork the dashboard into a commercial product and keep the changes private.

Running it unmodified for internal analysis is a different situation, but the boundary between internal use and offering a service to others is exactly where legal advice is needed, and this article cannot give it. What is verifiable from the repository is the licence identifier and the fact that the project ships the full source, the Dockerfiles and the build scripts. There is no separate enterprise licence file in the top-level entries.

One practical consequence of AGPL plus self-hosting: you inherit the upgrade burden. The repository has a CHANGELOG.md and a release cadence visible in the release list, with v2.5.20, v2.5.21 and v2.5.23 all landing in late February and early March 2026. The last push was on 2026-03-01, more than six months before today, so the project is not currently receiving commits. Treat the current release as a fixed artifact you patch yourself rather than a stream you track.

Where World Monitor is the wrong tool

The clearest limitation is operational: there is no documented rollback procedure. The README covers quick start, self-hosting, programmatic access and support status, but it does not describe how to revert a deployment or what a failed migration looks like. For a dashboard that aggregates external feeds, that gap matters less than for a system holding state, but it still means you are on your own when an upgrade goes wrong.

The second limitation is dependency on upstream sources. The README's support table marks the hosted variants and desktop binaries as stable, and issues are triaged from one backlog, but the data itself comes from third parties. The .env.example lists AISSTREAM, Finnhub and EIA keys among others, and states that features degrade gracefully without them. Graceful degradation is not the same as correctness: a finance radar with no Finnhub key is a different product from one with it, and the dashboard does not advertise which mode you are in.

Third, the project is not a substitute for primary reporting. AI-synthesized briefs compress whatever the feeds said. If a source is wrong, the brief is wrong, and the CII score is computed server-side on a registry the self-hoster does not control. Anyone treating the instability index as an independent measurement rather than an upstream number should check where it originates in their deployment.

Finally, if you need a vendor with a support contract, this is not it. There is a Discord and an issues board, and the README mentions a Pro surface, but no published SLA or security response timeline appears in the project's documentation.

Alternatives and the real difference in approach

Palantir is the comparison people search for, and the difference is structural rather than feature-level. Palantir deployments are proprietary, integration-heavy and sold with support; World Monitor is AGPL-3.0-only source you run yourself, with a documented Docker stack and a public MCP endpoint. If your requirement is a vendor who owns the outcome, World Monitor is the wrong category entirely.

A more honest comparison is with assembling your own stack: a feed reader, a Grafana board over a time-series database, and a mapping library. That path gives you full control over sources and retention but costs weeks of integration work, and you would still be writing the correlation logic that World Monitor ships as cross-stream correlation and the CII. The trade is that you would own the data model instead of adapting to a panel inventory designed upstream.

For the programmatic layer, the project's own CLI and SDKs are the alternative to the web UI. The README shows npx worldmonitor tools listing every MCP tool without a key, and worldmonitor risk IR --api-key wm_xxx for an authenticated call. Official client libraries exist for Python (worldmonitor-sdk), Ruby (worldmonitor) and Go (github.com/koala73/worldmonitor/sdk/go), all described as zero-dependency. If your goal is to feed signals into an existing pipeline, the SDKs are a smaller commitment than self-hosting the dashboard, and they sidestep the AGPL question for the frontend code since you are calling a service rather than redistributing it.

Programmatic access: MCP, REST and the CLI

The README treats agents as first-class consumers, which is a deliberate positioning choice. The MCP server lives at https://worldmonitor.app/mcp over Streamable HTTP. The README states that tools/list is public while tools/call authenticates with an X-WorldMonitor-Key header or OAuth. The server also publishes Agent Skills through a draft io.modelcontextprotocol/skills extension with skills/list, skills/get and skill:// resource reads.

The REST API has base https://api.worldmonitor.app and is described by an OpenAPI spec at worldmonitor.app/openapi.yaml. The CLI is the official worldmonitor npm package with source in cli/, and the README gives a short example of listing tools without a key and then calling a risk endpoint with one.

npx worldmonitor tools          # run ad-hoc, list every MCP tool (no key needed)
npm install -g worldmonitor     # or install the `worldmonitor` (alias `wm`) command
worldmonitor risk IR --api-key wm_xxx

Agent discovery files are listed as llms.txt, an agent-skills manifest under .well-known, and an api-catalog. This is more machine-readable surface than most dashboards expose, and it is the strongest argument for adopting World Monitor as a data layer rather than as a UI. The caveat is that all of it points at the hosted service. Self-hosting gives you the dashboard; the MCP endpoint and the api.worldmonitor.app base are the project's own infrastructure, and the documentation does not describe a supported way to stand up an equivalent MCP server from your own deployment.

Editorial conclusion

World Monitor fits teams that want a single interface over news, geopolitical signals and infrastructure data, and that are willing to run it themselves under AGPL-3.0-only. It is a poor fit if you need a maintained SaaS with an SLA: the last push was on 2026-03-01, the README does not document rollback, and the repo carries no published security response timeline. Before adopting, verify three things in your own checkout: that npm run dev serves on port 3000 without credentials, that the Docker stack starts with REDIS_TOKEN, WM_SESSION_SECRET and RELAY_SHARED_SECRET generated locally, and that the upstream APIs your deployment depends on still answer.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes