terraform-provider-vsphere is the Broadcom-maintained path to managing vSphere in code

A Terraform plugin for vSphere, published by Broadcom

The Terraform Provider for VMware vSphere is a plugin for Terraform that allows you to interact with VMware vSphere. It is written in Go, its module path is github.com/vmware/terraform-provider-vsphere, and the copyright and licence notices are held by Broadcom.

The audience is platform and infrastructure engineers who want vSphere infrastructure described in Terraform configuration rather than clicked together in a console. The value proposition is the ordinary one for a provider: resources, data sources and provider configuration are declared in HCL, and Terraform handles the plan and apply cycle against a real vSphere estate.

Where it sits in the wider ecosystem matters too. This is a Partner tier provider, which the documentation explains means it is owned and maintained by a partner in the HashiCorp Technology Partner Program, that HashiCorp verifies the authenticity of the publisher, and that the provider is listed on the Terraform Registry with a Partner tier label.

That arrangement has a practical consequence for how the provider evolves. The code lives in a VMware repository with Broadcom notices, the vSphere API client is the open source govmomi library, and the plumbing to Terraform is the HashiCorp plugin SDK, so the provider is a thin, well-defined layer over two mature upstream projects rather than a from-scratch automation stack.

The provider never upgrades itself, so init is a deliberate act

The single most operationally important line in the project documentation is this: the provider does not upgrade automatically.

When a new provider version is published, you upgrade it yourself by running:

terraform init -upgrade

Without that flag, terraform init installs the version your configuration asks for, and with it, Terraform fetches the newest matching release from the registry. The distinction matters in a team where several people run apply against the same state, because a provider that moves under your feet produces plans that differ depending on who last initialised their working directory.

The documentation also draws a line between two kinds of user. Unless you are contributing to the provider or you need a pre-release bugfix or a pre-release feature, you should use a released version. That rules out casually pointing your configuration at a nightly or preview build, which is the sort of thing that works for one person on a branch and then surprises everyone else.

Installation itself is not a manual step in the normal case. Running terraform init is enough, because Terraform pulls the provider from the Terraform Registry automatically. The repository also documents automated and manual installation methods and how to control the provider version, in a separate install document, for the cases where the registry path does not fit, such as an air-gapped environment.

Terraform 0.13, a Go toolchain for contributors, and a lifecycle policy

Three requirements are stated, and they apply to different people.

The first is Terraform 0.13 or newer, which is what you need to run the provider as a consumer. The second is Go 1.26.7, and it is only required if you are building the provider from source, which means it is a contributor requirement rather than an end user one. The module file goes slightly further and declares go 1.26.8 in its go directive, so the toolchain that actually compiles the tree is one patch level ahead of the version the documentation names.

The third requirement is the one with the most room for interpretation, which is VMware vSphere itself. The provider supports versions in accordance with the Broadcom Product Lifecycle, which is a link to a product lifecycle page rather than a matrix of supported releases. In practice this means your usable vSphere versions are bounded by the vendor's own support window, not by a list the provider publishes.

That is a reasonable design for a provider whose client library talks to a platform with a support lifecycle of its own, but it does mean you cannot assume a new vSphere release works with the current provider version. Checking the provider release notes against the vSphere version you intend to run is a step the documentation does not automate for you.

govmomi and the plugin SDK form the whole stack

The dependency list in the module file is short enough to be informative.

The vSphere client is github.com/vmware/govmomi at version 0.56.0. That library is what actually speaks to the vCenter and ESXi APIs, and it is where the bulk of the real protocol work lives, which is why the provider can stay relatively small. The Terraform side uses github.com/hashicorp/terraform-plugin-sdk/v2 at version 2.40.1, which is the standard SDK for a provider built on the older plugin protocol, plus terraform-plugin-log for structured logging and terraform-plugin-testing for the acceptance test harness.

The repository layout matches that division. main.go is the entry point, the vsphere/ directory holds the provider code, tests/ holds the test suite, and docs/ holds the provider documentation, which is also where the registry documentation is sourced from. The terraform-registry-manifest.json file at the root is the file the Terraform Registry reads to publish a build, and .goreleaser.yml with its template handles cross-platform binary packaging and release artifacts.

