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, message queues, 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  │
└──────────────────────┬──────────────────────────────┘
                       │ writes CR
                       ▼
┌─────────────────────────────────────────────────────┐
│              RootCauseInstallation CR               │
└──────────────────────┬──────────────────────────────┘
                       │ reconciles
                       ▼
┌─────────────────────────────────────────────────────┐
│              Operator Controller                    │
└──────────────────────┬──────────────────────────────┘
                       │ manages
          ┌────────────┼────────────┐
          ▼            ▼            ▼
   Dependencies    Platform     Secrets
   ├ PostgreSQL    ├ Platform   ├ Auth keys
   ├ Redis         ├ Data Svc   ├ DB credentials
   ├ MongoDB       ├ Data Fusion├ Storage credentials
   ├ Temporal      ├ ML Jobs
   ├ LiteLLM       └ Ingresses
   └ FusionAuth

Platform components:

Component	What it does
Platform	UI and backend-for-frontend (Next.js + API)
Data Service	Core backend for data processing, orchestration, and LLM integration (FastAPI)
Data Fusion	Data transformation and aggregation engine
ML Jobs	Headless compute engine for batch and algorithmic workloads

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	8.0+
Redis	Sync layer	7.2.4+
RabbitMQ	Message queue for async processing	3.12.2+
Temporal	Durable workflow execution	1.27.2+
LiteLLM	LLM API proxy and management	Deployed by default
FusionAuth	Identity and access management (optional — see Identity below)	Deployed on request

---

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.

---

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
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.

---

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

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

Storage

• Object storage bucket(s) created with credentials:

  • Datasets bucket/container

  • Digital twins bucket/container

  • ML models bucket/container

• 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

Cloud	Service	What you need
Azure	Azure Blob Storage	Storage account name, connection string, account key
AWS	S3	Bucket names, access key, secret key, region
GCP	GCS	Bucket names, service account JSON key

---

Next step

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