NVIDIA Open-Sourced Its AI Factory Layer. Here’s What It Means If You’re Building With Agents

Last updated: 7 November 2026

NVIDIA has published the software that turns a pile of GPU servers into a rentable, multi-tenant Kubernetes service. It is called NVIDIA Kubernetes Engine, or NVKE, and it is Apache-2.0 on GitHub. The tweet announcing it did modest numbers: 5,083 views and 154 likes by 7 November 2026. The Hacker News thread did a little better, 123 points and 27 comments. Neither number reflects what actually happened.

What happened is that the management layer of an AI factory became free software. Not the GPUs. Not the power. Not the building. The control plane that sits between a fleet of bare-metal machines and the customers who rent clusters on them. That is the layer a business used to have to build itself, and it is the layer most agent platforms are still getting wrong.

If you are building with AI, or building agents that you sell to business owners, this release is worth an hour of your attention. Not because you should install NVKE tomorrow. You should not, and NVIDIA says so itself. It is worth your attention because NVKE documents, in public, the exact architecture that a serious multi-tenant AI platform needs, and then lists, in public, every place where its own preview falls short. That list is a checklist you can hold against your own stack.

What NVIDIA actually released

NVKE is a management plane for GPU Kubernetes on bare metal. An operator installs it once, and then creates Kubernetes clusters for customers through an API or a CLI called nvkectl. Each workload cluster gets its own Kubernetes control plane, its own etcd store and its own node pools. The customer receives a kubeconfig and uses kubectl against their cluster. The operator keeps the management plane, the hardware and the billing relationship.

The README is careful about what NVKE is not. It is not a Kubernetes distribution, and it is not a Cluster API flavour. NVIDIA calls it a self-hosting factory for clusters: a temporary seed cluster stands up a highly available management cluster, and the management plane on that cluster then provisions and lifecycle-manages many isolated workload clusters on demand. The repository carries thirteen Go modules, three of which run in production: the NVKE controller, the node agent and the Cluster API infrastructure provider.

The code is Apache-2.0, copyright NVIDIA Corporation and affiliates, 2026. At the time of writing, on 7 November 2026, the repository had 351 stars, 78 forks, 182 open issues and 8 releases. It was created on 4 August 2026 and its latest release, v0.23.1, shipped on 3 November 2026. The project is a preview. The README says plainly that NVIDIA does not recommend it for production workloads.

The lifecycle features are the ones a service provider needs: create, scale and delete node pools, replace nodes, upgrade Kubernetes, renew certificates. Networking is an NVIDIA-curated build of OVN-Kubernetes, version 2.4.2. Kubernetes is pinned at 1.36.3. Node images are Ubuntu 24.04 LTS or 26.04 LTS on amd64 or arm64. Cluster API is pinned at v1.13.6 and Helm must be version 4.2.4, because Helm 3 cannot install the charts.

The detail that separates this from a generic installer is node identity. Before a machine receives a join credential, it attests through SPIFFE and SPIRE using its TPM. SPIRE 1.14.1 with the TPM plugin 1.9.0 is baked into the node image. etcd encryption at rest is available per cluster. That is a hardware-rooted chain of trust, not a shared secret copied into a cloud-init script.

Why this landed now: the AI factory stack went open source in June

NVKE is not a standalone product launch. It is the Kubernetes layer of DSX OS, the open-source operational software inside NVIDIA’s DSX AI factory platform, which was announced at GTC Taipei on 1 June 2026. NVIDIA’s developer blog describes DSX OS as modular software for operating multi-tenant AI factories at gigawatt scale, and it lists the components that surround NVKE: NICo for bare-metal lifecycle and BlueField DPU tenant isolation, AICR for validated runtime recipes, NVSentinel for GPU fault detection, Fleet Intelligence for fleet visibility, MaxLPS for power management, and KAI Scheduler, Dynamo and NVCF for scheduling and inference.

The commercial logic is straightforward. NVIDIA sells GPUs, not operations software. Every month a new GPU cloud spends rebuilding cluster lifecycle, fault handling and power management is a month of delayed silicon orders. Open-sourcing the operational layer removes that bottleneck for the whole ecosystem while keeping the hardware paid. It also deepens lock-in: every component is tuned for NVIDIA silicon, from NVFP4 kernels to NVLink-aware scheduling. Free software, paid hardware, and a reference architecture that makes the hardware easier to finance.

