> For the complete documentation index, see [llms.txt](https://docs.rootcause.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rootcause.ai/installation-and-deployment/requirements.md). # 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.27.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**.