Skip to main content

Deployment

Atlas runs as a set of cooperating services. Locally these come up with Docker Compose; in production they are deployed to Kubernetes via Helm charts (charts/api, charts/ui, charts/worker). This page describes the topology; see Local development to run it and Configuration for environment variables.

Service topology

Services

ServiceRole
osint-apiFastAPI backend
osint-uiReact frontend (served by nginx)
postgresRelational system of record
neo4jProperty graph
redisCache & rate limiting
atlas-minio / atlas-minio-initDocument storage + bucket init
flywayApplies SQL migrations at startup
keycloak / keycloak-db-initIdentity provider + DB bootstrap
temporal / temporal-uiWorkflow server + inspection UI
temporal-workerExecutes investigation workflow & activities
workflow-engine-workerExecutes the low-code workflow engine
langfuse-web / langfuse-worker / langfuse-clickhouse / langfuse-minioLLM tracing stack

Startup ordering

Migrations must succeed before the API serves traffic, and the API verifies its dependencies on boot (schema load, TranslationRegistry, MCP). This is enforced by health-gated ordering.

Kubernetes (production)

The Helm charts deploy the API, UI, and workers as separate deployments:

  • charts/api — FastAPI deployment with an init container that stages migrations to a Flyway PVC, a Flyway init container that runs them, liveness probe GET /health and readiness probe GET /health/ready, ingress via nginx with cert-manager TLS, and per-route rate limits.
  • charts/ui — the React app served by nginx.
  • charts/worker — the Temporal worker and the workflow-engine worker.

For the exact service ports see Reference → Ports; for environment variables see Configuration. For day-2 operations see the Runbook.