The timing matters for a second reason. The GPU cloud market is already in a shakeout. Business Insider reported on 6 November 2026 that lenders are pulling back from smaller neoclouds, that NVIDIA launched a US$36 billion backstop programme in July 2026 and paused some deals in August over antitrust concerns, and that Gartner expects roughly 80% of neoclouds to cease operating independently by 2030. Becoming a GPU landlord is a capital game with consolidation already under way. The software layer above the metal is where a smaller operator can still compete.

For Australian readers there is a third reason. NVIDIA named Australia as a single sovereign AI programme in September 2026, grouping Firmus, Sharon AI, IREN, Megaport, ResetData, CDC, NEXTDC and AirTrunk under a shared 2-gigawatt buildout target for end-2027, built on DSX. Heidi and Atlassian were named as early beneficiaries. Gartner put sovereign cloud infrastructure spending at US$80 billion for 2026, up 35.6% year on year, with Asia-Pacific growing 87%. The local AI factory layer is being funded. What runs on top of it is still an open field.

The part that matters for your business is tenancy, not GPUs

Most agent platforms sold to business owners are multi-tenant in the database sense. There is one application, one control plane and a tenant_id column on every row. The customer’s data sits in the same tables as everyone else’s, and isolation is enforced by application code. That was acceptable while agents were toys. It stops being acceptable when an agent can read a payroll system, send email as the customer, or move money.

NVKE takes the opposite approach. Every customer gets a separate Kubernetes control plane, a separate etcd store and separate node pools. There is no shared application database where a missing WHERE clause leaks one customer into another. The isolation boundary is the cluster, and the operator’s management plane sits outside it. That is heavier than a tenant_id column. It is also the shape enterprise and government buyers are starting to demand, because it turns a software bug into a contained incident rather than a breach notification.

The same logic applies to agent credentials. NVKE hands a customer an admin kubeconfig for their own cluster and nothing else. The customer’s administrators then create narrower credentials inside it. The operator does not hold per-user accounts inside customer clusters. Translate that to an agent platform: the client should own the identity provider and the role definitions inside their own boundary, while you own the platform that provisions and operates it. That separation is what makes an audit answer possible when a buyer asks who can see their data.

There is a harder lesson in the roadmap. Per-customer API authorisation is listed as coming soon, not shipped. Today NVKE does no authorisation at all: every caller that authentication admits can call every endpoint, including the ones that create and delete workload clusters. The preview docs say to issue tokens only to people and systems that may manage every cluster. That is a striking admission for a product whose entire purpose is multi-tenancy, and it is the single most useful sentence in the repository for anyone building an agent platform. If your agent gateway authenticates a caller and then trusts them with every tenant, you have built the same gap.

The architecture worth copying into your own agent platform

Strip away the Kubernetes specifics and NVKE describes a pattern that maps cleanly onto agent systems. There is a control plane that owns global state and never runs customer work. There are isolated execution environments created on demand. There is a durable workflow engine for long-running operations. There is a node agent that proves its identity before it is allowed to join. And there is an API that is designed to be called by software rather than by a human with a terminal.

The controller’s request path is the most transferable detail. When a client calls the API to create a cluster, the handler writes the cluster record and a row in a workflow_outbox table inside one Postgres transaction. A separate outbox processor polls that table, starts the matching Temporal workflow, and marks the row processed. The API never starts a long-running job directly. Either both writes land or neither does, so a committed cluster always has its work queued, and a crash between the two cannot leave a half-created customer.

That is exactly the failure mode of a naive agent platform. An HTTP request arrives, the handler calls a model, the model calls six tools, the process restarts, and nobody knows which side effects happened. The fix is not a better model. It is transactional intent plus a durable queue, so that the request records what should happen and a worker reconciles it. Temporal is one implementation. The pattern is the point.

The second transferable detail is attestation. NVKE does not trust a machine because it has an IP address on the right subnet. It trusts it because the machine can prove, through a TPM-backed SPIFFE identity, that it is the machine the operator intended to provision. Agent platforms have an equivalent problem. A worker, a tool server or a subagent should not receive credentials because it connected to the right port. It should receive a short-lived identity that proves what it is and which tenant it belongs to. If your agent fleet authenticates with a static API key in an environment variable, you are one leaked dotfile away from a cross-tenant incident.

