// Guide · VCF 9 · Dark-site deployments

VCF Offline Depot Generator

A live-preview generator that turns a few configuration choices into a production-ready software depot for VMware Cloud Foundation 9.x — one-shot installer, web server config, directory tree, verification script, landing page, and an air-gap two-script workflow. Aligned with Broadcom KB 312168 and the observed VCF 9.1 BOM.

Apache · nginxUbuntu · RHEL · PhotonLet's EncryptSelf-Signed · BYOVCF 9.0 / 9.1VCFDT ReadyAir-Gap ModeKB 312168

Open the tool Jump to walkthrough

Quick start

Configure — pick web server (Apache or nginx), target OS, depot FQDN, and target VCF version. The output panel updates live as you type.
Choose your cert strategy — Let's Encrypt (HTTP-01 or DNS-01 with embedded Cloudflare/Route53 creds), self-signed, or BYO cert.
Pick deploy mode — Online if the depot host has internet, Offline for a two-script workflow (run prep.sh on a connected host, transfer to dark site, run install.sh --offline).
Download and run — click the primary button, transfer to the depot host, run as root. Idempotent and re-runnable.
Populate with VCFDT — download VCF binaries with the VCF Download Tool, then run verify.sh before pointing SDDC Manager at the URL.

On this page

When to use this tool
How it works
Step-by-step walkthrough
Offline (air-gap) workflow
Certificate strategies
Examples
Common mistakes
Related tools
FAQ

When to use this tool

Use this tool whenever you need to:

Stand up an offline depot for VCF 9.x in environments where SDDC Manager cannot reach depot.broadcom.com directly (dark sites, air-gapped networks, restricted egress).
Get a deploy-ready installer instead of hand-rolling vhost configs, certbot invocations, htpasswd commands, systemd hardening, and directory trees.
Avoid SDDC Manager "Path not found" errors caused by depots that aren't laid out per Broadcom KB 312168 — the generator scaffolds the exact tree SDDC Manager probes.
Deploy to a dark site using the two-script workflow: bundle dependencies on a connected jumphost, transfer to the air-gapped depot, install offline.
Document the depot build with a generated README, verification script, and landing page for handoff to ops teams.

💡

Already running a depot? The verification script alone is useful as a standalone health check — generate it with your existing config and run it against your live depot to confirm SDDC Manager will accept it before pointing the UI at it.

How it works

SDDC Manager's offline depot feature expects a web server serving a specific directory tree at a specific URL pattern. The directory layout, basic-auth requirement, and metadata files come from Broadcom KB 312168. The generator produces every piece of that puzzle from a small set of inputs:

Web server config — vhost for Apache 2.4 or nginx, with TLS, basic auth, large-file delivery tuning, and security headers
Directory tree — the full PROD/COMP/, PROD/metadata/, vsan/hcl/, umds-patch-store/, and Photon TDNF mirror skeleton
One-shot installer — colored bash script that handles every step from preflight to smoke test
Cert handling — three strategies, plus optional embedded API credentials for DNS-01 challenges
Offline mode — a paired prep.sh that packages all OS dependencies into a tarball for transfer to dark-site hosts

All generation happens client-side. No FQDNs, passwords, or API tokens leave your browser.

Step-by-step walkthrough

1. Web server and OS

Pick Apache 2.4 or nginx and your target OS:

Ubuntu 24.04 / 22.04 LTS — most common for greenfield depots, uses www-data as web user
RHEL / Rocky 9 — enterprise standard, uses apache or nginx as web user, requires restorecon for SELinux
Photon OS 5 — VMware's own distro, useful if you're standardizing on the same OS as VCF appliances

The generator adjusts vhost paths, package names, package manager (apt / dnf / tdnf), and firewall tool (ufw / firewalld) per OS.

2. Endpoint configuration

Set the depot endpoint:

Depot FQDN — used as the TLS cert SAN, vhost name, and depot URL. Must resolve from SDDC Manager.
HTTPS port — defaults to 443. Change only if 443 is in use.
VCF version — picks the target BOM. 9.1.0 has 23 components including new ones like VCF_OBSERVABILITY_DATA_PLATFORM, VCF_SALT, VIDB.
Document root — must have PROD/ as an immediate child or the VCF Installer returns "Path not found" (Broadcom KB 413848).

