The terraform-provider-google-beta codebase is presented as a comprehensive introduction to the architecture, code generation system, and organizational structure of a provider that enables Terraform users to manage Google Cloud Platform resources using beta-level APIs. The provider runs in parallel to the GA provider terraform-provider-google and provides early access to new GCP features before they reach general availability. The beta designation means resources may have API changes, breaking changes, or deprecations as features evolve before reaching GA status. This characteristic shapes operational expectations for teams that adopt beta resources in production workflows. The provider is maintained by the Terraform team at Google and the Terraform team at HashiCorp, and it is generated by magic-modules. Any changes made directly to this repository will likely be overwritten. The repository is generated by magic-modules. If you wish to work on the provider, you'll need to make changes in magic-modules.
The Terraform Google provider beta is a plugin that allows Terraform to manage resources on Google Cloud Platform. This is the google-beta provider which contains all the features in google provider as well as the preview features and features at a beta launch stage. See Provider Versions for more details on how to use google-beta. The Google provider doesn't upgrade automatically once you've started using it. After a new release you can run
terraform init -upgrade
to upgrade to the latest stable version of the Google provider. See the Terraform website for more information on provider upgrades, and how to set version constraints on your provider.
Architecture Overview
The provider leverages Magic Modules MMv1 to automatically generate approximately 95 percent of its code from YAML resource definitions. This generation strategy creates a strong separation between source definitions and generated artifacts. Key characteristics include DO NOT EDIT to prevent manual modifications. Sources referenced for this characteristic are providermmv1resources.go1-16 cloudsecuritycompliance/resourcecloudsecuritycompliancecloudcontrol.go1-18 cloudsecuritycompliance/resourcecloudsecuritycompliancecloudcontrolgeneratedmeta.yaml1-50.
The impact of a 95 percent generated codebase is that human edits to generated files are lost on the next generation cycle. Operational teams must therefore never commit manual fixes to generated Go files. The contextual layer is that Magic Modules serve as the single source of truth, and the provider repository functions as a build artifact. This aligns with the instruction that the repository is generated by magic-modules and direct edits will be overwritten.
Resources are organized into 140+ service packages under google-beta/services. Each service package typically contains resource*.go files implementing CRUD operations, datasource*.go files for read-only data, *test.go files with acceptance tests, *utils.go for shared transformation logic, *sweeper_test.go for test cleanup, and product.go defining package constants.
The concentration of service packages under a single services directory creates a predictable navigation pattern for contributors. The impact for developers is faster onboarding when tracing a resource to its implementation. The contextual layer connects the service package layout to the core registration file providermmv1resources.go which imports all service packages.
Path purpose mapping is documented as follows.
| Path | Purpose | Line Reference |
|---|---|---|
| google-beta/provider/ | Provider initialization, configuration schema | provider.go1-1189 |
| google-beta/fwprovider/ | Plugin Framework provider implementation | framework_provider.go1-860 |
| google-beta/services/ | Service-specific resource implementations | providermmv1resources.go19-191 |
| google-beta/transport/ | HTTP client, auth, retry logic | config.go1-2310 |
| google-beta/fwmodels/ | Framework provider data models | provider_model.go1-234 |
| google-beta/sweeper/ | Test resource cleanup utilities | gcpsweepertest.go1-191 |
| website/docs/ | Generated Terraform documentation | clouddeploydeliverypipeline.html.markdown1-50 |
| go.mod | Go module dependencies | go.mod1-124 |
| CHANGELOG.md | Release notes and version history | CHANGELOG.md1-297 |
The provider initialization schema lives in provider.go1-1189. The impact is that all provider-level configuration, authentication defaults, and version constraints are centralized there. The contextual layer links this to transport.Config which handles auth for both protocol implementations.
Dual Protocol Multiplexing
The provider implements both Terraform plugin protocols simultaneously through multiplexing. This design allows a gradual migration from legacy SDKv2 resources to Plugin Framework resources without breaking existing configurations.
| Aspect | SDKv2 Implementation | Plugin Framework Implementation |
|---|---|---|
| Entry Point | provider.Provider() | fwprovider.FrameworkProvider |
| File | provider/provider.go | fwprovider/framework_provider.go |
| Resources | Majority (~1000+) | Small subset (~10) |
| Protocol | terraform-plugin-sdk/v2 | terraform-plugin-framework |
| Use Case | Legacy, stable resources | New features (ephemeral resources, functions) |
| Schema Type | *schema.Schema | Framework schema types |
Both implementations share transport.Config handles auth for both.
The coexistence of ~1000+ SDKv2 resources and ~10 Framework resources reflects a pragmatic migration. The impact for users is that most resources remain stable under the legacy protocol while new capabilities such as ephemeral resources and functions are exposed via Framework. The contextual layer shows that auth and transport are shared, reducing duplication of HTTP client, auth, and retry logic defined in config.go1-2310.
The entry points are provider.Provider() in provider/provider.go and fwprovider.FrameworkProvider in fwprovider/framework_provider.go. The impact is that Terraform core can select the appropriate protocol during provider negotiation. The contextual layer ties this to the multiplexing strategy that lets the same codebase serve both protocols.
Magic Modules Code Generation
The provider leverages Magic Modules MMv1 to automatically generate approximately 95 percent of its code from YAML resource definitions. Generation is triggered after changes to Terraform providers for Google Cloud. After making a change to the Terraform providers for Google Cloud, you must integrate your changes with the providers. This page explains how to generate provider changes to the google and google-beta Terraform providers.
Before you begin:
- Set up your development environment.
- Update magic-modules as needed. These updates could be any of the following changes:
By default, running a full make provider command cleans the output directory OUTPUT_PATH before generating code to prevent sync issues. This will override and delete any changes to that directory.
The requirement to clean OUTPUT_PATH before generation prevents sync issues. The impact is that any local edits to generated files are destroyed. The contextual layer reinforces that the repository is generated by magic-modules and changes must be made upstream.
Generate google and google-beta providers is the workflow name referenced in the documentation. The impact for contributors is that local provider builds are reproducible only when magic-modules is updated first. The contextual layer connects to the DO NOT EDIT markers in generated files.
Service Package Organization
Resources are organized into 140+ service packages under google-beta/services. Each service package typically contains:
- resource_*.go files implementing CRUD operations
- datasource*.go files for read-only data
- *_test.go files with acceptance tests
- *_utils.go for shared transformation logic
- *sweepertest.go for test cleanup
- product.go defining package constants
The uniformity of package contents reduces cognitive load. The impact is that engineers can predict file names when debugging a specific GCP service. The contextual layer shows that acceptance tests and sweepers are colocated with implementation, which accelerates test cleanup during CI.
Core registration file providermmv1resources.go contains:
- Import statements (lines 19-191): All service packages
- GeneratedResources (line 856): Generated resource map
- HandwrittenResources: Custom resource map
- HandwrittenIAMResources: IAM-specific resources
- ResourcesMap(): Combines all resource maps
The import block spanning lines 19-191 centralizes dependency declaration. The impact is that adding a new service requires updating this import list. The contextual layer ties this to the 140+ service packages, where each addition expands the import surface.
Release Version v7.39.0
Releases: hashicorp/terraform-provider-google-beta Release list v7.39.0
NOTES:
- compute: migrated googlecomputeinstancetemplate resource partially to use direct HTTP rather than a client library (#12576)
- compute: migrated googlecomputenetworkpeering resource to use direct HTTP rather than a client library (#12587)
FEATURES:
- New Data Source:
googleagentregistryagent (#12590)
- New Data Source:
googleagentregistryendpoint (#12590)
- New Data Source:
googleagentregistrymcpserver (#12590)
- New Data Source:
googlecomputeinstancegroups (#12554)
- New Data Source:
googlestoragecontrolfolderintelligencefindingssummary (#12585)
- New Data Source:
googlestoragecontrolorganizationintelligencefindingssummary (#12585)
- New Data Source:
googlestoragecontrolprojectintelligencefindingssummary (#12585)
- New Resource:
googleagentregistrybinding (#12590)
- New Resource:
googleagentregistryservice (#12590)
- New Resource:
googleartifactregistryprojectconfig (#12575)
- New Resource:
googlebiglakehivedatabase (#12580)
- New Resource:
googlecomputebulkperinstanceconfig (#12592)
- New Resource:
googlecomputefirewallpolicyiambinding (#12552)
- New Resource:
googlecomputefirewallpolicyiammember (#12552)
- New Resource:
googlecomputefirewallpolicyiampolicy (#12552)
- New Resource:
googlecomputenetworkfirewallpolicyiambinding (#12552)
- New Resource:
googlecomputenetworkfirewallpolicyiammember (#12552)
The migration of compute resources to direct HTTP rather than a client library reduces dependency on generated client libraries. The impact is tighter control over API request shapes for beta surfaces that may change. The contextual layer connects this to the beta designation where API changes are expected.
The addition of new data sources for agent registry and storage control intelligence findings summaries expands observability coverage. The impact for platform teams is the ability to query findings summaries without custom API calls. The contextual layer links these data sources to the broader trend of adding read-only introspection for beta compliance products.
Community Resources and Maintenance
Tutorials: learn.hashicorp.com
Forum: discuss.hashicorp.com
Documentation: https://www.terraform.io/docs/providers/google/index.html
Mailing list: Google Groups
Issue tracker: terraform-provider-google
The Terraform Google provider beta is a plugin that allows Terraform to manage resources on Google Cloud Platform. This provider is maintained by the Terraform team at Google and the Terraform team at HashiCorp.
Please see instructions on how to configure the Google Provider.
The community channels provide support paths. The impact is that users encountering beta API changes can report issues to the shared issue tracker terraform-provider-google. The contextual layer notes that documentation links point to the GA provider documentation, which overlaps with beta functionality.
Generating Providers from Magic Modules
Generate google and google-beta providers.
After making a change to the Terraform providers for Google Cloud, you must integrate your changes with the providers. This page explains how to generate provider changes to the google and google-beta Terraform providers.
Before you begin:
- Set up your development environment.
- Update magic-modules as needed. These updates could be any of the following changes:
By default, running a full make provider command cleans the output directory OUTPUT_PATH before generating code to prevent sync issues. This will override and delete any changes to that directory.
The make provider command is the primary integration step. The impact is that CI pipelines must run this command to keep generated code in sync with YAML definitions. The contextual layer ties this back to the 95 percent generated code metric and the DO NOT EDIT policy.
Conclusion
The terraform-provider-google-beta provider represents a parallel release channel for Google Cloud Platform resources that are not yet generally available. The architecture combines a legacy SDKv2 majority with a small Plugin Framework subset, shares transport.Config for authentication, and relies on Magic Modules MMv1 to generate approximately 95 percent of code from YAML definitions. The 140+ service packages under google-beta/services provide a predictable layout where resource*.go, datasource*.go, *test.go, *utils.go, *sweepertest.go, and product.go coexist per service. Core registration in providermmv1_resources.go aggregates imports from lines 19-191, GeneratedResources at line 856, HandwrittenResources, HandwrittenIAMResources, and ResourcesMap().
The beta designation means resources may have API changes, breaking changes, or deprecations as features evolve before reaching GA status. This reality necessitates the use of terraform init -upgrade after new releases to obtain the latest stable version of the Google provider, and it requires teams to monitor CHANGELOG.md for version history. Maintenance is shared between the Terraform team at Google and the Terraform team at HashiCorp, with the repository generated by magic-modules and manual edits overwritten on regeneration.
Release v7.39.0 illustrates ongoing evolution with migrations of compute resources to direct HTTP and the introduction of new data sources and resources for agent registry, artifact registry, BigLake, compute firewall policy IAM, and storage control intelligence findings summaries. The provider remains a bridge between early GCP feature access and Terraform infrastructure as code, with its code generation system and dual protocol multiplexing ensuring both stability for existing users and a path for new capabilities.