Requirements

Everything you need before deploying. Read this first, hand the checklist to your infrastructure team, and move on to the Deployment guide once everything is in place.

---

How the platform is deployed

The RootCause Platform is deployed into your Kubernetes cluster via the RootCause Operator. The operator manages the full lifecycle — install, configure, upgrade — through an Admin UI.

The deployment flow is:

1. Your infra team installs the operator (one Helm command)

2. You open the Admin UI and fill in a bootstrap wizard

3. The operator deploys everything: databases, workflow engine, identity, LLM proxy, and the platform itself

Once installed, data scientists can check for updates and apply them through the Admin UI without involving the infra team.

What the operator deploys

┌──────────────────────────────────────────────────────────────────┐
│                         Admin UI (:3000)                         │
│ Bootstrap │ Overview │ Secrets │ Users │ Releases │ LLM │ Cluster│
└────────────────────────────┬─────────────────────────────────────┘
                             │ writes CR
                             ▼
┌──────────────────────────────────────────────────────────────────┐
│                    RootCauseInstallation CR                      │
└────────────────────────────┬─────────────────────────────────────┘
                             │ reconciles
                             ▼
┌──────────────────────────────────────────────────────────────────┐
│                      Operator Controller                         │
└────────────────────────────┬─────────────────────────────────────┘
                             │ manages
             ┌───────────────┼───────────────┐
             ▼               ▼               ▼
      Dependencies       Platform         Secrets
      ├ PostgreSQL       ├ Platform       ├ Auth keys
      ├ MongoDB          ├ Data Service   ├ DB credentials
      │  └ Search        ├ Telemetry (opt) └ Storage credentials
      ├ Redis            └ Ingresses
      ├ Temporal              │
      ├ LiteLLM               │ spawns per task
      ├ FusionAuth            ▼
      └ Garage (opt)     ML Job pods (ephemeral, run on the
                         scale-to-zero compute node pool)

Platform components:

Component	What it does
Platform	UI and backend-for-frontend (Next.js + API)
Data Service	Core backend for data processing, orchestration, LLM integration, and the in-process query/compute engine (FastAPI)
ML Job pods	Ephemeral Kubernetes Jobs spawned per task by the Data Service for heavy compute (causal discovery, digital twins, simulation, ontology extraction). Not a long-running deployment — pods run to completion and are cleaned up.
Telemetry	Optional local telemetry service, disabled by default

Infrastructure dependencies (deployed by the operator into your cluster):

Dependency	Purpose	Minimum version
PostgreSQL	Relational database for Temporal, FusionAuth, and LiteLLM	15.0+
MongoDB	Document database for application data, deployed with MongoDB Search (mongot) for full-text search	8.0+
Redis	Sync layer	7.2.4+
Temporal	Durable workflow execution	1.26.2+
LiteLLM	LLM API proxy and management	Deployed by default
FusionAuth	Identity and access management (optional — see Identity below)	Deployed on request

MongoDB operator: the in-cluster MongoDB replica set and MongoDB Search are managed by the unified MongoDB Kubernetes Operator (MCK, chart mongodb-kubernetes). The legacy MongoDB Community Operator cannot deploy MongoDB Search and is rejected by the operator's preflight checks. The Deployment guide covers installing MCK.

Every dependency can instead be connected as an external instance (existing PostgreSQL, MongoDB, Redis, Temporal, or LiteLLM) during the bootstrap wizard.

---

Infrastructure requirements

Kubernetes and tooling

Requirement	Version
Kubernetes	1.26+ (tested on AKS, EKS, GKE, and kind)
Helm	3.12+
kubectl	Configured with cluster-admin access

Cluster sizing

Minimum — supports datasets up to ~5GB, 50 columns, ~1M rows:

Resource	Spec
Nodes	3-4
CPU per node	8 vCPU
RAM per node	64 GB
Storage	SSD-backed persistent volumes
GPU (optional)	48 GB VRAM (local LLMs only)

Recommended for production — supports datasets up to ~10GB, 100+ columns, ~20M rows:

Resource	Spec
Nodes	4+
CPU per node	64 vCPU
RAM per node	128 GB
Storage	SSD-backed persistent volumes
GPU (optional)	96 GB VRAM (local LLMs only)

All nodes must be amd64 architecture.

Compute node pool (optional, recommended for production): heavy ML jobs and digital twins run as ephemeral Job pods. You can route them onto a dedicated node pool that autoscales from zero — tainted rootcause.ai/workload=compute:NoSchedule, labeled rootcause.ai/nodepool=compute, autoscaling min=0. This gives heavy jobs large nodes on demand without paying for idle capacity. The Deployment guide covers the configuration.

---

Cloud-specific prerequisites

The platform runs on Azure, AWS, and GCP. The core deployment is identical; only the items below differ.

