Deep Dive of the Day Fleets, instances and domains in VCF 9.1: where the boundaries sit and why they matter
VCF 9 introduced a vocabulary that still trips people up in design reviews, so it's worth pinning down. Broadcom's fleet deployment models page describes a VCF fleet as a unified operational framework for deploying, managing and operating one or more VCF instances, and its designs use a single VCF Operations instance and a single VCF Automation instance to manage the environment. An instance is the next level down, and inside it sit the familiar management and workload domains and their clusters.
Paul Bryant's mental model write-up puts the ownership split neatly. Fleet-level services are shared across instances: VCF Operations, VCF Operations fleet management (which looks after the lifecycle of the management components), VCF Automation and the VCF Identity Broker. Each instance keeps its own SDDC Manager, management vCenter and management NSX. The practical consequence is that losing a fleet service hurts visibility, governance, lifecycle workflows and self-service, but it doesn't take away vCenter or your ESX hosts, so workloads keep running.
Domains are where you set blast radius and change windows, and clusters are your unit of capacity. That's why the write-up nudges you to schedule change at the domain or fleet level rather than vCenter by vCenter, and it lists running production workloads in the management domain among its anti-patterns, alongside out-of-band changes with no inventory or drift practice.
The TechDocs page builds four fleet designs on top of each other: a basic single-site fleet, site high availability across two availability zones, disaster recovery across regions (with VMware Live Recovery handling failover), and fault domains plus DR. The basic design is honest about its limit: a zone or region failure can take down the whole fleet, and growing beyond one site means moving to a multi-site model. It also notes that large estates may run several fleets, for example one per region, at the cost of more management overhead, and that latency between VCF Operations and every fleet component has to be checked against the published ports and protocols requirements.
For production, the gotcha is that fleet count, instance alignment, domain strategy and the SSO model are Day-0 choices that are expensive to reverse, so settle them before the first VCF Installer run rather than after. The write-up's suggested defaults are a good starting point: one fleet and one instance with several workload domains for a single site, one fleet with two instances for two sites, and either one fleet with several instances or one fleet per region for multi-region estates, depending on how much autonomy each region needs.
In a nested lab the boundaries show up when you tear things down. Devyn Harrington found that deleting an instance cleanly meant deactivating its VCF Operations registration, removing licence allocations and deleting the license server first, otherwise a replacement instance could sit in Pending Activation. If you rebuild labs often, script that clean-up alongside the deployment, and use "Delete from Disk" so the nested VMDKs actually give the space back.
Based on VCF Fleet Deployment Models (Broadcom TechDocs) Official VCF 9.0 GA Mental Model Part 1: Fleets, Instances, Domains (Digital Thought Disruption) Running VCF 9.1.1 on one physical homelab node (Devyn Harrington)
