Deployment & infrastructure

Jutsu runs as containerized services on Kubernetes, backed by four data stores and external LLM providers. Production runs on Google Kubernetes Engine (GKE) across more than one region; local development runs the same images under Docker Compose. This page describes the stack and how the pieces connect.

Runtime platform

Production deploys to GKE Autopilot, with manifests organized as a Kustomize base plus one overlay per environment. Autopilot provisions and removes nodes automatically to fit the pods that autoscaling creates, so there are no node pools to manage. Two autoscaling layers drive pod count:

  • HTTP APIs (platform-api, ingest-api) scale on CPU utilization via a HorizontalPodAutoscaler.
  • Queue workers scale on RabbitMQ queue depth via KEDA, matching the event-driven pipeline.

Scheduled singletons (reporting, data archiver, Google Workspace poller) are pinned to one replica because each runs an embedded cron — scaling them would duplicate scheduled work.

Datastores are external/managed and referenced only by URL from the deployment's secrets. Backups run as a scheduled job or via the database provider rather than in-cluster. Confirm the exact managed services against your deployment.

Data stores

Each store owns a distinct part of the data plane.

StoreRoleHolds
PostgreSQLTransactional system of recordOrganizations, users, credentials, incidents, cases, audit. Schema managed with Drizzle ORM migrations.
OpenSearchSearch and alert documentsNormalized events and alert documents, in per-organization weekly indices.
RabbitMQWorker message queueStage-to-stage handoff between agent workers.
RedisCache and countersCached LLM step results and short-lived counters; falls back to in-process memory when unavailable.

LLM providers

The AI agents call external large-language-model providers. Jutsu supports OpenAI and Anthropic, with the provider and model configurable per deployment and a fallback binding when a primary model is unavailable.

Regions

Production runs in more than one region, each as its own Kustomize overlay and namespace:

EnvironmentNamespaceRegistry region
Primaryagentsoc-produs-east1
Indiaagentsoc-fsnindiaasia-south1

Each region is an independent cluster with its own datastores and secrets, which keeps regional data within its region.

Region names and namespaces above reflect the reference overlays. Verify the regions, namespaces, and managed-certificate setup against your own k8s/overlays.

Local development

Docker Compose runs the full stack locally with the same images. The infrastructure containers (PostgreSQL, OpenSearch, RabbitMQ, Redis) come up alongside the APIs and workers, and database migrations run as a one-shot migrate step.

Services and ports

The table below lists the components and their conventional local ports. Production endpoints sit behind the ingress and are not exposed directly.

ComponentProtocolLocal port
DashboardHTTP5173
Platform APIHTTP8100
Ingest APIHTTP8110
PostgreSQLTCP5432
OpenSearchHTTPS9200
RabbitMQAMQP5672
RabbitMQ management UIHTTP15672
RedisTCP6379
These ports are the Docker Compose defaults for local development. In production, ports and hostnames depend on your ingress and managed-service configuration — confirm them against your deployment before relying on any value.