Skip to main content

Documentation Index

Fetch the complete documentation index at: https://kumo.ai/docs/llms.txt

Use this file to discover all available pages before exploring further.

Kumo can run as a Kumo-managed private deployment that is reachable from your network through Private Link, Private Service Connect, or customer-approved IP allowlists. This option gives you private access to Kumo without requiring your team to operate the Kubernetes cluster, GPU capacity, application services, or upgrades yourself. The architecture is similar to the Virtual Private Cloud deployment, but the Kubernetes environment runs in a Kumo-managed AWS, Azure, or Google Cloud account. Kumo operates the UI, API, authentication, data engine, model execution services, and cloud storage layer, while your team controls private network access, identity provider integration, source data permissions, and customer-managed encryption keys where required. This page is intended for security, infrastructure, and data platform teams who want to understand how the Private Link deployment behaves technically—what Kumo operates, how users and data systems connect privately, and what your team must provision.
  • Gives users and notebook environments private access to the Kumo UI and API through your corporate network.
  • Avoids public internet paths for user access by using Private Link, Private Service Connect, or customer-approved IP allowlists.
  • Provides the same Kumo application architecture as the VPC deployment without requiring your team to manage Kubernetes, GPU nodes, Helm/GitOps rollout, or application upgrades.
  • Supports enterprise identity, project-level RBAC, and standard warehouse integrations while keeping source access under customer-owned permissions.

​
2. Architecture and isolation

Each customer receives a dedicated Kumo environment in a Kumo-managed cloud account:
  • Kumo application services run as containers in a Kubernetes cluster managed by Kumo.
  • The cluster runs multiple pods for the UI, API, authentication layer, data engine, and model execution services.
  • Model execution uses Kumo-managed GPU capacity for training and prediction workloads.
  • Cloud storage in the Kumo-managed account holds intermediate artifacts, model binaries, prediction outputs, embeddings, logs, and backups. Where required, storage is encrypted with customer-managed keys.
  • Users access Kumo through Private Link, Private Service Connect, or IP allowlist paths from your corporate network.
Traffic between your network, your data platforms, and the Kumo-managed environment uses private or customer-approved paths. Source data access is controlled by the service accounts, warehouse roles, storage permissions, or managed identities that you configure. High Level Architecture

​
3. Identity, RBAC, and console access

Access to the Kumo console and APIs is integrated with your identity provider:
  • OIDC identity provider integration is supported for enterprise login.
  • MFA, device posture checks, and other access policies remain enforced by your identity provider.
  • Admin-configurable RBAC maps users and groups to Kumo projects and permissions.
  • User groups can be restricted to their own projects, and each project can be configured to access only specific datasets in the source warehouse or storage location.
This allows separate teams to use the same Private Link deployment while maintaining strong separation between projects, source datasets, models, predictions, and artifacts.

​
4. Data sources and protection

The principle remains: your primary data stays in your platforms, and Kumo reads only through the access paths and credentials you configure. Supported data sources include:
  • Parquet files in customer cloud storage.
  • Direct upload, if enabled by your administrators.
  • Standard cloud data warehouses and lakehouse platforms, including BigQuery, Snowflake, and Databricks.
Kumo connects to each source using customer-owned permissions, such as service accounts, warehouse roles, storage roles, or managed identities. For team-separated deployments, those permissions can be scoped by project so different user groups can only access the datasets assigned to them. Training, evaluation, prediction, and embedding jobs execute in the Kumo-managed private environment. Outputs are written back to destinations you configure, such as warehouse tables or customer cloud storage. Data in transit is protected with TLS, and Kumo-managed storage can be encrypted with customer-managed keys for model artifacts, logs, backups, and intermediate data.

​
5. Network and dependencies

The Private Link deployment keeps infrastructure operations with Kumo while giving your team control over the private access paths:
  • Private access: Private Link, Private Service Connect, or IP allowlist rules allow employees and notebook users to reach the Kumo UI and API from your corporate network.
  • Identity provider: OIDC integration connects Kumo login to your enterprise identity provider.
  • Data platforms: Connections to BigQuery, Snowflake, Databricks, object storage, or other supported sources use customer-owned permissions.
  • Encryption keys: Customer-managed keys can be used where required for Kumo-managed cloud storage.
Unlike the VPC deployment, your team does not need to provision or operate Kubernetes node pools, GPU autoscaling, Helm releases, GitOps configuration, or application upgrades.

​
6. Installation flow and customer responsibilities

Typical customer responsibilities are:
  • Create Private Link, Private Service Connect, or approved network access paths so employees can reach the Kumo UI and API from the corporate network.
  • Configure OIDC for your identity provider, including the user and group claims Kumo should use for RBAC.
  • Grant service accounts, roles, managed identities, or warehouse permissions for each data source and destination the deployment should access.
  • Provide customer-managed encryption keys if required by your security policy.
  • Validate end-to-end workflows: data access, training, prediction, and writeback paths for each team or project.

​
7. Operations and lifecycle

  • Kumo operates the Kubernetes cluster, application services, GPU capacity, upgrades, and routine platform maintenance.
  • Kumo coordinates upgrades and maintenance windows with your change management process where required.
  • Support access is time-bounded and can be provided through your approved access pattern, such as VDI or a customer-controlled account.
  • Your team remains responsible for identity provider configuration, private network access, data source permissions, and customer-managed keys.
If you want to evaluate Private Link, your Kumo representative can share a cloud-specific endpoint topology and bill of materials for your identity provider, network pattern, data sources, and expected workload size.