hashicorp/terraform-provider-google: a generated GA-only provider where pull requests belong somewhere else
Terraform Provider for Google Cloud Platform
At a glance
- What is it?
- terraform-provider-google is the plugin that lets Terraform manage Google Cloud resources. It is generated from magic-modules, covers generally available features only, and does not upgrade itself.
- Who is it for?
- Use it when Terraform is your tool and the resources you need are generally available on Google Cloud; use google-beta alongside it for anything in a beta launch stage. Do not use this repository as a place to fix the provider, because it is generated and edits made here can be overwritten.
- Can I use it commercially?
- Yes, with conditions. MPL-2.0 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on November 13, 2026, and from our analysis. They are not legal advice.
Star history
- hashicorp/terraform-provider-google2,676 ★ · +22
| Repository | 2026-10-04 | 2026-11-13 |
|---|---|---|
| hashicorp/terraform-provider-google | 2.7k | 2.7k |
22 Stars in the last 40 days, measured from the daily GitHub snapshot. Compare with other projects
Editorial analysis
The repository is generated, so a fix made here can disappear
This repository is generated by magic-modules, a separate project under GoogleCloudPlatform. The contributing instructions are blunt: if you want to work on the provider, make your changes in magic-modules, because changes made directly to this repository can be overwritten.
That has a direct consequence for anyone who finds a bug in a resource and wants to patch it. A pull request against this repo does not hold, since the next generation run replaces the file. The place to contribute is magic-modules, following its contribution process, and questions that the contribution documentation does not cover go to an issue on this repository.
It also explains why the tree looks the way it does: a google/ directory for the generated provider code, main.go, a version/ directory, a website/ directory for documentation, and a .changelog/ directory feeding the CHANGELOG files.
Only generally available features live in this provider
The README says this is the google provider, containing generally available features. Preview features, and anything at a beta launch stage, belong to the separate google-beta provider, which has its own repository at hashicorp/terraform-provider-google-beta.
If a Google Cloud feature you want is still in a beta launch stage, you cannot reach it through this provider. You have to add google-beta to your configuration as well, and the README sends you to the provider versions guide in the Terraform Registry for how to do that.
The practical effect is that a configuration mixing GA and beta resources carries two providers, each with its own version constraint, credentials block and upgrade cycle. A resource moving from beta to GA also means moving it from one provider to the other.
The provider never upgrades itself
Once you have started using the provider, it does not upgrade automatically. After a new release you choose to upgrade by running:
terraform init -upgradeThat moves you to the latest stable version of the Google provider. The README points to the Terraform website for how to set version constraints on a provider.
Without a constraint, running that command can cross a major version, and this provider has had several: the repository keeps CHANGELOG_v0.md through CHANGELOG_v7.md next to the current CHANGELOG.md. Major releases are where behaviour changes, so an unconstrained upgrade in a shared pipeline is a risk to plan for. Pin the range you have tested, then widen it on purpose.
Two major lines are being released at the same time
The recent releases show an 8.x line and a 7.x line moving together. v8.9.0 was published on 2026-10-27. On 2026-10-23, v8.8.1 and v7.46.2 were published within the same hour or so, 20:29 and 19:48 UTC.
The pairing suggests that fixes are being applied to both the newest major and the previous one. That helps anyone who has not yet moved to 8.x, since a patch release for their line exists. It also means a version constraint such as one that stays within 7 will keep receiving updates for now, while the changelog for 8 is where the newer behaviour is described.
The repository was pushed to on 2026-11-02, so the code is being touched very recently. How long the 7.x line will be patched is not something the repository states, so do not assume it stays supported.
Two plugin frameworks sit in go.mod at once
The go.mod declares Go 1.26.0 and lists both github.com/hashicorp/terraform-plugin-sdk/v2 v2.40.1 and github.com/hashicorp/terraform-plugin-framework v1.19.0, along with terraform-plugin-mux v0.23.1, terraform-plugin-go v0.31.0 and terraform-plugin-testing v1.16.0. It also depends on google.golang.org/api v0.310.0, cloud.google.com/go/bigquery v1.85.0 and cloud.google.com/go/bigtable v1.58.0, and carries go-vcr v1.2.0.
What you can read from the dependency list is that the build is not tied to one provider SDK: both the older SDK v2 and the newer framework are required, with the mux package present. The list alone does not say which resources use which.
For anyone building the provider from source, the Go 1.26.0 floor matters, and .go-version pins the toolchain used by the repository.
Examples cover networking and load balancing, not every service
The examples/ directory has eight sample configurations: cloud-armor, content-based-load-balancing, endpoints-on-compute-engine, example-versioned-module, internal-load-balancing, shared-vpc, two-tier and vpn.
That is a narrow slice of what the provider manages. The samples lean toward network layout and load balancing, with one on Cloud Endpoints and one on versioned modules. If your target is, for example, a data warehouse, there is no sample here to copy, and you would work from the Registry documentation instead.
The README itself is mostly links: tutorials on learn.hashicorp.com, a forum at discuss.hashicorp.com, a Google Groups mailing list, Gitter, and a getting started guide and provider reference in the Terraform Registry. The configuration of credentials is documented in that provider reference, not in this repository.
Two companies maintain it, and contributor data is covered by an IBM privacy notice
The provider is maintained by the Terraform team at Google and the Terraform team at HashiCorp. It uses the MPL-2.0 license and the repository is not archived.
The README ends with a privacy notice. Individuals who take part in the repository, including external contributors, may have personal information tied to their GitHub profiles, contributions and activity processed for security, compliance, audit, vulnerability management and related governance purposes. It points to the IBM Privacy Statement for details.
The repository also holds release machinery visible at the top level: .goreleaser.yml, a .release/ directory, a .teamcity/ directory and terraform-registry-manifest.json. Those files describe how the provider is packaged for the Registry, but there is nothing in them for a user to configure.
Editorial conclusion
Use it when Terraform is your tool and the resources you need are generally available on Google Cloud; use google-beta alongside it for anything in a beta launch stage. Do not use this repository as a place to fix the provider, because it is generated and edits made here can be overwritten. Before you upgrade, set a version constraint and read the changelog for your major version, since 7.x and 8.x lines are both receiving releases.
Frequently asked questions
What is the Google Cloud Terraform provider?
It is a plugin that allows Terraform to manage resources on Google Cloud Platform. The google provider contains generally available features, and beta features come from google-beta.
Does GCP support Terraform through terraform-provider-google?
Yes. The provider is maintained by the Terraform team at Google and the Terraform team at HashiCorp, and its documentation is published in the Terraform Registry.
What is Terraform for Google Cloud, and how do I upgrade the provider?
It is the google provider plugin, and it does not upgrade automatically. Run terraform init -upgrade to move to the latest stable version, and set version constraints first.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/hashicorp-terraform-provider-google)Star history chart for your README
[](https://hysenlabs.com/projects/hashicorp-terraform-provider-google)Was this useful?