architecture

Centralising GitOps: Argo CD Lands Natively in VCF Automation 9.1.1

One Argo CD instance per hosting namespace, scoped to one region. It's Tech Preview, but the namespace design constraint applies now.

VCF 9.1.1 added a native Argo CD-based GitOps service to VCF Automation. It is in Tech Preview, which matters, but the architectural decisions inside it are worth understanding now because they will shape how you lay out namespaces and projects long before the service goes GA.

Tech Preview

Not for production, and not something to build a delivery pipeline commitment around yet. Read it as a statement of direction and a chance to get your namespace design right before it lands properly.

What was actually shipped

An Argo CD-based GitOps service, native to VCF Automation, available to Org users. Argo CD is the CNCF project that treats a Git repository as the single source of truth for Kubernetes state, continuously reconciling the live cluster against what is declared in the repo and correcting drift automatically.

Choosing Argo CD rather than building something proprietary is the right call and worth noting. Per the 2025 CNCF End User Survey it is now the dominant GitOps tool, managing close to 60% of Kubernetes clusters. Teams arriving at VCF with existing GitOps practice bring their repositories and their habits with them rather than relearning a platform-specific tool.

The deployment model, and why it constrains your design

This is the part that belongs in a design document rather than a release summary.

The rule

One Argo CD instance per hosting namespace.

That instance can be scoped to synchronise declarative resources across multiple vSphere Namespaces and VKS clusters, provided they sit within the same region.

Three consequences follow from that, and none of them are obvious from the announcement.

The hosting namespace becomes a delivery boundary, not just a resource boundary. If you have been treating namespaces purely as a way to carve up quota and access, that model now carries a second meaning. An Argo CD instance lives in one, and everything it manages is reached from there.

Region is a hard edge. The scope covers multiple namespaces and multiple VKS clusters, but only inside one region. A multi-region estate needs multiple Argo CD instances by construction. Any design that assumed one control point for continuous delivery across regions needs revising.

Organisational boundaries survive. Broadcom is explicit that project users can collaborate on delivery targets without compromising organisational boundaries or security postures. That is the difference between a centralised GitOps service and a shared Argo CD instance somebody stood up by hand, which almost always ends up with either too much access or a proliferation of instances nobody tracks.

The problem it is solving

Anyone who has run Kubernetes at enterprise scale recognises the pattern. Platform teams provide clusters. Application teams want continuous delivery. Nobody owns the layer between them, so each team stands up its own Argo CD, and within a year you have a dozen instances with a dozen different access models, a dozen upgrade cycles, and no central view of what is deployed where.

That is not a tooling failure. It is what happens when a capability everyone needs has no owner. Centralising it inside VCF Automation puts the delivery layer under the same operating model as the infrastructure underneath it, which is the whole argument for a platform rather than a collection of products.

What to decide before it goes GA

Which namespace hosts the Argo CD instance for each region. This is a design decision with a long tail, and it is much cheaper to make deliberately now than to move later.
How many instances your region topology actually requires. Count them. If the answer surprises you, that is useful information about your regional design rather than about GitOps.
Who owns the Argo CD lifecycle. Platform team or application teams. Centralising the service does not by itself answer who patches it, who defines the sync policies, or who is called when a sync fails at 2am.
What happens to the Argo CD instances you already have. Most estates running VKS have some. Migration onto a native service is a project, not a switch, and it needs a plan before the service is GA rather than after.
Whether your repository structure matches the namespace scope. If one repo currently serves clusters in three regions, and the service is scoped to one region per instance, something has to change. Better to know which.

The honest assessment

Tech Preview means do not deploy it in production and do not plan a delivery commitment around a date. What it does not mean is ignore it. The namespace and region scoping is a design constraint that applies to how you lay out VCF Automation regardless of when the GitOps service ships, and getting that layout right is free now and expensive later.

The wider pattern is consistent with the rest of the 9.1 line. Take a capability every enterprise assembles by hand, make it native, and put it under the same organisational and security model as everything else. Whether that displaces your existing Argo CD estate is a separate question, and for most large estates the honest answer is partly.