Nutanix Tech Connect 2026: Kubernetes, Private AI, and the Platform Behind It All
After a slightly more eventful journey than planned, I finally made it to Nutanix headquarters in San Jose for Nutanix Tech Connect 2026.
Tech Connect is an invite-only event for Nutanix Technology Champions. Around 28 NTCs from seven countries spent two days with the product managers, engineers, executives, and community leaders who build and shape the Nutanix platform. It is much smaller and more interactive than a regular conference. We could ask detailed questions, challenge assumptions, share customer experiences, and discuss where the platform is heading.
Some sessions and roadmap discussions were under NDA, so this post only covers information I can share publicly.
My earlier posts from the trip focused on the practical deployment of Nutanix Central and Service Provider Central:




This post is the bigger picture: what stood out across the entire event.
Day one: Kubernetes becomes a complete platform
The first day was dominated by cloud native infrastructure and the Nutanix Kubernetes Platform (NKP). I deployed NKP after the 2024 Tech Connect, but the platform has moved forward significantly since then.
The central message was simple: enterprises do not want Kubernetes to become another collection of tools that every team must assemble, secure, upgrade, and troubleshoot independently. They want a consistent platform that can run in the datacenter, in public cloud, at the edge, and increasingly on bare metal for AI workloads.

One platform for cloud native and AI
NKP combines upstream Kubernetes with a validated cloud native stack and centralized lifecycle management. The goal is to automate both day-one deployment and day-two operations while keeping workloads portable.
Several capabilities made that direction clear:
- A unified Nutanix registry provides hardened and scanned container images from a controlled source.
- Projects 2.0 expands the project boundary beyond virtual machines. Images, persistent volumes, networks, quotas, RBAC, and related resources can belong to the same tenant boundary.
- Simplified upgrades bring more of the familiar Nutanix one-click operating model to Kubernetes, including preflight and post-flight checks.
- The Nutanix AHV VM Operator lets developers manage virtual machines through Kubernetes APIs and GitOps workflows while infrastructure teams retain governance in Prism Central.
- NKP Metal extends the operating model to bare-metal workers, which matters when GPU density, performance, or specialized hardware makes virtualization less suitable.

For me, Projects 2.0 was especially relevant. We operate Nutanix as a service provider, and a tenant boundary is only useful when it covers the full resource lifecycle. A project that contains the VM but leaves its image, volume, or networking outside the same governance boundary is incomplete. The new model is much closer to how an MSP needs to delegate and control infrastructure.
Resilience is more than a replica count
One of the strongest architecture sessions covered NKP deployment topologies and resilience.
A Kubernetes cluster can look healthy while still having a hidden failure-domain problem. Three control-plane nodes do not provide real high availability if two of them run on the same physical host. The same applies to workers and application replicas. Availability depends on placement, anti-affinity, topology spread, storage, and network design working together.
The sessions covered single-cluster and multi-cluster environments, management-cluster backup to S3-compatible storage, multi-zone designs, stretched clusters, and site-failure patterns. Nutanix CSI 3.x and Nutanix Data Services for Kubernetes add important storage and replication options, especially for stateful applications.
My main takeaway: infrastructure survival and application availability are not the same thing. You need to design both, and the magic word of the day:
Quorum!
Security at fleet scale
Kubernetes security also becomes harder as the number of clusters grows. Identical clusters gradually drift, certificates expire, deprecated APIs remain unnoticed, and thousands of CVE findings can hide the few issues that actually matter.
NKP Insights is designed to correlate signals from tools such as Trivy, Kube-bench, Polaris, Kubernetes events, and alerts. Instead of presenting another long list, it creates a prioritized insight with scope, root cause, and remediation guidance. The architecture is also designed for disconnected environments, which is important for many Nutanix customers.

