Offline VMware Cloud Foundation 9 Depot: Your Path to Air-Gapped Deployments

Running VMware Cloud Foundation somewhere that can’t talk to the internet takes a bit of planning, and the piece that trips most people up is the software depot. When this post first went up it covered building an offline depot for VCF 9.0. A lot has moved since then. VCF 9.1 changed how the download tool authenticates, added new components that have to be installed during an upgrade, and gave 5.2 customers a direct path to 9.1. So I rebuilt the post around all of that.

Updated October 5, 2026: Rewritten for VCF 9.1.1 and VCF Download Tool 9.1.1, with a new section on upgrading an air gapped VCF 5.2.x environment to 9.1.x. The old VCF 9.0 commands are still near the bottom if you need them.

---

What Changed in VCF 9.1

If you built your depot from the original version of this post, the first thing you will hit is authentication. The download token from the Broadcom Support Portal is gone for 9.1. You now generate a software depot ID with the download tool, register it in the VCF Business Services console, and get an activation code back. Every 9.1 command also wants --sku VCF (or --sku VVF if you own vSphere Foundation).

ESX content moved to its own command, esx download, and you need it because vLCM images are the only option in 9.x. Download Tool 9.1.1 also grabs only the newest patch of each component unless you pass --latest false, and it picked up an artifacts command for things like Supervisor content.

On the web server side, Broadcom now supports plain HTTP with no authentication for the 9.1 software depot and VCF Installer, on top of the HTTPS options. The catch is that the Installer UI still only takes HTTPS, so an HTTP depot there has to be set through the API. Broadcom also now recommends giving the depot its own disk of at least 1 TB, which lines up with what I have seen in my lab.

Last one. The old Offline Bundle Transfer Utility is not supported against SDDC Manager 9.x. Once you are on 9.x, the VCF Download Tool is the only supported way to get binaries into a dark site.

What You Need

• A Broadcom Support Portal login with VCF entitlement, plus access to the VCF Business Services console at vcf.broadcom.com with rights to create software depot registrations.
• VCF Download Tool 9.1.1 or newer.
• A Linux VM with internet access (direct or through a proxy), a static IP and a 1 TB data disk. I use Photon OS and wrote up the build here: Deploying and Configuring the VMware LCM Bundle Utility on Photon OS
• A web server on that VM. Apache, NGINX, whatever you like, as long as it does TLS 1.2 and 1.3 if you serve HTTPS.
• TCP keepalive turned on in your SSH client. Some of these downloads run for hours.

If your proxy uses Kerberos or NTLMv2 authentication, stop here and sort that out first, because VCF won’t work through it.

And if you would rather skip the manual build entirely, Airlock Depot is my open source appliance that wraps this whole process into a Photon OS OVA.

Step 1: Get the VCF Download Tool

In the Broadcom Support Portal go to My Downloads, then VMware Cloud Foundation, pick the version you are heading to (9.1.1 as I write this) and open Drivers & Tools. The download tool is in that list.

Copy it to the depot VM and extract it. I keep mine in /root/.

tar -xzvf vcf-download-tool-<version.build>.tar.gz
cd vcf-download-tool-<version.build>/bin/

Make sure everything in bin/ is executable. You will see two tools in there, vcf-download-tool and the older lcm-bundle-transfer-util. Everything in this post uses the first one.

Run it with no arguments and it lists its command groups. The ones you will use most are binaries for VCF component downloads, esx for ESX content and vendor depots, and artifacts for Supervisor content. There is also configuration for generating the depot ID and depot for pushing files into a disconnected software depot.

Step 2: Get an Activation Code

Your activation code is tied to your entitlement. Treat it like a password.

First generate a software depot ID on the depot VM:

./vcf-download-tool configuration generate --software-depot-id

Then log into the VCF Business Services console. Use the tenant picker in the top left corner to select the tenant and site ID that hold your VCF entitlement, because picking the wrong one is an easy mistake. Go to Software Depot Registrations, click New Registration and paste in the ID. Save the code it gives you as a single line in a text file and lock the file down.

vi /root/activation-code.txt
chmod 600 /root/activation-code.txt

Step 3: Set Up the Depot Disk and Web Server

Broadcom’s reference build serves from /var/www/html. I stuck with /depot to match the original post, so change the path if yours is different.

mkdir -p /depot
mkfs.ext4 /dev/sdb
echo "/dev/sdb /depot ext4 defaults 0 2" >> /etc/fstab
mount -a
chmod 755 /depot

The download tool builds a PROD folder and your web server just needs to serve it. If you want basic auth, Broadcom’s Apache example protects PROD/COMP and PROD/metadata and leaves the vSAN HCL folder open. Here it is adjusted for /depot:

<Directory /depot/PROD/COMP>
    AuthType Basic
    AuthName "Basic Authentication"
    AuthUserFile /etc/httpd/conf/.htpasswd
    require valid-user