3. Authentication

Basic auth is required by SDDC Manager — anonymous depots are rejected. Pick a username (default vcfdepot). The installer prompts for the password at runtime, or you can pass it via the DEPOT_PASS environment variable for non-interactive deployments.

4. TLS certificate

Three strategies:

Let's Encrypt — automated free cert from a public CA. Requires the depot FQDN to be publicly resolvable (HTTP-01) or that you control DNS for the zone (DNS-01).
Self-signed — generated locally by the installer. SDDC Manager will require importing this cert as trusted before connecting.
BYO cert — admin places the cert and key at the OS-specific paths before running the installer. Best for environments with an internal CA.

See the Certificate strategies section below for picking between them.

5. Depot content

Four toggleable content groups:

VCF Lifecycle Bundles — the core PROD/COMP/ tree
ESXi / vLCM Image Depot — vendor addons (DEL/HPE/LNV), custom components, base images
VCF Ops & Automation — legacy PRODUCTS/ tree (deprecated in 9.1 but kept for back-compat)
Photon TDNF Repo — appliance patch mirror for vCenter, NSX Manager, SDDC Manager, VCF Ops

The Photon repo is what the VCF appliances pull OS patches from. It's independent of your depot host OS — you can serve a Photon repo from an Ubuntu host.

6. Installer options

Toggles for installer behavior:

