Lighthouse AdvisorySLED AI Adoption Intelligence
← Back to results

From the NVIDIA edition of October 13, 2026

Vendor claimEmergingUndated source

NVIDIA Run:ai open-source repository: Apache 2.0 license, components, install paths and stated fit limits

NVIDIA (DSX AI Factory GitHub organization) · Technology vendor · Global

NVIDIA
Publisher
GitHub
Original publication
2026-10-13 (repository public with the announcement; README undated)
Source retrieved
2026-10-14
Event date
2026-10-13
Read original source

What happened

The README describes a monorepo with the control plane, cluster services, installer, CLI, MCP server, client packages, scale tests and docs. It is licensed Apache 2.0 with trademarks excluded and nested MIT and CC-BY-4.0 components. It supports Kubernetes or OpenShift, connected or air-gapped, with images and Helm charts pulled from NGC (nvcr.io/nvidia/runai) by default. It says Slurm is an alternative for HPC-style batch on bare metal and that single-team dedicated GPUs may need only native Kubernetes. No long-range roadmap is published.

Why it matters

Moderate to high for university research computing teams deciding between Kubernetes GPU orchestration and existing Slurm clusters.

Evidence and measured results

Primary project documentation; does not include performance data.

Limitations and uncertainty

Project self-description; support and end-of-life details sit on linked pages not reviewed line by line.

Cross-source patterns this evidence supports

Put this evidence to work

Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-10-14; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.

Sales

Role takeaway
Customer problem
Campus and state IT teams need to know exactly what is open, what is licensed differently, and when Run:ai is the wrong tool before committing staff.
Stakeholders
  • University research computing / HPC director
  • Campus CIO and IT finance
  • Principal investigators sharing GPU clusters
  • State or system-wide shared AI computing program leads
Discovery questions
  • Do you run HPC batch on bare metal with Slurm, Kubernetes, or both?
  • Do you need air-gapped installation?
  • Will you mirror NGC images internally?
Value hypothesis
Interpretation: clear fit boundaries can shorten qualification and avoid failed pilots on Slurm-only estates.
Potential engagement
Bounded fit assessment comparing the institution's schedulers and workloads against the repository's stated scope.
Unsupported claims
  • That Run:ai replaces Slurm
  • That NVIDIA trademarks or brand assets are licensed
  • A published long-term roadmap

Pre-sales engineering

Role takeaway
Fit
Moderate to high for Kubernetes GPU estates; the README itself says low for single-team dedicated GPUs.
Architecture and integration
Control plane managing one or more clusters; cluster services extend Kubernetes scheduling; web UI, CLI, REST API and an MCP server for AI assistants.
Prerequisites
  • Kubernetes or OpenShift within the support matrix
  • Access to nvcr.io or an internal mirror
  • Helm or the runai-installer CLI
Constraints
  • Default image source is NVIDIA NGC
  • Nested third-party licenses (MIT, CC-BY-4.0) in some subdirectories
  • No published long-range roadmap
Security
Vulnerabilities go through a private Security process; the MCP server exposes platform operations to AI assistants and needs access review.
Proof of value
  • Install in an air-gapped test cluster from mirrored images
  • Review the MCP server's permissions before enabling it
  • Check NOTICE files for redistribution obligations

Delivery

Role takeaway
Work
Stand up a test install with the guided installer, verify license obligations, and set a version-tracking process.
Dependencies
  • Internal container registry
  • Kubernetes platform
  • Legal review of NOTICE files
Ownership
Research computing platform team.
Skills and adoption
Teams need Helm, Kubernetes operator and release-management skills.
Governance checkpoints
  • Security review of MCP server exposure
  • License and NOTICE review before redistribution
  • Supported-version check before each upgrade
Acceptance criteria
  • Proposed: successful air-gapped install from mirrored images
  • Proposed: upgrade tested within a supported version window
Risks
  • Dependence on NGC availability
  • Version churn without a roadmap
  • Misreading Apache 2.0 as covering trademarks

Implementation considerations

Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.

Architecture and integration

What must connect, and where does the AI sit in the workflow?

Multi-cluster control plane; complementary to Kubeflow, Ray and Argo; alternative to Slurm for some workloads.

Governance

Who approves, reviews and stays accountable for outcomes?

Role-based access and organizational policies across workloads.

Security and privacy

What data, permissions and controls need testing?

Private vulnerability reporting; MCP server adds an AI-assistant control surface.

Accessibility and workforce

Who is affected, and what skills or accommodations follow?

Builds run in containers, lowering local toolchain needs for contributors.

Procurement

What should contracts, pricing and exit terms secure?

Apache 2.0 code permits self-use and modification; trademark and NGC terms remain separate.

Operating model

Which teams own the service once it runs?

Operators must track releases and supported versions themselves.

Publication history

  1. 2026-10-13NVIDIA · Issue 387 resources
Read preserved resource versions (JSON)

Stable resource ID: github-dsx-ai-factory-run-ai-repo-readme