The third detail is that the management plane does not run customer workloads, and the customer does not see the management plane. That separation is what lets an operator upgrade, patch and replace customer clusters without the customer’s application noticing, and it is what lets a customer’s own team operate inside their boundary without being able to reach yours. In agent terms: your orchestration layer and your client’s execution layer should not share a blast radius.

What NVKE admits about itself, and why that is the useful part

The preview documentation is unusually candid. NVIDIA publishes a page called Preview status and known limitations that lists every gap, and the gaps are the same ones that show up in agent platforms that shipped too early. The management cluster cannot upgrade, scale or replace its own nodes. There is no management-plane upgrade procedure and no backup or restore procedure. The API serves plain HTTP on port 30080 with authentication off, and tokens cross the network unencrypted unless the operator puts TLS in front. A handed-over admin kubeconfig cannot be revoked, because NVKE does not rotate the cluster certificate authority. The full-disk encryption node image does not protect data at rest, because every node built from one image inherits the same volume key and the bootstrap passphrase stays in the GRUB configuration.

What the preview admits	What it looks like in an agent platform
No authorisation: any authenticated caller can delete any cluster	One admin API key that every internal service and every tenant integration shares
Plain HTTP, authentication off by default	An internal agent gateway with no TLS and no default-deny policy
Admin kubeconfig cannot be revoked	Long-lived tenant tokens with no rotation and no revocation list
No backup or restore for the management plane	Agent state in memory or in a single database with no tested restore
Management cluster cannot upgrade itself	An orchestrator that cannot be upgraded without downtime for every tenant
FDE image does not protect data at rest	Encryption at rest that exists on the slide but not in the key management
Node pool changes do not replace running nodes	Config changes that apply only to new agents, leaving old ones on stale policy

None of this makes NVKE a bad release. It makes it an honest preview. The useful move is to read the list as a maturity scorecard. A platform that has not solved per-tenant authorisation, credential revocation, backup and restore, and self-upgrade is not ready to hold another business’s operational data, regardless of how good its demo looks. NVIDIA says that about its own product. You should say it about yours.

Five questions to ask any AI platform vendor, including yourself

If you are buying an agent platform, or building one to sell, the NVKE documentation gives you a short, concrete interrogation list. These are not abstract security questions. Each one has a yes or no answer that a vendor should be able to give without a slide deck, and each one maps to a failure that has already happened somewhere in this market.

One: who can delete a tenant? Ask for the authorisation model, not the authentication model. Authentication proves who is calling. Authorisation decides what they can touch. If every internal service holds a token that can reach every tenant, the answer is everyone. NVKE ships without authorisation and says so. Ask your vendor whether they do the same.

Two: can you revoke a customer’s access without deleting their data? NVKE cannot revoke a handed-over admin kubeconfig, because it does not rotate the cluster certificate authority. That is a preview limitation, but it is also a design choice that shows up in agent platforms as long-lived tokens with no revocation path. If the only way to cut off a compromised integration is to delete the tenant, the platform is not ready for a business that has staff turnover.

Three: what happens to a job if the orchestrator restarts mid-run? Ask for the durable execution story. NVKE uses Temporal workflows fed by a transactional outbox, so a crash resumes from the last completed step rather than starting over. An agent platform that loses the thread on a restart will either duplicate side effects or silently drop work. Both are unacceptable when the side effect is an invoice or an email to a customer.

Four: how does a worker prove it belongs? Ask what identity a tool server or worker presents, how long it lives, and what it is scoped to. NVKE uses TPM-backed SPIFFE identities, which is stronger than most agent platforms need, but the principle scales down: short-lived, audience-scoped credentials beat a shared API key every time.

Five: can you restore the control plane? NVKE has no backup or restore procedure for the management plane at preview, and it tells you to keep the etcd encryption key file somewhere safe because it is the only copy not on a node. Ask your vendor when they last restored from backup, and how long it took. A platform that has never tested a restore does not have a backup.

Build, rent or resell: a 90-day decision for business owners

There are three positions a business can take in this stack, and they have very different capital profiles. Building your own GPU cluster is the most expensive and the least differentiated. Renting capacity from an AI factory operator is the cheapest way to start and the easiest to exit. Reselling managed clusters on someone else’s metal, which is what NVKE is designed for, sits in between: you own the customer relationship and the software layer, and the operator owns the hardware and the power.

