# Cloud Foundation Fabric: Terraform module library and FAST landing zone for GCP > Cloud Foundation Fabric is a GCP-specific Terraform toolkit, available under Apache-2.0, that provides an extensive module library covering networking, data, compute, AI and security services, alongside Fabric FAST, a reference implementation for bootstrapping an enterprise Google Cloud organization. The repository ships as a single unit intended to be forked into a production-owned copy or kept synchronized as a prototyping toolkit. **GoogleCloudPlatform/cloud-foundation-fabric** — End-to-end modular samples and landing zones toolkit for Terraform on GCP. - Repository: https://github.com/GoogleCloudPlatform/cloud-foundation-fabric - Stars: 2,132 · Forks: 1,280 - Language: HCL - License: Apache-2.0 - Published: 2026-10-11 · Updated: 2026-10-11 · Language: en - Canonical page: https://hysenlabs.com/projects/googlecloudplatform-cloud-foundation-fabric ## Clone-and-fork adoption: why the toolkit ships as one repository rather than a module registry Cloud Foundation Fabric is a Terraform toolkit built exclusively for Google Cloud Platform. Its scope divides into two components that share the same repository: Fabric FAST, which handles the initial setup of a GCP organization hierarchy, and a module library covering billing accounts, IAM, networking, compute, data, AI infrastructure, serverless, and security services. Adoption follows one of two patterns. A team can fork the repository into a separately owned copy to seed production use, or keep the upstream as the authoritative source and synchronize changes as they arrive. Both paths carry the full module library along; there is no option to pull individual modules from a Terraform registry. A fork is the expected pattern for teams that cannot reference external sources, and the module code is written to support that fork. The README links to CONTRIBUTING.md and FABRIC-AND-CFT.md, both in the repository, for the rationale behind this approach and a direct comparison with other GCP Terraform toolkits. ## Module interface: IAM bundled with resource creation; no external commands allowed Every module follows a shared interface built around one principle: stay close to the underlying GCP Terraform provider resource rather than abstracting it behind higher-level constructs. IAM assignments go into the same Terraform plan as the resource itself. Creating a GCP project and assigning roles to a service account is one module call, not two sequential calls with a state dependency between them. The design rule is that each module routes its work entirely through the Terraform provider. No module shells out to another tool to complete a step. The README states this as a hard design constraint, with no external commands as the given example. For teams auditing what a Terraform plan will modify before approving it, this makes each module's behaviour predictable from the plan output alone. Networking has the widest module coverage in the library: distinct modules handle DNS, NAT, VPC firewall policy, multiple load balancer configurations, HA VPN, Static VPN, VPN Dynamic, IPSec over Interconnect, Secure Web Proxy, VPC service controls, and VPC peering. A project factory module sits under process factories as its own category, separate from the single-project module in foundational. ## Fabric FAST: Terraform plan for a production-ready GCP organization from a blank billing account Fabric FAST is in the fast/ directory and addresses a specific starting problem. Getting a new GCP organization into a production-ready state requires provisioning folder structure, billing controls, log sinks, and networking before application teams can deploy anything. Most teams handle this sequence manually. FAST produces a Terraform plan that creates that initial infrastructure. Billing controls, an organizational folder hierarchy, log destinations, and a base networking layer are among the resources most enterprise GCP setups need before application teams can start working. These are the resources that application-level Terraform modules assume are already in place; FAST is the step that creates that assumption. A bootstrapping problem exists before FAST can run: Terraform needs organization-level permissions to create the resources that manage further permissions. FAST accounts for this sequence, but the detail is in fast/ rather than in the root README. Understanding the full scope of what FAST provisions requires reading the fast/ directory documentation directly. ## CURSED_KNOWLEDGE.md documents GCP API behaviors the repository accounts for but the README omits CURSED_KNOWLEDGE.md appears at the repository root but receives no mention in the README. By naming convention, files with this label in engineering projects collect platform behaviors that are technically correct but produce unexpected outcomes: API calls that succeed while silently ignoring a field, resources that initialize in an unexpected state, timing dependencies between API calls, and edge cases absent from official documentation. For a toolkit that provisions organization policies, VPC service controls, billing accounts, and dozens of other GCP services through Terraform, the range of potential surprises is wide. This file represents knowledge the development team documented after encountering it. None of its contents appear through the module READMEs or through the root README, so a team reading only those files would not know it exists. The adrs/ directory at the repository root holds Architecture Decision Records. Like CURSED_KNOWLEDGE.md, adrs/ is not referenced in the README. ADRs capture the reasoning behind design choices that might otherwise appear arbitrary and are useful for teams that want to understand why the module interfaces are structured as they are. ## OpenTofu support via default-versions.tofu alongside default-versions.tf Two files sit at the repository root with nearly identical names: default-versions.tf and default-versions.tofu. The .tf file targets Terraform; the .tofu file targets OpenTofu, the open-source fork. Both exist in the repository, confirming that Cloud Foundation Fabric maintains compatibility with both tools. This is only discoverable from the file listing. The README does not mention OpenTofu by name in the visible section, so for teams that have shifted their standard tooling to OpenTofu, confirming this support requires inspecting the top-level directory rather than reading the README. FACTORIES.md is another top-level file not referenced in the README. Its name points to documentation for the factory pattern used in the project factory module, and teams building on top of that module benefit from reading it. The .pre-commit-config.yaml and .tflint.hcl files confirm that contributors work with pre-commit hooks and TFLint for static analysis of HCL. Setting up a fork for active development requires installing these tools to match the expected local workflow. ## AGENTS.md and GEMINI.md: AI assistant configuration in a repository that also provisions AI infrastructure AGENTS.md and GEMINI.md appear at the repository root alongside the standard Terraform and documentation files. Neither is referenced in the README. AGENTS.md is a convention used by AI coding tools for documenting how automated contributors should interact with a repository: it typically covers project structure, tooling conventions, and patterns that an AI assistant should follow when generating or reviewing code. GEMINI.md serves a similar purpose for Gemini models specifically. These files indicate that the cloud-foundation-fabric development team uses AI coding assistants within the repository workflow. This sits alongside the repository's AI module category, which includes 4 modules: AI Applications, and 3 components of the Gemini Enterprise Agent Platform: Agent Gateway, Agent Runtime, and Workbench. GEAP modules let teams provision that infrastructure through Terraform alongside other GCP resources, rather than configuring it through the GCP console. The skills/ directory at the top level does not appear in the README. Its name and the presence of GEMINI.md both point to AI-assisted development workflows built into the project itself. ## adrs/, blueprints/, and the tests/ suite in the repository layout Architecture Decision Records in adrs/ capture the reasoning behind design choices in the module interfaces and FAST structure. For teams building on top of the library, ADRs explain why specific module interface patterns were chosen, which is relevant for both the FAST bootstrapping sequence and the project factory design. The blueprints/ directory contains end-to-end example configurations that combine multiple modules into complete infrastructure patterns for specific use cases. These are distinct from the modules in modules/ and the landing zone in fast/; blueprints show how the pieces fit together at a larger scale. For teams evaluating whether Cloud Foundation Fabric covers their use case, blueprints/ provides more complete examples than the individual module READMEs. For teams working from a fork, the test suite in tests/ and the build tooling in tools/ are relevant for local development. The .pre-commit-config.yaml and .tflint.hcl files at the root confirm that contributors run pre-commit hooks and TFLint as part of the standard workflow. v59.0.0 was tagged on 2026-09-25, the last push was on 2026-10-06, and the code is available under an Apache-2.0 licence; that licence imposes no restrictions on commercial use and requires only that the licence text be included in distributions. ## Conclusion Cloud Foundation Fabric is appropriate for enterprise GCP teams that want Terraform-managed infrastructure with IAM bundled into each resource module and a proven pattern for bootstrapping an organization hierarchy. Teams running small projects without an organization setup, or teams that prefer pulling modules from a registry, will find the toolkit's scope larger than necessary. Before adopting it, read CURSED_KNOWLEDGE.md at the repository root for accumulated GCP API behaviors the team has documented, and check whether blueprints/ covers the infrastructure pattern your deployment needs. ## FAQ ### What is the difference between Cloud Foundation Fabric and terraform-google-modules? FABRIC-AND-CFT.md in the repository directly compares the two. Cloud Foundation Fabric is designed to be cloned and forked as a single unit rather than referenced from a Terraform module registry. Both provide Terraform modules for GCP, but the adoption model and interface design differ. ### What does Fabric FAST do? Fabric FAST is in the fast/ directory and provides both a reference design for an enterprise GCP organization hierarchy and a Terraform implementation of it. It covers folder structure, billing account configuration, logging, and networking, which are the prerequisites before application teams can deploy resources. ### Does Cloud Foundation Fabric support OpenTofu? Yes. A default-versions.tofu file exists at the repository root alongside default-versions.tf, confirming compatibility with both Terraform and OpenTofu. The README does not mention OpenTofu by name in the visible section. ### What does the no-side-effects constraint mean for Cloud Foundation Fabric modules? Every module completes its work through the Terraform provider only. No module shells out to gcloud, runs a script, or invokes an external data source. The README states this as a hard design constraint, with no external commands as the given example. ### What is CURSED_KNOWLEDGE.md in the Cloud Foundation Fabric repository? CURSED_KNOWLEDGE.md is a top-level file not documented in the README. By naming convention, such files collect platform behaviors and API quirks that are technically correct but produce unexpected outcomes in practice. For a GCP Terraform toolkit of this scope, it holds GCP API behaviors the development team has documented and accounted for in the codebase. ## Sources - [GoogleCloudPlatform/cloud-foundation-fabric on GitHub](https://github.com/GoogleCloudPlatform/cloud-foundation-fabric) - [Issues](https://github.com/GoogleCloudPlatform/cloud-foundation-fabric/issues) - [License: Apache-2.0](https://github.com/GoogleCloudPlatform/cloud-foundation-fabric/blob/master/LICENSE) - [README](https://github.com/GoogleCloudPlatform/cloud-foundation-fabric/blob/master/README.md) - [Releases](https://github.com/GoogleCloudPlatform/cloud-foundation-fabric/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/googlecloudplatform-cloud-foundation-fabric