Configure firewall — auto-opens 80/tcp and your HTTPS port via ufw or firewalld
Auto-generate htpasswd — creates the basic-auth file at install time
Schedule cert renewal — systemd timer that runs certbot renew twice daily (Let's Encrypt only)
Include VCFDT setup — adds VCF Download Tool bootstrap notes to the installer output

7. Deploy mode

The most important toggle. Online vs Offline determines the entire deployment workflow. See Offline (air-gap) workflow below.

Offline (air-gap) workflow

When the depot host has no internet — common in regulated, government, or fully air-gapped environments — switch to Offline deploy mode. The generator produces two scripts instead of one:

prep.sh — runs on an internet-connected workstation matching the depot's OS. Downloads all OS packages, certbot, and plugins into deps.tar.gz.
install.sh --offline /path/to/deps.tar.gz — runs on the air-gapped depot host. Extracts the bundle and installs everything from local files instead of distro repos.

⚠

OS version must match exactly prep.sh enforces this with a hard check. You cannot prep on Ubuntu 22.04 for an Ubuntu 24.04 depot — package versions across releases are incompatible and dpkg will reject the bundle.

Offline mode auto-forces BYO cert — Let's Encrypt cannot work from an air-gapped host because certbot can't reach the ACME server. Stage your cert in the prep host's working directory before running prep.sh and it'll be bundled, or place it on the depot host before running the installer.

Typical bundle size: 15–40 MB depending on certbot plugins. VCF binaries themselves (80–100 GB) are not bundled — VCFDT runs separately on an internet-connected host with your Broadcom token.

Certificate strategies

The right cert strategy depends on whether your depot FQDN is publicly resolvable and what your CA story looks like.

Let's Encrypt with HTTP-01

Use when the depot FQDN resolves on the public internet and port 80 is reachable from Let's Encrypt's servers. Simplest path — certbot handles everything inline with the Apache/nginx plugin.

Let's Encrypt with DNS-01 (Cloudflare or Route53)

Use when the depot is on an internal-only FQDN that doesn't resolve publicly. Requires DNS API credentials for your zone. The generator has two paths:

Embed credentials in install.sh — paste your Cloudflare token or AWS access key + secret into the generator. The installer auto-stages them to /root/.secrets/cloudflare.ini or /root/.aws/credentials (mode 0600).
Pre-stage manually — leave the fields blank. Place credentials on the depot host yourself before running the installer. The installer detects and uses them.

🚨

Embedded credentials are in the script An install.sh with embedded Cloudflare or AWS credentials is a secret artifact. Don't commit it to git, don't paste it in chat, transfer only over secure channels, and delete or rotate after deploy. The generator shows an amber warning the moment you fill in a credential.

Self-signed

Use for lab, dev, or POC depots where you don't want to manage a public DNS record. The installer generates a 4096-bit RSA cert valid for 825 days with the depot FQDN as SAN. SDDC Manager will reject this unless you import the cert as trusted on the SDDC Manager appliance first.

BYO (Bring Your Own) cert

Use when you have an internal CA or commercial cert. Place the cert at /etc/ssl/certs/<fqdn>.crt (or /etc/pki/tls/certs/ on RHEL) and the key at the matching /etc/ssl/private/<fqdn>.key path before running the installer. The installer verifies they exist and sets correct permissions.

Examples

Example · Internet-connected Ubuntu depot with Let's Encrypt

Public FQDN depot.example.com on Ubuntu 24.04 with HTTP-01:

Web Server:     nginx
Target OS:      Ubuntu 24.04 LTS
Depot FQDN:     depot.example.com
HTTPS Port:     443
VCF Version:    9.1.0.0
Cert:           Let's Encrypt (HTTP-01, production)
Deploy Mode:    Online

→ Download install.sh
→ scp install.sh root@depot:/root/
→ sudo ./install.sh

Single command, 3-minute install. certbot gets a real cert, depot is live at https://depot.example.com/.

Example · Internal-only depot with Cloudflare DNS-01

Internal FQDN depot.corp.internal on RHEL 9, zone managed in Cloudflare:

Web Server:     apache
Target OS:      RHEL / Rocky 9
Depot FQDN:     depot.corp.internal
Cert:           Let's Encrypt (DNS-01 Cloudflare)
CF Token:       cf-token-xxxxx  (Zone:DNS:Edit scoped)
Deploy Mode:    Online

→ Download install.sh  (now contains embedded token)
→ Transfer over secure channel
→ sudo ./install.sh
→ Rotate the Cloudflare token after deploy

certbot uses the embedded token to add a TXT record, get the cert, then clean up. No public DNS or open port 80 needed.

Example · Air-gapped depot with internal CA cert

Fully isolated depot on Ubuntu 24.04, cert from internal PKI:

Web Server:     nginx
Target OS:      Ubuntu 24.04 LTS
Cert:           BYO Cert
Deploy Mode:    Offline

# On internet-connected jumphost (Ubuntu 24.04):
sudo ./prep.sh
# Produces ./deps.tar.gz (~25 MB)

# Transfer cert + key + bundle + installer
scp deps.tar.gz install.sh depot.crt depot.key dark:/root/

# On dark-site depot host:
mv depot.crt /etc/ssl/certs/depot.corp.internal.crt
mv depot.key /etc/ssl/private/depot.corp.internal.key
sudo ./install.sh --offline /root/deps.tar.gz

No internet at any point on the depot host. Cert from your internal CA. VCFDT runs separately on the jumphost to fetch VCF binaries, then those get rsynced to the depot.

Common mistakes

🚨

Wrong document root layout The VCF Installer expects <docroot>/PROD/ as an immediate child. If you nest the depot deeper (/var/www/depot/vcf/PROD/), SDDC Manager returns "Path not found - /metadata/productVersionCatalog/v1/productVersionCatalog.json" (Broadcom KB 413848). The generator's directory tree always uses the right structure.

⚠

Forgetting to fix ownership after VCFDT VCFDT writes files as root. The web server runs as www-data (Ubuntu), apache (RHEL/Photon), or nginx (RHEL). After VCFDT finishes, run chown -R <web-user>:<web-group> /var/www/depot or you'll get 403s on every binary.

⚠

Using http2 on; on nginx < 1.25.1 The standalone http2 on; directive only exists in nginx 1.25.1+. Ubuntu 22.04 ships nginx 1.18, 24.04 ships 1.24 — both reject it with "unknown directive http2". The generator uses the universal listen 443 ssl http2; syntax that works on all versions.

⚠

Misreading empty component directories as broken VCFDT only populates dirs your Broadcom token is entitled to download. Empty ESX_HOST/, NSX_T_MANAGER/, or VRO/ after a run is expected, not a failure. Check VCFDT logs and your token's entitlements before troubleshooting the depot itself.

🚨

Embedded credentials shared via insecure channels If you embed a Cloudflare token or AWS keys in install.sh, that file becomes a secret. Pasting it into a chat tool, committing to git, or leaving it in a shared dropbox exposes the credentials to your entire DNS zone or AWS account. Rotate immediately if exposed.

⚠

Cross-OS-version prep bundles Don't run prep.sh on Ubuntu 22.04 to deploy to an Ubuntu 24.04 depot. Package versions across distro releases are incompatible. The prep script enforces this with a strict OS version check and refuses to continue without explicit confirmation.

Tools that pair well with the Offline Depot Generator:

FAQ

Does the tool send my FQDN or credentials anywhere?

No. Everything stays in your browser. All generation runs client-side — no FQDNs, passwords, API tokens, or configs leave your device. Refresh the page and the configuration is gone (cert credentials too).

Why is basic auth required? Can I run an anonymous depot?

SDDC Manager rejects depots without basic auth — it's a Broadcom requirement, not a generator choice. The installer always sets up an htpasswd file, and the generator always emits the auth config in the vhost. If you skip auth, SDDC Manager will return a connection error when you try to register the depot.

Does the tool download VCF binaries for me?

No. The tool builds the depot infrastructure (web server, directory tree, auth, certs). VCF binaries are downloaded separately by the VCF Download Tool (VCFDT) using your Broadcom Support Portal token. VCFDT writes binaries directly into the depot structure the generator scaffolded.

Can I re-run the installer safely if something goes wrong?

Yes — the installer is idempotent. It checks for existing certs, htpasswd files, vhost configs, and systemd units before touching them. Re-run after fixing input errors and it'll only update what changed. Use ./install.sh --uninstall to remove configs while preserving depot data.

What if my depot needs to serve both VCF 9.0 and 9.1?

The generator scaffolds the union of all known 9.x components, so the same depot tree can hold both. VCFDT writes the right files for whichever version you ask for. Unused component directories on older versions are harmless empty placeholders.

Does offline mode bundle the VCF binaries too?

No. prep.sh bundles only the OS packages needed to install the web server, certbot, and tooling — typically 15–40 MB. VCF binaries (80–100 GB) are downloaded separately via VCFDT, usually on the same internet-connected jumphost, then rsynced or carried to the depot host on physical media.

Why does the verify script return 404s for some components?

VCFDT only populates dirs your Broadcom token is entitled to download. The verify script treats 404s on optional components as a yellow ○ (not entitled — fine), not a red ✗. Only paths required by SDDC Manager (PROD/, productVersionCatalog.json, vcfManifest.json, vsan/hcl/all.json) are treated as hard failures.

Can I use the depot from multiple SDDC Manager instances?

Yes. The depot is just an HTTP endpoint — any SDDC Manager that can resolve the FQDN and authenticate with the basic auth credentials can use it. Use a single shared depot for multi-site deployments, or one per site if egress to the depot would cross slow links.

What changed in VCF 9.1 vs 9.0?

9.1 introduced 16 new components in PROD/COMP/ (DEPOT_SERVICE, HCX, NSX_ALB, TELEMETRY_ACCEPTOR, VCFDT, VCF_FLEET_LCM, VCF_LICENSE_SERVER, VCFMS_METRICS_STORE, VCF_OBSERVABILITY_DATA_PLATFORM, VCF_SALT, VCF_SALT_RAAS, VCF_SDDC_LCM, VCF_SERVICE_VCD_MIGRATION_BACKEND, VIDB, VSAN_FILE_SERVICES, VSP) plus new metadata paths under PROD/metadata/ (Compatibility/v1, Compatibility/v2, vsan/hcl). vCenter delivery also changed to UUID-namespaced vmw/<uuid>/ subdirs. The generator handles all of this automatically.

Can I use this on Windows?

The generated installer is bash and targets Linux (Ubuntu, RHEL/Rocky, Photon). Windows Server is not a supported VCF depot platform per Broadcom KB 312168 — the depot must be Linux with Apache or nginx.