For most business owners building agents, the right move in the next 90 days is to rent, and to spend the saved capital on the layer that actually differentiates: the agent workflows, the integrations and the evaluation data. The infrastructure is becoming commodity software at speed. NVIDIA just gave away the management plane, and the DSX components around it are open source too. Competing on cluster provisioning is a race to zero.

The exception is a business that already has a reason to own metal: a data-residency obligation, a latency-sensitive workload, a regulated client base, or an existing data centre relationship. For those, the NVKE model is worth studying even if you never install it, because it shows what a credible managed-cluster service looks like: per-customer control planes, hardware-rooted node identity, a durable workflow engine and an API-first interface. If you are going to resell capacity, resell it with those properties, not with a shared namespace and a promise.

One more number belongs in this decision. NVIDIA claims DSX MaxLPS can recover stranded power to run up to 40% more GPUs inside the same megawatt budget, using 45-degree Celsius liquid cooling. If that claim holds for your operator, the cost per token falls without new power. Ask any GPU provider what they are doing on tokens per megawatt, not on peak FLOPS. The operators who can answer that question are the ones likely to survive the consolidation Gartner is forecasting.

Frequently asked questions

What is NVIDIA Kubernetes Engine (NVKE)?

NVKE is an open-source management plane for running Kubernetes on NVIDIA GPU hardware. An operator installs it once, then creates isolated Kubernetes clusters for customers through an API or the nvkectl CLI. Each workload cluster has its own control plane, etcd store and node pools. It is Apache-2.0, published by NVIDIA in August 2026, and currently in preview.

Is NVKE ready for production?

No. NVIDIA’s own documentation says it does not recommend NVKE for production workloads. The preview has no per-customer authorisation, serves its API over plain HTTP with authentication off by default, cannot upgrade or back up its own management plane, and cannot revoke a customer’s admin kubeconfig. It is an evaluation release, not a service you can sell today.

Do you need NVIDIA GPUs to try NVKE?

No. The local quickstart runs on one Linux machine or VM with at least 6 CPUs, 12 GiB of free memory and 100 GiB of free disk, plus Docker and virtual TPM support. It uses mock-NICo, a simulator that answers the NVIDIA Infra Controller API and starts each workload cluster node as a Docker container. No GPU and no NVIDIA account are required.

What does NVKE mean for a small business building AI agents?

Mostly it is a blueprint, not a product to install. The architecture shows what serious multi-tenancy looks like: one isolated control plane per customer, hardware-rooted node identity, a durable workflow engine and an API-first interface. The limitations list shows what to demand from any platform vendor, including the one you are building. The release also confirms that the infrastructure layer is commoditising, which pushes value toward agent workflows and integrations.

Should I build my own GPU cluster or rent capacity?

For most businesses, rent. Building GPU capacity is capital intensive, and Gartner expects roughly 80% of neoclouds to cease operating independently by 2030. Renting lets you move the spend to the layer that differentiates: agent design, integrations, evaluation and support. Own metal only when a data-residency, latency or regulatory requirement forces it.

What is an AI factory?

An AI factory is a data centre designed around a fixed power budget rather than floor space, where compute, networking, cooling and software are co-designed to maximise tokens produced per megawatt. NVIDIA’s DSX platform is its reference design for these facilities, and NVKE is the Kubernetes management layer inside DSX OS, the open-source operational software that runs them.

The short version

NVIDIA has made the management layer of an AI factory open source. That lowers the barrier to running a managed GPU Kubernetes service, and it confirms that cluster provisioning is becoming commodity software. For a business owner building agents, the release is less interesting as a product than as a design document. It shows the isolation model that enterprise buyers will expect, the identity model that keeps a worker honest, and the durable execution model that stops a crashed orchestrator from duplicating side effects. It also shows, in unusual detail, what happens when a platform ships before it has solved authorisation, revocation, backup and self-upgrade.

The practical takeaway is not to install NVKE. It is to read its limitations page, hold it against your own platform, and fix the gaps before a customer’s auditor finds them. The infrastructure layer is being given away. The trust layer is not. That is where the next round of advantage sits for anyone selling AI to business owners.