Why Flow Standalone in NCI 7.5 Is a Design Choice, Not an Upgrade
Powerful by nature. Intentionally not retrofittable.
For a long time, networking and security inside infrastructure platforms were treated as extensions of management. Powerful features, tightly coupled to the lifecycle, availability, and scale of a central UI.
With Nutanix NCI 7.5, that assumption starts to break.
Flow standalone is not about adding new capabilities. It is about separating responsibilities. And once you look at it from that angle, many of its constraints suddenly make sense.
Centralized management was the easy answer
When platforms were smaller, centralization worked.
One Prism Central, one place to define policies, one lifecycle. Networking, security, inventory, and operations all lived inside the same control plane.
At scale, that model becomes fragile.
Network and security grow faster than management. They change more cautiously. Their blast radius is higher. And tying their enforcement to the same plane used for day-to-day operations creates hidden coupling.
Hidden coupling always shows up at the worst possible time.
Network and security behave differently from management
Management tolerates churn. Network and security do not.
Security policies must survive management upgrades, partial outages, restore operations, and multi-site or multi-domain topologies. They are expected to remain stable precisely when the rest of the platform is changing.
They also follow a different scaling logic. Adding routes, VPCs, or security policies should not automatically force the management plane to grow.
This mismatch between how management scales and how network and security behave is the architectural problem Flow standalone is addressing.
Flow standalone is about separation of responsibility
It is tempting to describe Flow standalone as an availability feature. Separating the Flow control plane from Prism Central does improve resilience.
But availability is not the real reason.
The real reason is architectural decoupling.
Flow standalone moves network and security enforcement to a control plane that:
- runs at the cluster level
- has its own lifecycle
- enforces policies independently from Prism Central availability
Prism Central remains the governance plane. Flow becomes the enforcement plane.
This is not a feature toggle. It is a correction in platform design.
Scaling network without scaling management
One of the real advantages of Flow standalone is architectural, not functional.
Without it, increasing network complexity often forces you to scale Prism Central, even when governance requirements stay the same. More VPCs, more routing, more security policies translate into more load on the management plane.
Flow standalone breaks this dependency.
Network and security scale where enforcement happens, on the cluster. Prism Central scales only when governance needs grow, not because routing does.
Each layer now scales for what it is responsible for.
Why this is not an in-place upgrade
This separation has a very concrete implication.
Flow standalone cannot be enabled on a live production cluster already using VPCs.
If a cluster has VPCs, VLAN subnets, or external subnets, the Network Controller cannot be disabled. And without disabling it, Flow standalone cannot be introduced.
This is not a limitation. It is an explicit architectural boundary.
Disabling the Network Controller would mean tearing down the active network model. The platform is not blocking an operation. It is protecting the integrity of the network control plane.
Flow standalone is not a migration path.
It is a design choice that must be made day zero, or introduced on a new cluster with workload migration.
Flow standalone makes sense when you are designing a new cluster, introducing new network domains, or redefining enforcement boundaries. Not when trying to retrofit an existing VPC-based environment.
This becomes immediately visible when attempting to disable the Network Controller on a live VPC-based cluster.
Enforcement survives management outages
Once deployed, Flow standalone continues enforcing policies even if Prism Central is unavailable.
What stops is change, not enforcement.
There is no supported fallback to Prism Element or CVM-level access to manage Flow standalone. Governance remains centralized, enforcement remains local, and the two are never mixed.
A familiar pattern in NCI 7.5
This mirrors what we already see in other areas of the platform.
As seen with the dark site upgrade orchestrator, Nutanix increasingly separates orchestration and governance from execution and enforcement. Upgrades, lifecycle operations, and now networking follow the same pattern.
Central intent. Distributed execution.
A consistent direction across the platform
Flow standalone fits cleanly alongside other NCI 7.5 pillars.
Infrastructure Manager enforces architectural intent.
Dark site tooling proves that control planes must operate under constraints.
Flow standalone enforces network and security without tying their fate to management scale or availability.
Seen together, these are not isolated features. They are signals of a platform moving from trust-based operations to control-based design.
Designing differently from day zero
Once network and security have their own control plane, architecture changes from the first diagram.
You stop designing around management availability and upgrade windows. You start designing around explicit enforcement, isolated failure domains, and predictable behavior under stress.
This is not additional complexity. It is architectural maturity.
Closing the loop
Flow standalone is powerful precisely because it cannot be casually enabled.
It forces you to make network and security explicit architectural decisions, not operational afterthoughts.
Flow standalone works best when it is planned, not discovered.