That correlation is more valuable than adding yet another scanner. At fleet scale, the challenge is no longer finding data. It is deciding what deserves attention first and confirming that a fix remains fixed.
Day two: Agentic AI needs an operating model
The second day shifted heavily toward Nutanix Enterprise AI, private inference, and the Nutanix Agent Gateway.
AI conversations often start with models and GPUs. The sessions at Tech Connect focused more on the operational questions that appear when experiments become production services:
- Where does data go?
- Who can access each model and tool?
- How do you control credentials and token consumption?
- How do you route requests across private and public models?
- How do you observe, secure, and audit agent activity?
Those are infrastructure and governance questions, not only data-science questions.
From AI infrastructure to an AI factory
Nutanix described its AI platform as a full stack: accelerated hardware, infrastructure optimization, an AI-ready Kubernetes platform, and a catalog of AI services above it.
NKP provides the Kubernetes foundation across virtualized and bare-metal infrastructure. The catalog brings validated components for GPU operators, scheduling, inference, notebooks, vector databases, and agent tooling. Nutanix Private Inference manages open-weight models and inference services, while the Agent Gateway controls how agents reach models and enterprise tools.
The "run anywhere" aspect matters. A company may use private inference for sensitive workloads, a public provider for frontier models, and specialized models for specific tasks. The architecture should support that choice without creating a separate governance model for every endpoint.
Nutanix Agent Gateway
The Agent Gateway was one of the most interesting parts of the event. It acts as a central entry point between agents, models, and tools.
Agents can use one endpoint while policies route requests to public providers, private models, or other inference services.
MCP connections provide controlled access to enterprise tools. The gateway can apply authentication, authorization, credential management, tool filtering, token limits, logging, metrics, and tracing.

Under the hood, the gateway builds on open-source technology including Agent Router and Envoy AI Gateway. Nutanix adds the enterprise layer around identity, management, integrations, user experience, and support.
This is where the AI story became concrete for me. Enterprises do not only need a place to run a model. They need a control point for everything an autonomous agent can reach and do.
Service experience is part of the product
My favorite session of the event was the discussion about service strategy, release management, Lifecycle Manager (LCM), Nutanix Validated Designs, diagnostics, and support. It connected directly to the operational work we do every day, and I probably asked more questions here than in any other session.

That sounds obvious, but it changes how product quality is measured. A technically successful upgrade is not enough if customers lack the information needed to decide whether to perform it, cannot understand a failure, or have to open a support case for something a qualified partner could have solved independently.
More confidence before an upgrade
Nutanix has moved from separate LTS and STS tracks toward a more predictable release model with feature, maintenance, and patch releases. New versions become available through the support portal first and are then introduced into LCM in controlled stages while Nutanix monitors adoption, feedback, and quality.
This explains why a release may be generally available but not immediately visible as a one-click LCM update. Customers who need a specific feature can download it manually, while others can wait until the release has progressed through staged adoption.
The discussion also became very practical. Firmware inventory is often slower than software inventory because LCM must collect information through hardware-vendor tooling before it can filter and evaluate the result. Upgrade time can also grow when dependencies require repeated validation, retries, or separate reboots. Nutanix is looking at better batching and ways to avoid unnecessary work without weakening the dependency handling that makes LCM valuable in the first place.
For larger environments, that distinction matters. The question is not only whether an upgrade is supported. Operators need enough visibility to judge its maturity, expected maintenance window, known risk, and relevance to their own environment.
Partners need deeper access to knowledge
This led to one of the questions I cared most about. As Nutanix partners, many of us have experienced support cases where the solution eventually comes from an internal knowledge base article. In some cases, we already have enough product knowledge to diagnose and resolve the issue, but we cannot see the information that confirms the fix.
I asked whether partners and advanced users could receive greater access to internal knowledge. The goal is not unrestricted access to dangerous procedures. It is to let qualified partners solve more issues for customers without opening a case for every known problem.
The answer gave useful insight into the work happening behind the scenes. Nutanix categorizes knowledge base articles as external, partner-facing, or internal and tracks that distribution by product. Teams have an explicit objective to increase the percentage of externally available content, and SREs who work with real cases are now more involved in keeping that knowledge current.
There are valid reasons why some articles cannot simply be published. An internal workaround may involve low-level configuration changes that are too risky without support supervision. The better long-term answer is to turn that workaround into a product fix, guardrail, or safe UI workflow. The public article can then point customers to a fixed release instead of documenting a potentially destructive internal procedure.
I liked that answer because it acknowledged both sides of the problem. More transparency helps capable partners deliver faster support, but publishing every internal command is not the same as creating safe self-service.
NIVA: a new front door to Nutanix knowledge
We also spent time on NIVA, the Nutanix Intelligent Virtual Agent in the support portal. NIVA accepts questions in natural language, searches vetted Nutanix sources such as KB articles, troubleshooting guides, and advisories, and returns summarized guidance with links to the underlying material.
NIVA is not intended to replace version-specific documentation or the compatibility matrices. It is a faster way to find the right starting point and the next useful action. That distinction is important because the correct answer can depend on the exact AOS, AHV, Prism Central, hardware, and configuration versions involved.
I followed up on the relationship between NIVA and the KB-access question. For partners and advanced users, NIVA could provide deeper answers based on their entitlement and technical level, helping us resolve more problems ourselves instead of immediately calling support. The team agreed with that direction and asked us to keep providing feedback as the service improves.
We also saw where it still has room to grow. I had recently asked NIVA which AHV version was bundled with a particular AOS version. It correctly directed me to the interoperability matrix but could not provide the answer directly. That was not a wrong result, but it is a good example of the difference between finding the documentation and completing the operational task.
Another interesting suggestion was to let NIVA understand the authenticated customer's own environment. Instead of manually navigating the portal, an operator could ask questions about registered assets, installed hardware, software versions, or affected clusters. That capability was not available during the session, but the feedback was well received.
From reactive support to guided self-service
The Insights Portal and Discoveries complete the picture. They provide global asset visibility, software and hardware timelines, impact-based health information, and actionable findings. For issues such as a failed LCM upgrade, the platform can automatically collect the relevant log bundle so it is ready if a support case is needed. One-click diagnostics reduce the time spent gathering the same information after the case has already started.
The same session tied together several ways to reduce operational risk:
- Start with a Nutanix Validated Design for architecture, sizing, integrations, and operating guidance.
- Use release notes and compatibility information before an upgrade.
- Use Insights and telemetry to identify risks before they become incidents.
- Use NIVA, guided diagnostics, and trusted knowledge sources to shorten troubleshooting.
- Give qualified partners enough information to resolve more known issues independently.
- Feed customer cases and product telemetry back into better guardrails and documentation.
The feedback loop also works in the other direction. Customers and partners can rate KB articles and NIVA responses, explain what is unclear, and have that feedback routed to the responsible team. I have used the KB feedback function myself and seen Nutanix follow up with questions, so this is not a feedback button that disappears into a black hole.
This session may sound less exciting than a new AI feature, but it was the highlight of Tech Connect for me. Better release visibility, safer self-service, deeper partner knowledge, and support tools that understand the customer's environment can have an immediate effect on the people operating Nutanix platforms every day.
Direct access to the people building Nutanix
Tech Connect is valuable because it is not only a sequence of presentations. The room is small enough for real discussion.
We could ask detailed questions directly to product managers and engineers, discuss practical problems from our environments, and give feedback on priorities. We also had an open session with Nutanix CEO Rajiv Ramaswami and a workshop about the future of the NTC program.