</Directory>
<Directory /depot/PROD/metadata>
    AuthType Basic
    AuthName "Basic Authentication"
    AuthUserFile /etc/httpd/conf/.htpasswd
    require valid-user
</Directory>
<Directory /depot/PROD/vsan/hcl>
    Require all granted
</Directory>

htpasswd -c /etc/httpd/conf/.htpasswd depotuser
chown apache /etc/httpd/conf/.htpasswd
chmod 0400 /etc/httpd/conf/.htpasswd

If you are upgrading from 5.2, don’t get clever with the new HTTP option yet. That support belongs to the 9.1 software depot and Installer. While SDDC Manager is still on 5.2, I would keep the depot on HTTPS with a trusted certificate and a basic auth user, then relax it later if your security team is fine with that.

Step 4: Download the 9.1 Binaries

I always run a list first. It proves the activation code works and shows how much you are about to pull down.

./vcf-download-tool binaries list --sku VCF --vcf-version 9.1.1 \
  --depot-download-activation-code-file /root/activation-code.txt \
  --type UPGRADE

Install Binaries

You need these for a new build with VCF Installer. You also need them when upgrading from 5.2, which surprised me at first. VCF management services and the license server don’t exist in 5.2, so they get installed rather than upgraded.

./vcf-download-tool binaries download --sku VCF --vcf-version 9.1.1 \
  --depot-download-activation-code-file /root/activation-code.txt \
  --type INSTALL --automated-install --depot-store /depot

Upgrade Binaries

./vcf-download-tool binaries download --sku VCF --vcf-version 9.1.1 \
  --depot-download-activation-code-file /root/activation-code.txt \
  --type UPGRADE --depot-store /depot

ESX Binaries and Metadata

./vcf-download-tool esx download \
  --depot-download-activation-code-file /root/activation-code.txt \
  --depot-store /depot

Be patient with this one. It pulls thousands of small files and the console does not tell you much, so I tail ./logs/esximage.log in a second session. If you use a hardware vendor add on, register their depot before you run it with ./vcf-download-tool esx configuration --add-url https://<vendor-host>/index.xml.

Artifacts and Patches

# vSphere Supervisor and other artifacts (VCF Download Tool 9.1.1 and later)
./vcf-download-tool artifacts download --sku VCF --vcf-version 9.1.1 \
  --depot-download-activation-code-file /root/activation-code.txt \
  --depot-store /depot

# Pull only the newest Express Patches
./vcf-download-tool binaries download --sku VCF --vcf-version 9.1.1 \
  --depot-download-activation-code-file /root/activation-code.txt \
  --type UPGRADE --patches-only --depot-store /depot

Patches for 9.1.1 components keep coming (the latest batch dropped October 12), and Broadcom wants you on the newest binaries whenever you deploy or upgrade. I run the upgrade and patch downloads again the day before every maintenance window.

After any download, fix ownership and permissions or the web server will throw 403s at SDDC Manager:

chown -R apache /depot
find /depot -type d -exec chmod 0500 {} \;
find /depot -type f -exec chmod 0400 {} \;

---

Upgrading VCF 5.2.x to 9.1.x from an Offline Depot

Good news first. You can go from 5.2.x straight to 9.1.x without stopping at 9.0. If you are on something older than 5.2, the management domain and every workload domain have to reach 5.2.x before any of this applies.

Pick 9.1.1 as Your Target

VCF only lets you upgrade to a release that came out after the one you are running. It checks that against every component in your BoM, not just SDDC Manager. Since 5.2.4 shipped after 9.1.0, a lot of people found they couldn’t go to 9.1.0 at all.

Source	Target	Supported
VCF 5.2.0 (25 JUN 2024)	VCF 9.1.0 (11 MAY 2026)	Yes
VCF 5.2.4 (27 MAY 2026)	VCF 9.1.0 (11 MAY 2026)	No
VCF 5.2.4 (27 MAY 2026)	VCF 9.1.1 (03 SEP 2026)	Yes
vCenter 8.0 U3j and ESX 8.0 U3j	VCF 9.1.0	No
vCenter 8.0 U3j and ESX 8.0 U3j	VCF 9.1.1	Yes

VCF 9.1.1 fixed those back in time gaps, and you can go to it directly without touching 9.1.0. Unless you have a specific reason not to, that is the version to download. If you applied async patches to vCenter or ESX on top of the 5.2 BoM, look at the Interoperability Matrix before you pull anything. Broadcom’s VCF Upgrade Planner is also worth a few minutes.

Before You Start

Aria Operations has to be on 8.18. VCF Operations is mandatory in 9.x, so if you never deployed Aria Operations you will be deploying VCF Operations as part of this. The instance that hosts VCF Operations also needs a cloud proxy.