Requirement	Azure	AWS	GCP
Managed Kubernetes	AKS	EKS	GKE
Storage class	managed-csi	gp3	standard or premium-rwo
Object storage	Azure Blob Storage	S3	GCS
Compute pool autoscaler	Built-in cluster autoscaler	Cluster Autoscaler or Karpenter (self-deployed)	Built-in cluster autoscaler
Ingress options	Azure Application Gateway (AGIC) or nginx	nginx or ALB Ingress Controller	nginx or GCE Ingress
Identity (OIDC)	Azure EntraID	Okta, Auth0, or any OIDC provider	Google Workspace or any OIDC provider

Note: Azure Application Gateway requires additional ingress annotations and path configuration. The Deployment guide covers this in detail.

No cloud bucket? On any cloud (or on-prem) you can skip external object storage entirely: the operator can deploy Garage, an in-cluster S3-compatible object store, fully automated — it creates the bucket, generates credentials, and wires everything to the platform. See Decision Point 3 below.

---

What you need to provide

Hand this checklist to your infrastructure team. Everything must be in place before deployment begins.

Cluster and access

• Kubernetes cluster provisioned (1.26+, amd64 nodes, SSD-backed storage)

• kubectl configured with cluster-admin access

• Helm 3.12+ installed

• (Optional) Compute node pool for ML jobs: autoscaling node group with min=0, tainted rootcause.ai/workload=compute:NoSchedule, labeled rootcause.ai/nodepool=compute

Networking

• Ingress controller installed (nginx, Azure Application Gateway, or equivalent)

• Base domain with wildcard DNS record pointing to the ingress controller IP

• Subdomains planned for: platform, auth, and litellm (e.g., platform.rootcause.example.com, auth.rootcause.example.com, litellm.rootcause.example.com)

• TLS certificate — wildcard or per-subdomain

• Outbound (egress) access from the cluster to:

  • registry.gitlab.com — container images and OCI Helm charts

  • https://telemetry.rootcause.ai — platform telemetry

  • Your LLM provider APIs (e.g., OpenAI, Anthropic, Google, AWS Bedrock, Azure OpenAI) — unless serving local LLMs

Storage

• Object storage — choose one:

  • A single bucket/container created with credentials. Datasets, digital twins, and ML models are stored as sub-directories of this one bucket.

  • Nothing — use the in-cluster Garage object store, deployed and configured automatically by the operator.

• Storage class available for persistent volumes (e.g., managed-csi, gp3)

Registry access

• Container registry credentials from RootCause (GitLab deploy token with read_registry scope)

Identity (choose one)

• OIDC (recommended): Issuer URL, client ID, client secret, and well-known configuration URL from your identity provider

• SAML: Metadata URL or XML, entity ID, and certificate from your identity provider

• Managed FusionAuth: No preparation needed — the operator provisions it automatically. Best for POCs or organizations without an existing IdP.

LLM access

• API keys for at least one LLM provider (OpenAI, Anthropic, Google AI Studio, AWS Bedrock, or Azure OpenAI). LiteLLM is included in every deployment and proxies requests to your LLM providers.

---

What RootCause provides

• RootCause Operator Helm chart (OCI registry)

• Platform and dependencies Helm charts (OCI registry, pulled automatically by the operator)

• Admin UI for configuration, deployment, user management, and upgrades

• Deployment support via Slack, email, and scheduled check-ins

---

Decision points

Answer these before starting the Deployment guide. They determine which sections you'll fill in during the bootstrap wizard.

1. Identity provider

Option	When to choose it
External OIDC (recommended)	Your organization has an existing identity provider (EntraID, Okta, Auth0, Google Workspace)
External SAML	Your IdP only supports SAML, or your security team requires it
Managed FusionAuth	POC, eval, or no existing IdP. The operator deploys and configures FusionAuth automatically.

2. Ingress controller

Option	When to choose it
nginx	Most common. Works on all clouds. Simpler configuration.
Azure Application Gateway	Required by your Azure networking team, or you need WAF/DDoS protection at the ingress layer. Requires additional annotations and path config — see Deployment guide.

3. Object storage

The platform uses one bucket/container; everything is stored under sub-directories of it.

Option	What you need
Azure Blob Storage	Storage account name and one auth method: connection string, account key, or service principal (tenant ID, client ID, client secret); one container
AWS S3 (or S3-compatible)	One bucket, access key, secret key, region — plus an endpoint URL for S3-compatible stores
GCS	One bucket, project ID, service account credentials
Garage (in-cluster)	Nothing — the operator deploys it, creates the bucket, and generates credentials. Single-node mode for dev; 3-replica production mode needs 3+ schedulable nodes.

4. ML job compute

Option	When to choose it
Default node pool	Simplest. ML Job pods run on the general cluster nodes.
Dedicated scale-to-zero compute pool	Production. Heavy jobs get large nodes on demand without paying for idle capacity; small ontology jobs stay on the default pool.

---

Next step

Once your infrastructure team has checked off the list above, proceed to the Deployment guide.