> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.nvidia.com/sdgm/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.nvidia.com/sdgm/_mcp/server.

# Choose a Deployment Path

> Choose a pip install, Docker Compose, or Helm (Kubernetes) deployment path for the Kumo RDL Platform.

#### Coming soon

**Kumo containers will be publicly available in the NVIDIA NGC Registry soon. Stay tuned.**

The Kumo RDL Platform ships as software you run in your own environment.
Pip install is coming soon for notebook-based exploration.
Today, you can run the Kumo RDL Platform with Helm on Kubernetes or Docker Compose on a single host.
The container deployment paths run the same images and expose the web UI, REST API, and SDK.
They differ in how they scale and what infrastructure they require.

## Deployment Paths

### Pip Install (Coming Soon)

The pip-install version provides the service-independent Kumo training engine for use from a GPU-enabled notebook, without deploying the Kumo RDL Platform services.
It will be the recommended starting point for first-time users, offering the fastest route to a first model and a focused environment for exploration.
This path is coming soon.

The underlying Python package is `kumo-core`, which requires Python 3.10 or later and includes PyTorch, PyTorch Geometric, PyTorch Lightning, and DiskGraph dependencies.
The package metadata defines no pip console-script entry point, so use it from Python code in your notebook.

### Docker Compose

**[Docker Compose](/get-started/docker/prerequisites)** runs all Kumo services on a single Linux host.
It bundles Temporal (the workflow engine Kumo uses for job scheduling), Postgres, and nginx.
The stack is started with `docker compose` using the single-host compose files.
It is the fastest way to get Kumo running and the right choice for evaluation, demos, and small single-team workloads.

### Helm (Kubernetes)

**[Helm](/get-started/helm/registry-and-image-access)** installs Kumo onto a customer-managed Kubernetes cluster (EKS, AKS, GKE, or Azure Red Hat OpenShift).
It delivers cluster-managed, autoscaled GPU pools and rolling updates.
The cluster, Temporal, Postgres, HTTPS edge, and object storage must be provisioned before installation.
This is the production path.

## Which one to choose

|                                | Pip Install (Coming Soon)                           | Docker Compose                           | Helm (Kubernetes)                                                          |
| ------------------------------ | --------------------------------------------------- | ---------------------------------------- | -------------------------------------------------------------------------- |
| **Best for**                   | First model and exploration                         | Evaluation, demos, single-node workloads | Production, staging, real workloads                                        |
| **Runtime**                    | GPU-enabled notebook with Python 3.10+              | Any Linux host with Docker               | Kubernetes cluster (EKS / AKS / GKE / Azure Red Hat OpenShift / on-prem)   |
| **GPU scaling**                | GPU-enabled notebook                                | Single host, fixed GPU count             | Multi-node, autoscaled pools                                               |
| **DiskGraph pooling**          | DiskGraph package dependency; no pool configuration | Single pool worker                       | Cluster-managed, multi-worker cache and ephemeral pools                    |
| **Concurrent jobs**            | 1 job per notebook kernel                           | Set by `POOL_GPU_CONCURRENCY`            | Determined by scheduled GPU pool capacity                                  |
| **HA and rolling updates**     | Not a service deployment                            | None                                     | Supported                                                                  |
| **Ops effort**                 | Lowest - install into a notebook environment        | Minimal - `docker compose up`            | Higher - cluster, secrets, storage, ingress to provision                   |
| **Connector credential model** | Coming Soon                                         | Environment variables                    | Workload identity (IRSA / GKE Workload Identity / Azure Workload Identity) |

DiskGraph is Kumo's on-disk graph data cache used during training jobs; the pooling rows in the table describe how many worker processes build and serve it.

**Start with Pip Install** when it becomes available to build a first model in a GPU-enabled notebook.
Use Docker Compose to evaluate the full Kumo RDL Platform on a single machine.
Move to Helm when you need production guarantees: high availability, horizontal scale, autoscaled GPU training, or integration with existing Kubernetes infrastructure.

## Connectors

Docker Compose and Helm support S3, Azure ADLS Gen2, GCS, and file upload.
Credential configuration differs by path: Docker Compose uses environment variables, while Helm uses cloud workload identity and does not store access keys.
Connector credential support for Pip Install is coming soon.

## Data stays with you

Kumo reads from your source systems and writes model artifacts to the object storage you provide.
For Docker Compose and Helm, data and model artifacts remain in your cloud environment.
Nothing leaves your environment unless you configure it.

For architecture deep dives, see [Simplified VPC Deployment](/simplified-vpc-deployment) for Docker Compose and [Virtual Private Cloud](/virtual-private-cloud) in Admin and Setup for Helm.