The technical content was excellent, but that access is what separates Tech Connect from a normal conference. Slides explain what a product does. Conversations explain why decisions were made, what trade-offs exist, and where customer experience does not yet match the intended design.
My five takeaways from Tech Connect 2026
- Kubernetes is becoming a core part of the Nutanix platform NKP is no longer an isolated cloud native product. It connects infrastructure, storage, security, lifecycle management, AI, and developer self-service.
- Enterprise AI is primarily an operating-model challenge Models change quickly. Governance, identity, observability, data control, and cost management must remain consistent.
- Private and public AI will coexist The useful architecture is not "everything private" or "everything public". It is the ability to route each workload to the right model under one policy framework.
- Day-two operations remain the differentiator One-click deployment gets attention, but upgrades, diagnostics, resilience, and support determine whether a platform succeeds in production.
- Community feedback still matters Putting NTCs in the same room as product and engineering teams creates honest conversations that are difficult to reproduce through surveys or support cases, and this is the strength of this community, we as NTCs can be honest and speak out when something is not good enough, and we definitely get listened to.
Tech Connect 2026 showed a Nutanix platform expanding in two directions at once. NKP is becoming the consistent runtime for cloud native and AI workloads, while Nutanix Enterprise AI adds the inference and governance layers needed for agentic applications. Around both sits the less glamorous but essential work of tenancy, security, upgrades, resilience, and support.
The common thread is operational consistency: one platform, one control model, and the freedom to run workloads where they make sense.
Two very full days, a notebook full of ideas, and plenty of new things to test when I get home. A big thank you to Angelo Luciani and the Nutanix team for organizing the event, and to everyone who shared their knowledge and joined the discussions.
Now it is time to turn those notes into labs, so stay tuned :)