Architecting the Foundation

VMware Cloud Foundation architecture, operations, and field notes from a working lab.

Automation · May 14, 2026 · 4 min read

Deploying a VMware Cloud Foundation Automation Tenant with Terraform

In the previous post I published the VMware Cloud Director version of my Terraform tenant demo. The next thing I wanted to look at was the same idea in VMware Cloud Foundation Automation.

The example code is here:

GitHub: wynner/scripts/vcfa/terraform/tenant-demo

Safety Warning

Use these Terraform files with care. They create, change, and destroy infrastructure objects. Treat them as example code and test them only in non-production environments unless you have reviewed and adapted the configuration for your own VMware Cloud Foundation Automation platform.

What This Demo Builds

This is not a one-for-one replacement for the VCD example. The current VCFA Terraform provider can create the tenant Organization, but it does not yet expose every object at the tenant level I used in the VCD version. So this demo focuses on the VCFA-native pieces that map well today.

  • a VCFA tenant organization
  • a region quota against an existing region and region zone
  • a VM class allow-list
  • storage policy quota for the tenant
  • organization networking settings
  • regional networking through a named provider gateway and edge cluster
  • a local tenant administrator
  • a tenant content library

That gives me the core parts of a tenant setup from code. It is the foundation I would want before moving on to workload placement or blueprint creation.

What Is Different From The VCD Version

The VCD demo builds quite a lot: an Org VDC, an edge gateway, a routed network, a shared Named Disk, two dummy VMs, DNAT, SNAT, IP sets, security grouping, and firewall policy. The VCFA provider is not at that same object coverage point yet. It’s still version 1.0 afterall.

At the time I tested this, the VCFA Terraform provider did not expose first-class equivalents for the standalone VMs, independent disks, internal VM disks, routed Org VDC networks, edge NAT rules, edge firewall policies, tenant NSX-T IP sets, tenant security groups, application port profiles, or security tags used by the VCD demo.

That does not make the VCFA example less useful. It just makes it a different type of demo. This is about standing up the tenant foundation, quota, networking attachment, administrator, and content library using Terraform. A fuller application build would need additional provider support or a separate design using other automation layers.

No Hard-Coded Environment IDs

As with the VCD version, I wanted the code to be usable by others outside of my lab environment. This example code asks for names such as the region, region zone, vCenter, Supervisor, provider gateway, edge cluster, storage policies, and VM classes. Those values live in terraform.tfvars, with placeholders in terraform.tfvars.example.

The provider-side objects are looked up from those names using Terraform data sources. The user edits a variables file with the names from their environment rather than pasting internal IDs into the resource code.

Files In The Example

  • main.tf configures the VCFA provider
  • variables.tf keeps endpoint, tenant, region, quota, and application-facing values out of the resource code
  • data.tf looks up existing VCFA provider-side objects
  • tenant.tf builds the tenant organization, region quota, networking, and local administrator
  • application.tf creates the tenant content library
  • terraform.tfvars.example shows the values to supply without including secrets

Apply Notes

The workflow is intentionally simple:

cp terraform.tfvars.example terraform.tfvars
Edit the terraform.tfvars with your VCFA specific endpoint details
terraform init
terraform fmt
terraform validate
terraform plan -out tfplan
terraform apply tfplan

Why This Is Useful

The useful part here is not that the example creates a content library. It is that the provider-side tenant shape can be described as code: the organization, regional quota, storage policy exposure, VM class exposure, networking settings, regional networking, and the first administrator.

That is a good starting point for repeatable tenant onboarding in VCFA. It is also a useful comparison with the VCD example because it shows both the promise and the current boundaries of the Terraform provider. VCD can express more of the tenant application topology today; VCFA can express the tenant foundation cleanly, and I expect that surface area to grow.

The good news is that the VCFA 9.0 API is centered on the VCD API but changed for the concept of regions and namespaces etc. I’m hoping in future releases the API for the tenant from the VCD side will be exposed too.