There are also the files you would expect from a corporate open source project: CODEOWNERS, a NOTICE file, a CODE_OF_CONDUCT.md, a CHANGELOG.md and a .golangci.yml for linting, with a Makefile for the tasks in between.

The Makefile separates unit runs from six hour acceptance tests

The build file shows how the project separates a fast feedback loop from the slow one.

Every target depends on a formatting check, so a build cannot proceed on unformatted code:

build: fmtcheck
	go install

The acceptance tests are the target that matters for anyone working against a real environment. They are gated behind an environment variable and given a long timeout:

testacc: fmtcheck
	TF_ACC=1 go test $(TEST) -v $(TESTARGS) -timeout 360m

A six hour timeout tells you these tests talk to a live vSphere and can wait on long operations, and the TF_ACC=1 switch is the conventional Terraform SDK gate that means the acceptance tests actually run rather than skip.

Documentation is checked with the same rigour. A docs-check target runs a script under scripts/ that verifies the structure of the documentation, and a separate pair of targets checks and fixes the HCL formatting inside the markdown with terrafmt, which is installed on demand by the tools target. A diff against the checked-in formatting fails the build rather than warning, which is what keeps the examples in the documentation honest.

The formatting check itself is a shell script, gofmtcheck.sh, invoked with the repository's own scripts/ directory, and a fmt target applies gofmt to the Go files. The test target also runs the package list through xargs in batches of four with a 30 second per package timeout, so a hang in one package does not stall the rest.

Two support paths, and an issue before a pull request

The support section describes a two-track arrangement that is worth reading before an outage.

Because the provider is developed as an open source project following standard GitHub community practices, the documentation encourages bug reports and enhancement requests to be submitted directly in the project repository. Some situations, however, may require formal technical support through the Global Support Services process. For those, you open a case through the Broadcom support portal and reference the provider, the provider version and any related GitHub issues. The instructions are specific about the case metadata: select VMware ESXi as the product and choose VCF Terraform from the components drop-down.

That split is a practical one. An ordinary bug belongs in the repository where other users can see the fix. A production outage with a commercial support agreement behind it belongs in the support portal, and the instruction to reference the GitHub issue connects the two.

The contribution path has a similar shape. The documentation asks that you read the contribution guidelines before submitting a pull request, and it asks specifically that you open an issue to discuss an enhancement or feature beforehand. For a provider whose resource and data source surface is a large public API, that request is sensible: it is far cheaper to agree on a resource design before the code exists than to review a pull request for an API shape nobody has looked at yet.

MPL-2.0 keeps the licence at file level

The provider is available under the Mozilla Public License, version 2.0, and the copyright is held by Broadcom, with a note that the term Broadcom refers to Broadcom Inc. and its subsidiaries. The licence file is at the root of the repository, and the licence identifier is also carried as an SPDX header in the source.

MPL-2.0 is a file level copyleft licence, which is the key practical point. Modified files that you distribute must stay under the same licence, while files you merely link against do not have to. For a provider that most people consume as a binary through the Terraform Registry, this rarely comes up. It matters if you fork the provider, patch it internally, or ship a modified build to your own users, and it is worth knowing the boundary before you start rather than after a legal review.

The maintenance picture is straightforward. The repository is not archived, the last push was on 2026-10-20, and the release history is regular: v2.17.1 on 2026-09-14, v2.17.0 on 2026-09-01 and v2.16.1 on 2026-06-10. The v2.17 line sits at a patch release within weeks of the minor, which is the shape you would expect from a provider with an active bug flow.

The one caveat worth repeating is the one from the requirements section. Support for vSphere versions follows the Broadcom Product Lifecycle, so the ceiling on what you can run is set by vendor support windows rather than by the provider.

Editorial conclusion

terraform-provider-vsphere is the right choice for a platform team that already runs Terraform and wants vSphere estates managed as code with the govmomi client library and the Terraform Plugin SDK, and the wrong choice for a team hoping the provider will follow vSphere upgrades on its own, because the documentation says it does not upgrade automatically and version selection is manual. Before adopting it, pin the provider version in your configuration, run terraform init -upgrade deliberately when you intend to move, and check your vSphere release against the Broadcom Product Lifecycle the provider follows.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. Project website
3. README
4. Releases
5. vmware/terraform-provider-vsphere on GitHub