vLCM baselines are gone in 9.x, so every cluster has to be on vLCM images. That is why the ESX download above is not optional.

Moving vCenter from 5.2 to 9.1 means a Reduced Downtime Upgrade, so line up a temporary IP for each vCenter.

VCF management services needs its own IP block and DNS records. Plan for at least 12 addresses as a /28, though Broadcom recommends a /27. On top of that you need FQDNs for the services runtime, the fleet component, the instance component, identity broker and the license server. Keep the names lowercase and stay away from .local because it gets rejected. The services runtime also uses 198.18.0.0/15 internally. If that range already exists on your network, 9.1.1 lets you pick 240.0.0.0/15 or 250.0.0.0/15 instead.

The usual housekeeping still applies. Take a fresh SDDC Manager backup to SFTP and snapshot the SDDC Manager VM. Back up everything it manages. Check that no certificates or passwords are about to expire, update the vSAN HCL database, and get a clean precheck.

If you run Supervisor or VKS, read Broadcom’s critical advisory from October 9, 2026 about verification steps before upgrading vCenter to 9.1.0 or 9.1.1.

What Happens to Your Aria Products

VCF 5.2 component	In 9.1
Aria Operations 8.18	Upgraded in place to VCF Operations 9.1 with the PAK file. This is the very first step.
Aria Suite Lifecycle 8.x	Not upgraded. The new fleet lifecycle and SDDC lifecycle services take over its job. Keep it around because it still manages VMware Identity Manager.
VMware Identity Manager 3.3.x	No upgrade path. Identity broker 9.1 gets deployed with management services. Leave vIDM alone while VCF Automation still authenticates against it.
Aria Automation 8.x	Imported into VCF Operations and upgraded to VCF Automation 9.1. I would treat this as its own project.
Aria Operations for Networks	Imported and upgraded. You need 6.14.0 Patch 6, 6.14.1 or newer first.
Aria Operations for Logs	No upgrade path. You deploy the new log management component later and can move your log data over.
HCX	Upgrade it to 9.1, then upgrade every paired site. 9.x won’t pair with older versions.

What Has to Be in the Depot

This is where a dark site upgrade usually goes sideways. The upgrade reaches back into the depot at several points, and if something is missing you find out halfway through your change window. Before starting, make sure the depot has:

• The VCF Operations 9.1 upgrade PAK and the cloud proxy
• The SDDC Manager 9.1 upgrade bundle
• Install binaries for VCF management services and the license server. That covers services runtime, SDDC lifecycle, Salt master, telemetry, software depot, Salt RaaS, fleet lifecycle, identity broker and license server. Additional instances in the fleet only need the first four.
• NSX, vCenter and ESX upgrade binaries plus the ESX metadata
• Anything extra you plan to bring forward, like VCF Automation, Operations for networks, log management, HCX or Avi

Honestly, I just run all three downloads from Step 4 into the same /depot and stop worrying about it. If disk space is tight you can filter by component instead. This one grabs only the VCF Operations upgrade content:

./vcf-download-tool binaries download --sku VCF --vcf-version 9.1.1 \
  --depot-download-activation-code-file /root/activation-code.txt \
  --component VROPS --type UPGRADE --depot-store /depot

Run binaries list first to confirm the component names for your target version. Broadcom’s download tool reference also has the full filter list.

Point SDDC Manager 5.2.x at the Depot

SDDC Manager won’t connect until it trusts the depot’s certificate. SSH in as vcf, su to root, import the cert and restart LCM:

openssl s_client -connect depot.example.lab:443 < /dev/null \
  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /tmp/depot.crt

keytool -import -trustcacerts -file /tmp/depot.crt \
  -keystore /etc/alternatives/jre/lib/security/cacerts \
  -alias offline-depot -storepass changeit -noprompt

systemctl restart lcm

Then go to Administration > Depot Settings in the SDDC Manager UI. Add the offline depot with its URL and your basic auth user. Check the management domain’s Updates tab and you should see the 9.1 bundles listed.

Upgrade Order

Stick to this order. If you jump ahead, say by trying NSX right after SDDC Manager, you get an error claiming the NSX bundle is missing even though it is sitting right there in your depot. That one is covered in KB 447995. Start with the management domain of the instance that hosts VCF Operations.

