NVKE is NVIDIA's open-source preview for running a managed Kubernetes service on your own GPU machines. The repository is dsx-ai-factory/nvke, with copyright held by NVIDIA and an Apache 2.0 license. It reached the Hacker News front page with 123 points and 27 comments, and showed 326 stars after adding 125 in a day.
The README's own tagline is "Run a managed Kubernetes service on your own NVIDIA GPU infrastructure." It also says plainly that "we do not recommend NVKE for production workloads." This post explains what it is, how it fits NVIDIA's data-center stack, what you can try today, and what developers said about it.
TL;DR: the questions people ask first
| Question | Answer |
|---|---|
| What does it do? | Creates and operates isolated Kubernetes clusters on bare-metal GPU machines |
| Who runs it? | Platform teams at GPU clouds and data centers, not end users |
| Is it a distro? | No. It is a management plane that provisions workload clusters |
| Do I need a GPU to try it? | No. The local quickstart uses simulated machines |
| License | Apache 2.0 |
| Production ready? | No. The README says do not use it in production |
| Docs | docs.nvidia.com/nvke |
What NVKE actually is
Think of a cloud provider's managed Kubernetes product, such as the ones big clouds sell. NVKE is the software behind a product like that, but you run it on your own hardware. A platform team installs it, then creates clusters for customers. Customers use the normal Kubernetes API and kubectl.
Each customer cluster has its own control plane, etcd and node pools. That separation is the point: one tenant cannot see another's cluster state.
Kubernetes control plane concept with a ship wheel surrounded by pods, one highlighted, for NVIDIA NVKE
The README calls NVKE a "self-hosting factory." A temporary seed cluster bootstraps a management cluster. The management plane then provisions and manages many isolated workload clusters. After that, the seed is no longer needed.
How is NVKE built?
The README describes these parts.
- Management cluster. Runs the NVKE management plane and infrastructure controllers, including CAPNICo, which requests machines from NICo (NVIDIA Infra Controller).
- Workload clusters. Run customer applications. Their GPU machines boot from a node OS image, join as nodes and run an
nvke-agent. - Optional add-ons. An accelerated runtime from AICR and NVKE observability can be added to workload clusters.
- Build pipeline. A companion project, NVIDIA Kubernetes Recipes (NVKR), builds node images and NVKE components from pinned inputs. NVKE deploys those artifacts.
- Binaries.
make buildproduces nine:agent,updater,controller,nvkectl,capd-reboot-controller,nvke-os-image-check,management-engine,tenant-apiandoperator-api.
Security design
Nodes prove who they are before they get join credentials. The README says nodes attest with SPIFFE/SPIRE using their TPM, the hardware security chip on the machine. Etcd data encryption is available per cluster.
Permission boundary concept showing isolated tenant clusters behind a gate, relevant to NVIDIA NVKE node attestation
Those are real isolation features. The README also lists gaps, covered below.
What can you do with it today?
Cluster lifecycle works in preview: request clusters through the NVKE API or the nvkectl CLI, create, scale and delete node pools, and upgrade Kubernetes. Node replacement and upgrades have preview limits.
NICo is the only compatible infrastructure provider at preview. That ties NVKE to NVIDIA's own provisioning layer.
Try it without GPU hardware
The local evaluation path needs no NVIDIA account. It runs a development management plane and a workload cluster on simulated machines. Requirements from the README:
- A Linux host or VM, amd64 or arm64
- At least 6 CPUs, 12 GiB of free memory and 100 GiB of free disk
- Docker and virtual TPM support
- On macOS, run the evaluation inside a Colima virtual machine
To build from source you need Go 1.27.3 and GNU Make 4 or later. Run make build, then make preflight before submitting changes. We did not run the quickstart for this post, so we cannot report timings or failures.
Known limits in the preview
The README is direct about what is not ready:
| Limit | What it means |
|---|---|
| Unstable APIs | APIs, configuration and behavior can change between releases |
| Auth off by default | API authentication is off and the API uses plain HTTP after install. Configure auth before callers can reach it |
| No self-management | The management cluster does not upgrade, scale or replace itself |
| No backups | No management-plane upgrade or backup and restore procedure |
| FDE images | Full-disk-encryption node images are for evaluation only and "provide no data-at-rest confidentiality" |
| Linux node agent | The node agent runs only on Linux. On macOS, the evaluation runs in a Colima VM |
| Single provider | NICo is the only supported infrastructure provider |
If you run this anywhere reachable, lock the API down first. Plain HTTP without authentication on a cluster factory is a serious exposure. The same lesson applies to AI agents that call cluster APIs: give them narrow permissions. Our Kubernetes-adjacent coverage of agent control planes and the guide to running agents side by side cover that side.
Where NVKE fits in NVIDIA's stack
The repository sits under the dsx-ai-factory organization, which matches NVIDIA's DSX AI factory branding. The README points to the #nvke channel in the DSX AI Factory Slack for chat. We covered other DSX pieces at GTC Berlin: the keynote roundup with the DSX pod, the DSX pod claims versus verified facts, and confidential bare metal for European AI clouds.
NVKE looks like the Kubernetes layer for that picture. NVIDIA already ships tools above and beside it, such as Mission Control 2.5 for self-healing GPU clusters and GPU sharing and fractioning on Kubernetes. Note that this placement is our reading. The README does not map NVKE to those products.
What developers are saying on Hacker News
The thread is mixed. These are commenters' views, not verified facts.
- The README is hard to read. jeremy_carroll said it reads like a data dump and asked for a description of what the product does. This is why we put a plain definition first.
- "Can't regular Kubernetes use GPUs?" jimbokun asked. It can; NVKE addresses the layer above, creating many isolated clusters on shared bare metal.
- Who it is for. QuentinM described it as tenant-isolated clusters on NVIDIA's DSX reference stack, using NICo and BlueField for isolated networking and wiping and re-attesting hosts between tenants. They said it mostly helps teams seeking NVIDIA Cloud Partner status or NVIDIA support across the whole stack.
- Scope criticism. Yasuraka said it mixes concerns that should be separate, such as Cluster API, Kamaji and the GPU operator, and would only borrow the kind-based bootstrapper and the SPIFFE and TPM integration.
- Lock-in. antimario called it heavy and non-composable, tied to one vendor at many levels, and wanted tools that enrich existing infrastructure.
- Nostalgia warning. random3 recalled OpenStack and other all-in-one infrastructure projects.
The pattern is clear. Readers see value in the isolation and attestation design, and worry about weight and vendor coupling.
How does NVKE differ from plain Kubernetes with GPUs?
Plain Kubernetes can schedule GPU workloads once a cluster exists. The GPU operator and device plugins handle drivers and resources on nodes. That answers the question one commenter raised, and it is true. What plain Kubernetes does not give you is a service for creating, isolating and retiring whole clusters on bare metal for many customers.
That gap is where NVKE sits. A cloud operator who sells GPU capacity has to answer several questions for each tenant. Where does the control plane live? How do you prove a machine is the one you provisioned? What happens to a host when a tenant leaves? NVKE bundles answers to the first two: separate control planes and TPM attestation before join. The commenter's description of wiping and re-attesting hosts between tenants goes to the third, but the README summary we read does not spell out that workflow, so check the docs.
The trade-off is coupling. NICo is the only provider at preview, and the design assumes NVIDIA's reference stack. Teams that already run Cluster API with their own provisioning may find the overlap uncomfortable, which matches the scope criticism in the thread.
Should you care?
If you rent GPUs, run one cluster or use a hosted cloud, probably not yet. NVKE is infrastructure for people who operate GPU fleets for others.
If you are a platform engineer at a GPU cloud, a university or an enterprise AI team, read the architecture docs. Three ideas are worth borrowing even if you never deploy it: per-tenant control planes, TPM-based node attestation before join, and building node images from pinned inputs.
The broader point is that Kubernetes is again a main battleground for AI infrastructure. We discussed that shift in the open-weight Kubernetes moment, and Google has its own orchestration push in AX. NVIDIA releasing its own management plane signals it wants the software layer, not just the chips.
How to evaluate it safely
- Read the architecture and limits sections in the README and the NVKE docs.
- Run the local quickstart on a disposable Linux VM with the stated resources.
- Do not expose the API. Enable authentication before any other user connects.
- Treat the FDE images as test-only.
- Watch the issue tracker: the repo showed 108 open issues and 74 open pull requests on November 7.
If you plan to let AI agents operate clusters through any API like this, restrict what they can do first.
Details are accurate as of November 7, 2026. NVKE is a preview, so APIs, requirements and star counts can change.
Related reading
- GTC Berlin 2026 keynote: everything announced
- NVIDIA DSX pod: claimed versus verified
- NVIDIA confidential bare metal for European AI clouds
- NVIDIA Mission Control 2.5 for GPU clusters
- GPU sharing on Kubernetes with CUDA 13.4
- The open-weight Kubernetes moment
- Official: dsx-ai-factory/nvke and NVKE docs