Short answer: Starting with VCF 9.1, an offline depot can be served over plain HTTP without authentication, in addition to HTTPS with or without basic authentication. In 9.0 the documented offline depot setup was HTTPS with basic authentication. You still populate the depot with the VCF Download Tool and publish the PROD tree from any web server. The VCF Installer UI in 9.1 only configures authenticated depots, so an unauthenticated HTTP or HTTPS depot is set through the API.
Supported offline depot protocols in VCF 9.0 vs 9.1
| Protocol | Authentication | VCF 9.0.x | VCF 9.1 | How to configure in 9.1 |
|---|---|---|---|---|
| HTTPS | Basic auth | Supported (default) | Supported | UI or API |
| HTTPS | None | No | Supported | API |
| HTTP | None | No | Supported | API |
The three 9.1 combinations come from the Broadcom doc Set Up an Offline Depot Web Server for VMware Cloud Foundation (9.1). The UI-vs-API split is from William Lam’s testing. Broadcom still recommends HTTPS, so keep plain HTTP to isolated, trusted networks such as air-gapped sites and labs.
Offline depot web server requirements
- Linux (any distribution, for example Photon OS, RHEL or Ubuntu) or Windows VM with a static IP address. DNS records are recommended but not required.
- A dedicated disk for depot content; Broadcom recommends at least 1 TB.
- A dedicated non-root user with read/write access to the depot directory.
- For HTTPS: TLS 1.2 and 1.3, and a certificate whose SAN includes both the FQDN and IP address of the depot server.
Depot directory layout
The Broadcom Apache example uses /var/www/html as the document root with this structure:
/var/www/html/PROD/COMP # product binaries
/var/www/html/PROD/metadata # depot metadata
/var/www/html/PROD/vsan/hcl # vSAN HCL data
/var/www/html/umds-patch-store # ESX component data (UMDS)
You do not build this tree by hand. The VCF Download Tool writes binaries and metadata into it when you point --depot-store at the web root. The commands for install, upgrade and ESX downloads are in my VCF 9.1 VCF Download Tool (VCFDT) cheat sheet.
Serving the depot over HTTP with Apache
For an unauthenticated HTTP depot you only need Apache listening on port 80 with read access to the tree. In Broadcom’s HTTPS example, PROD/COMP and PROD/metadata are protected with AuthType Basic, while vsan/hcl and umds-patch-store are always Require all granted. For HTTP without authentication, grant all four:
<Directory /var/www/html/PROD>
Require all granted
</Directory>
<Directory /var/www/html/umds-patch-store>
Require all granted
</Directory>
Then apply the permissions from the Broadcom procedure and restart the web server:
chown apache -R /var/www/html/
find /var/www/html -type d -exec chmod 0500 {} \;
find /var/www/html -type f -exec chmod 0400 {} \;
chmod 755 /var/www/
chmod 755 /var/www/html/
Open TCP 80 (or your chosen port) on the host firewall. Before connecting VCF, check from another machine that http://depot.example.local/PROD/metadata/ returns content.
Connecting VCF Installer to the HTTP offline depot
In the VCF Installer UI (Depot Settings and Binary Management > Offline Depot > Configure) you enter the depot URL and credentials, as described in Connect VCF Installer to Broadcom or an Offline Depot. For a depot without authentication, use the VCF Installer API instead:
- Get a token from
POST /v1/tokens. - Send
PUT /v1/system/settings/depotwith adepotConfigurationthat setsisOfflineDepotto true and uses yourhttp://depot URL, with noofflineAccount. - Check the result with
GET /v1/system/settings/depot, then sync metadata and download binaries as usual.
William Lam’s post has a working PowerShell example for both the VCF Installer and the fleet depot service (/depot-service/api/depot/v1/connectivity with depotType: OFFLINE). A fleet deployed from an installer that used an HTTP depot inherits that configuration. The API reference is on the Broadcom developer portal: Depot Settings APIs.
HTTPS depot: trusting the certificate
If you stay on HTTPS with a private CA, VCF Installer must trust the depot certificate before you configure it. The Broadcom procedure, run as root over SSH, is:
openssl s_client -connect depot_server_FQDN:443 < /dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /tmp/server.crt
keytool -import -trustcacerts -file /tmp/server.crt -keystore /etc/alternatives/jre/lib/security/cacerts -alias offline_depot_server -storepass changeit -noprompt
echo 'y' | /opt/vmware/vcf/operationsmanager/scripts/cli/sddcmanager_restart_services.sh
Skipping this step, or using a certificate without the IP address in the SAN, will break the offline depot connection. HTTP avoids certificate handling entirely, which is the main practical benefit of the 9.1 change for labs and isolated sites.