1. Aria Operations and the cloud proxy to VCF Operations 9.1 with the PAK file
2. vSphere Replication, Live Site Recovery, vSAN Data Protection and Avi, if you have them
3. SDDC Manager to 9.1. Open the management domain, go to Updates, click Plan Upgrade, choose the 9.1 target, then Update Now or Schedule Update
4. VCF management services and the license server, from Build > Lifecycle in VCF Operations. Use the SDDC Manager API instead if you want a custom VLAN network or a scattered list of IPs
5. The fleet level software depot (covered next), then register VCF Operations and the license server in the VCF Business Services console
6. Aria Automation, Orchestrator, Operations for Networks, log management and HCX. These can wait until the core stack is done
7. NSX Global Managers if you use Federation, then NSX Manager
8. vCenter with a Reduced Downtime Upgrade
9. VKS and Supervisor, if you run them
10. vSAN witness hosts, then ESX using vLCM images
11. NSX Edge clusters, then finalize NSX
12. Distributed switch version, VMware Tools, VM compatibility, vSAN disk format and vSAN File Service

Workload domains are not part of the required upgrade, so you can do them whenever it suits you once the management domain is finished. Also get comfortable working in VCF Operations, because the SDDC Manager UI is deprecated after this.

Reconnect the Depot After SDDC Manager Hits 9.1

This one caught me out. The depot settings you set in SDDC Manager 5.2 do not carry over to the new software depot service. Only fresh 9.1 builds inherit them from VCF Installer. Until you set it up, NSX, vCenter and ESX can’t see a single binary.

If your depot is HTTPS, check that the certificate you imported earlier is still trusted on SDDC Manager. If you have to import it again, restart lcm afterwards. Then log into VCF Operations as an admin and go to Build > Software Depot. Click Edit and choose Offline Depot, then enter the URL. Turn on Authentication with your depot user if you kept basic auth, and click Finish. Your binaries should appear under Build > Lifecycle, in your instance’s Binary Management tab.

Keep in mind that in this mode the software depot does not store anything locally. It forwards requests from VCF components to your web server, so the depot VM has to stay up for every lifecycle job from here on.

No web server at all? Use Disconnected mode. You download on a machine with internet access and push the content straight into the software depot with depot binaries upload, depot esx upload and depot artifacts upload. You can also export to tar files first with binaries export and esx export. Broadcom’s disconnected mode page has the full syntax.

---

VCF Depot Structure

This tree is from my original 9.0.0 depot. A 9.1 depot keeps the same PROD/COMP, PROD/metadata and PROD/vsan/hcl layout. It just adds folders for the management services components and newer builds inside each folder.

/depot
  PROD
    COMP
      ESX_HOST
      HCX
      NSX_T_MANAGER
      SDDC_MANAGER_VCF
        Compatibility
          VmwareCompatibilityData.json
      VCENTER
      VCFDT
      VCF_OPS_CLOUD_PROXY
      VIDB
      VMTOOLS
      VRA
      VRLI
      VRNI
      VRO
      VROPS
      VRSLCM
      VSAN_FILE_SERVICES
    metadata
      manifest
        v1
          vcfManifest.json
      productVersionCatalog
        v1
          productVersionCatalog.json
          productVersionCatalog.sig
    vsan
      hcl
        all.json
        lastupdatedtime.json
  umds

The download tool keeps track of what it already has and resumes where it left off if a download dies. Running it again verifies every existing file by checksum, which takes a while on a full depot, and then grabs anything new.

VCF 9.0 Commands From the Original Post

I left these in for anyone still running an older download tool against a 9.0 depot with a download token. On Download Tool 9.1 or newer, use the activation code commands above.

# Install binaries
./vcf-download-tool binaries download --vcf-version 9.0.0 --automated-install \
  -d /var/www/offline-bundles --depot-download-token-file /root/token.txt --type=install

# Upgrade binaries
./vcf-download-tool binaries download --vcf-version 9.0.0 --automated-install \
  -d /var/www/offline-bundles --depot-download-token-file /root/token.txt --type=upgrade

# Full depot
./vcf-download-tool binaries download --vcf-version 9.0.0 --depot-store /depot \
  --depot-download-token-file /root/token.txt

Older VCF Versions

The download tool still handles 5.x, which helps if you need to patch a 5.2 environment forward before the jump to 9.1. William Lam’s 9.1 cheatsheet still uses the token file for 5.2.0 downloads, so that is what I show here.

# Install binaries for VCF 5.2
./vcf-download-tool binaries download --vcf-version 5.2.0 \
  --depot-download-token-file /root/token.txt --depot-store /depot --type INSTALL

# Upgrade binaries for VCF 5.2
./vcf-download-tool binaries download --vcf-version 5.2.0 \
  --depot-download-token-file /root/token.txt --depot-store /depot --type UPGRADE

References

• Upgrading to VMware Cloud Foundation 9.1.x
• Set Up an Offline Depot
• Download Binaries to an Offline Depot by Using the VCF Download Tool
• Configure a Software Depot Connection Mode
• Upgrade to SDDC Manager 9.1
• Deploy VCF Management Services and License Server as Part of VCF Upgrade to 9.1
• How to Upgrade to VMware Cloud Foundation 9.1
• KB 447995
• William Lam’s VCF 9.1 Download Tool Cheatsheet