blog-site/src/content/blog/self-host-worldmonitor-open-source-osint-dashboard.md
WorldMonitor is open source, but "open source" does not automatically mean "safe to run on the public internet with defaults." A serious self-hosted intelligence dashboard needs secrets, seeders, Redis, source keys, and a clear understanding of which feeds are public, optional, or paid.
The good news: the local stack is designed to run with Docker or Podman. You can bring up the dashboard, seed Redis, and open a browser at http://localhost:3000.
The important caveat: you should treat it like infrastructure, not a toy clone. Generate real secrets, keep override files out of git, and understand which data sources require API keys.
Self-hosting is useful when you want:
It does not magically give you every upstream dataset. Some sources are public, some require free signup, and some are paid. Self-hosting controls the application layer; it does not bypass upstream licensing or authentication.
The Docker stack contains four core services:
| Service | Purpose |
|---|---|
worldmonitor | nginx plus the Node.js API surface |
worldmonitor-redis | Redis data store |
worldmonitor-redis-rest | Upstash-compatible REST proxy |
worldmonitor-ais-relay | AISStream relay for vessel tracking when configured |
The runtime route is simple: the browser hits localhost:3000, nginx serves the Vite app and proxies /api/* to the Node API, the API talks to the Redis REST proxy, and seed scripts populate Redis.
That architecture is deliberately close to production concepts without requiring Vercel, Railway, or Upstash for a local install.
You need:
.env with generated secretsThe required secrets are:
RELAY_SHARED_SECRETREDIS_PASSWORDREDIS_TOKENGenerate them with a secure random source such as openssl rand -hex 32. The stack refuses to start without these values because hardcoded local defaults are unsafe once someone changes a bind address or deploys an override file.
At a high level:
.env.docker compose up -d../scripts/run-seeders.sh.http://localhost:3000.The seeders are not optional if you want a useful dashboard. Redis starts empty. The app can render, but many panels need cached data written by seed scripts.
If you remove volumes with docker compose down -v, Redis data is lost and you need to seed again.
WorldMonitor works with many public sources, but some feeds need keys.
Examples of optional or source-specific keys include:
The recommended pattern is docker-compose.override.yml for local keys. That file is gitignored, which keeps secrets out of commits.
Do not paste production secrets into issue comments, screenshots, terminal transcripts, or blog posts. The safest self-hosting guide is boring about secrets.
The local relay can be run without auth only by setting an explicit danger flag. That path is for local debugging, not internet-exposed deployments. If a route is reachable by other machines, assume someone will eventually find it.
Also remember:
Self-hosting is power and responsibility in the same box.
For local development, you can run the Vite app and API surfaces directly. For a fuller self-hosted stack, Docker Compose gives you the nginx, API, Redis, REST proxy, and relay shape.
For production-like deployment, you need to think beyond "does it start?":
WorldMonitor is a real-time intelligence dashboard with many external dependencies. That means operational hygiene matters.
For developer context before you deploy, read the developer API and open-source guide and the MCP server guide.
The self-hosting path uses public code, local secrets, Redis-backed caches, and seed scripts that fetch upstream data. Some panels will show more when optional keys exist. Some sources are free with signup. Some are paid. Missing source keys should be treated as expected partial coverage, not a broken product.
That distinction is important for demos. If a panel is empty, check whether the seeder ran, whether Redis has data, whether the key is configured, and whether the source is currently available.
The deployment files and current setup instructions live in the public WorldMonitor repository. Review the GNU AGPL license text alongside the repository's own licensing notes before operating a modified network service.
Can I run WorldMonitor entirely offline?
Not meaningfully. The application can run locally, but most intelligence value comes from fetching upstream public or authenticated sources into Redis.
Do I need every API key?
No. Many public sources work without keys, and optional keys unlock additional feeds. Start with the public stack, then add keys for the domains you actually use.
Can I deploy my fork publicly?
You can, but read the AGPL license and upstream source terms carefully. Network deployment and redistribution have obligations, and third-party data sources may have their own rules.
Self-hosting WorldMonitor is not about cloning a website. It is about owning the data path, the secrets, and the operational tradeoffs behind your intelligence workspace.