Service Map

Service map

Eleven services plus PostgreSQL and Redis. Everything is reached through the gateway; the ports below are what each container publishes on the host, taken from docker-compose.yml.

Entry points

Service	Host port	Built with	Role
gateway	80, 443, 8080	OpenResty (Nginx + Lua), Redis	The only service exposed beyond localhost. Routing, rate limiting, authentication
dashboard	127.0.0.1:3000	Next.js 14, TypeScript, Tailwind, TanStack Query	Web interface

Core services

Service	Host port	Built with	Role
identity	127.0.0.1:8001	FastAPI, PostgreSQL, JWT, Stripe	Users, teams, RBAC, API keys, subscription billing
api (tools)	127.0.0.1:8000	FastAPI, Redis	Unified API over 50+ security tools, with dynamic discovery and execution
data	127.0.0.1:8002	FastAPI, PostgreSQL, Redis	Threat intelligence aggregation and serving
guardian	127.0.0.1:8013	Django, PostgreSQL, Celery, Redis	Vulnerability lifecycle with risk-based prioritisation
responder	127.0.0.1:8018	FastAPI, Dramatiq, Redis	Incident response automation, YAML playbooks
cspm	127.0.0.1:8019	FastAPI, Celery, cloud SDKs	Cloud posture management for AWS, Azure, GCP
agents	127.0.0.1:8006	FastAPI, Celery, LangChain	LLM-based analysis and reporting
sensor	127.0.0.1:8004	osquery, Python	Endpoint telemetry collection

Support services

Service	Host port	Notes
tools-worker	none	Celery worker behind the tools API
tools-flower	127.0.0.1:5555	Flower, the Celery task monitor
data-scheduler	none	Scheduled threat-feed refresh
postgres	none	Reachable only on the Docker network. The mapping exists in the compose file but is commented out, deliberately
wildbox-redis	none	Same
automations	127.0.0.1:5678 when started	n8n workflow automation, off by default, behind a Compose profile

What starts by default

Everything above except automations, which sits behind a Compose profile:

docker compose --profile automations up -d

Nothing hard-depends on it. The gateway resolves it dynamically, so /api/v1/automations/ returns 502 until the profile is started, which is expected rather than broken.

Note. The README describes cspm and sensor as "in development" and "not enabled in the default docker-compose.yml". They are in fact defined in the default compose file, without a profile, so they do start. Treat their maturity as the README describes it, but do not be surprised to see the containers running.

Elasticsearch is in the diagram, not in the compose file

The README's architecture diagram and its stack description for open-security-data both list Elasticsearch. There is no Elasticsearch service in docker-compose.yml, and data declares depends_on: postgres only. So nothing starts one, and it does not enter the memory budget for a default deployment. Worth knowing if you are sizing a host from the README, or wondering why a search-shaped feature is missing.

Networking

Only the gateway binds beyond localhost. Every other published port is bound to 127.0.0.1, and the two datastores publish nothing at all. The intent is that all external traffic arrives through the gateway, which is where authentication and rate limiting live.

The practical consequences: reaching a service from another machine means going through the gateway or opening an SSH tunnel, and the dashboard on port 3000 is reachable only from the host running Docker.