What Is VMware VCF Automation and Who Needs It?

What it is, without the brochure

In many VMware estates an administrator creates a virtual machine whenever somebody asks. VCF Automation sits above the infrastructure and lets the people who ask do it themselves, within limits the platform team sets. Broadcom describes it as a way for IT teams and cloud service providers to deliver a self-service private cloud for AI, Kubernetes and VM-based applications, with policy-based governance and multi-tenant provisioning.

In practice there are three sides to it. A provider side, where infrastructure, quotas and networking are managed. An organisation side, where a business unit or customer administers its own users and resources. And a consumption side, where application teams request services such as VMs, Kubernetes clusters, volumes, databases or networking through the UI, API or CLI.

It is not a hypervisor and it does not replace vCenter. It is the request-and-governance layer that drives the infrastructure underneath.

The name change, and why it is not just a rename

Broadcom's documentation describes VCF Automation as formerly VMware Aria Automation, which itself grew out of vRealize Automation. That is a third name for the same lineage, so anyone searching old forum posts has our sympathy.

The 9.x release is a genuine change of design rather than a repaint. The 9.0 release notes describe the old Assembler, Service Broker and Orchestrator areas being merged into a single UI, with built-in multi-tenancy through organisations and new Kubernetes-based cloud services. Anything you remember about Aria Automation 8 should be checked, not assumed.

How it is organised: organisations, projects and two flavours

Tenancy is built around organisations. Each one is isolated and limited to the services and resources allocated to it, and comes with predefined roles for organisation administrators and application teams. Projects represent application teams and, in 9.0, map to vSphere namespaces with resource limits.

VCF Automation 9 offers two organisation types, labelled in the product as Organization for All Apps and Organization for VM Apps. Broadcom's own blog describes All Apps as designed for the broadest range of workloads, covering traditional VM application stacks and container-based microservices. Independent write-ups describe VM Apps as the experience closest to Aria Automation 8.x, which is the sensible starting point for teams that mainly deploy VMs from blueprints. Broadcom material also notes that feature availability differs between the two, so check the feature list for your exact version before choosing.

The 9.0 release notes say VPC workload networking is a prerequisite for All Apps organisations. That is a networking design decision rather than a tick box, and it is worth knowing before anyone promises the business Kubernetes next month.

What disappeared from Aria Automation 8

If you currently use Aria Automation, this is the section that matters. Broadcom's 9.0 product support notes and prechecks article list functionality that is removed or unsupported, including:

• Shared-infrastructure multi-tenancy (Virtual Private Zone and provider image management).
• Adding VMware Cloud Director as a cloud account.
• The Cloud Consumption Interface.
• Kubernetes integrations such as TKG, PKS, OpenShift and TMC.
• NSX-V and NSX-T cloud accounts, including the NSX-T Manager mode.
• Avi Load Balancer cloud accounts, which Broadcom's article expects to return in a future release.
• Pipelines.

Moving to it from older products

Broadcom's July 2026 technical articles describe upgrades from Aria Automation 8.18.1 or later, and from VCF Automation 9.0.x to 9.1, as managed through Fleet Lifecycle in VCF Operations. They are not in-place patches. A new cluster is deployed beside the old nodes and data is migrated across. For the Aria Automation route, Broadcom says downtime starts when the source environment is powered off partway through the process, and returns once the new cluster is serving traffic. Plan a maintenance window, not a lunch-hour change.

Cloud Director users have a separate path. Broadcom's knowledge base says migration to VCF 9.1 requires first upgrading to Cloud Director 10.6.2, and Broadcom's provider blog describes running an Environment Assessment Tool as the first step. Broadcom has not, in the sources we reviewed, stated a Cloud Director end-of-support date, so we are not asserting one.

If you run NSX-V, NSX-T Manager mode accounts or any of the removed features above, Broadcom's guidance is to pause and have a migration plan before upgrading. Removing an NSX endpoint is described as highly disruptive to existing deployments.

Do you need to care?

This is our judgement rather than vendor guidance, but the split is fairly clean.

You can probably leave it alone if you run a handful of VMs on vSphere, Hyper-V or Proxmox and nobody needs a self-service catalogue. VCF Automation earns its keep where several teams or tenants need governed self-service, where Kubernetes is a first-class workload, or where a provider hosts customers. For a small estate it is likely more platform than the job needs.

You should look closer if you already run Aria Automation, Aria Suite Lifecycle or Cloud Director, because the product names, lifecycle tooling and feature set are changing under you. Entitlement is a licensing question to settle with your Broadcom reseller before you plan anything. We have not covered it here.

What to check against your version

Broadcom's documentation now covers both 9.0 and 9.1, and a banner on the 9.1 pages notes 9.1.1 is generally available. Several of the details above come from 9.0-era notes. Feature lists, organisation-type behaviour and upgrade paths have moved between releases, so confirm any decision against the TechDocs for the exact version you intend to run.