The GCP Infrastructure Tools I Actually Recommend (and What Each One Is For)

Key points

• There is no single best tool for managing GCP infrastructure. Most teams run one tool per job: provisioning (Terraform/OpenTofu, Pulumi, Google Cloud Infrastructure Manager, Config Connector), Google-native operations (Cloud Console, gcloud, Cloud Asset Inventory, Cloud Monitoring), security posture (Security Command Center, Wiz, Orca Security), cost (Cloud Billing export to BigQuery plus FinOps Hub, Ternary, CloudZero), and developer self-service (Qovery, Cloud Run, Backstage).
• Terraform or OpenTofu with the Google provider, plus Cloud Monitoring and a BigQuery billing export, covers most of what a GCP team needs at zero license cost. Add a CNAPP such as Wiz or Orca Security when you go multi-cloud or hit compliance requirements, and a cost tool such as Ternary or CloudZero when you need unit economics that billing exports cannot produce.
• Google Cloud Infrastructure Manager is Google's managed Terraform runner and the successor to Deployment Manager, which Google is retiring (support ended April 1, 2026; the service turns down after June 30, 2027). If you are picking IaC on GCP today, Terraform-compatible HCL is the safest bet because Google's own managed service runs it.
• The gap most teams hit is not provisioning, it is day-2 developer access. Terraform provisions GKE well and does nothing about how a developer ships a service to it, gets a preview environment for a pull request, or tears it down afterwards.
• If you are starting on GCP today, Qovery is the fastest way to get a production-grade setup with best practices already in place: a GKE cluster in under 20 minutes, apps deploying shortly after, self-service for developers, and per-PR preview environments - inside your own GCP project, and identically on AWS, Azure, Scaleway, or an existing Kubernetes cluster.

---

Most GCP teams I work with own four or five infrastructure tools and still take three days to give a new developer a working environment. That gap is the real story of GCP tooling in 2026. The provisioning layer is solved and commoditized. The path from a merged pull request to a running, reviewable environment is where teams still lose days.

Google Cloud is worth taking seriously as a home for that work. It held 15% of the global cloud infrastructure market in Q2 2026, behind AWS at 28% and Microsoft at 20%, according to Synergy Research Group, and Alphabet reported Google Cloud revenue of $24.8 billion for the quarter, up 82% year over year, in its Q2 2026 earnings release. More teams are landing on GCP, and most of them are assembling the same stack from scratch.

This is a map of that stack, organized by the job each tool does rather than by vendor category. I have tried to be fair to every tool here, including the ones we compete with, because a map is only useful if it is honest.

What are the top tools for managing GCP infrastructure in 2026?

The tools most GCP teams standardize on fall into five jobs: provisioning, native operations, security posture, cost management, and developer self-service. No single tool covers all five well, and the teams that shop by vendor category usually end up with two tools overlapping on one job and nothing covering another.

Here is the flat version, one line per tool:

• Terraform / OpenTofu - declarative provisioning of GCP resources as code using the hashicorp/google provider.
• Pulumi - provisioning in general-purpose languages (TypeScript, Python, Go, .NET, Java) instead of HCL.
• Google Cloud Infrastructure Manager - Google's managed service that runs your Terraform configurations for you.
• Config Connector / Crossplane - manage GCP resources as Kubernetes custom resources.
• gcloud CLI + Cloud Console - the primary interfaces to operate GCP by command line and browser.
• Cloud Asset Inventory - a searchable record of every resource and policy in your organization.
• Cloud Monitoring / Logging - Google's built-in observability stack for metrics, logs, traces.
• Security Command Center - Google's native security and compliance posture management.
• Wiz / Orca Security - agentless multi-cloud security posture and risk graphing.
• Ternary / CloudZero / nOps / CoreStack - cost allocation, unit economics, commitment and governance tooling.
• Cloud Billing export to BigQuery + FinOps Hub - the free cost baseline for GCP.
• Backstage - an open-source developer portal framework you build on.
• Google Cloud Run - serverless container hosting with request-based billing.
• Qovery - an internal developer platform that provisions clusters and gives developers self-service deployments in your own cloud account.

A vendor that claims to do all five jobs is usually strong in one and thin in the rest. It is worth checking two things per tool before you commit: its license, and whether it runs inside your own GCP project or ships your data to a vendor SaaS. That second point decides a lot for regulated teams.

Which tool should you use to provision GCP infrastructure as code?

Terraform or its OpenTofu fork with the hashicorp/google provider is the default answer for GCP provisioning. The strongest signal is that Google's own managed IaC service, Infrastructure Manager, runs Terraform configurations rather than a proprietary format, so writing Terraform-compatible HCL keeps every door open.

Terraform has the largest module ecosystem and a provider that Google co-develops in the open through the GoogleCloudPlatform/magic-modules repository. HashiCorp puts the hashicorp/google provider at over 800 resources and 300 data sources. The catch is licensing: HashiCorp moved Terraform to the Business Source License (BSL 1.1) on August 10, 2023, which some procurement teams treat as a blocker.

That is what OpenTofu exists for. It is a Terraform fork under the MPL 2.0 license, hosted by the Linux Foundation and announced in September 2023. For most Google-provider usage it is a drop-in, so pick it if BSL licensing is a concern.

Pulumi takes a different path: you write infrastructure in TypeScript, Python, Go, .NET, or Java, and its core is Apache 2.0. It fits best when your platform team writes more application code than configuration and wants real loops, types, and tests around infrastructure.

Google Cloud Infrastructure Manager is Google's managed Terraform runner. It executes your blueprints through Cloud Build and keeps Terraform state in Cloud Storage, so there is no state backend to babysit. If you want IaC without operating the runner, this is the native option. Config Connector and Crossplane instead model GCP resources as Kubernetes custom resources; they are worth it only when GKE is already your control plane and you want one reconciliation loop for everything.

One tool to stop reaching for: Deployment Manager. Google deprecated it, ended support on April 1, 2026, and will turn the service down after June 30, 2027, with Infrastructure Manager named as the migration path.

Here is the honest limit that sets up the rest of this guide: IaC provisions resources, and it does nothing about how a developer ships an application onto them. Writing the GKE, VPC, IAM, and networking modules yourself is weeks of platform work that most teams do not need to repeat.

What GCP-native tools should you use before buying anything third-party?

Google ships a usable baseline at zero or near-zero cost that most teams underuse: gcloud CLI, Cloud Console, Cloud Asset Inventory, Organization Policy Service, Cloud Monitoring and Logging, Security Command Center Standard, and Cloud Billing export to BigQuery. Exhaust these before you sign a third-party contract.

Cloud Asset Inventory answers "what do we actually have running and who owns it," which is the exact question many third-party CSPM tools charge you to answer. Organization Policy Service and IAM Conditions go one step further: they give you org-level and folder-level guardrails that an external scanner can only report on, never enforce.

For observability, Cloud Monitoring and Logging are the sensible default. Cloud Logging includes a free monthly allotment per project and then charges per GiB ingested, and Cloud Monitoring has a free tier for metrics before per-unit pricing kicks in. Teams outgrow this when they need cross-cloud dashboards or long retention, which is where Datadog, Grafana Cloud, or Chronosphere start to earn their cost.

On cost, Cloud Billing export to BigQuery plus the FinOps Hub gives you a free baseline, including committed use discount recommendations. On security, Security Command Center runs Standard at no additional cost with basic posture management; Premium adds advanced posture management, attack path analysis, and threat detection for Google Cloud; and higher tiers extend to multi-cloud coverage with Mandiant threat intelligence. Read the tier page before you assume you need to pay.

My rule of thumb: buy third-party when you run more than one cloud, when an auditor needs evidence Google's console cannot export, or when a person is spending more than a day a week reproducing a report by hand.

Which GCP security and cost tools are worth paying for?

Third-party security and cost tools earn their price in two situations: you run more than one cloud, or you need evidence for an auditor or a CFO that Google's native views cannot produce. Below those thresholds, Security Command Center and a BigQuery billing export are usually enough.

On security, Wiz and Orca Security both use agentless snapshot scanning and build a risk graph across GCP, AWS, and Azure. That is their real advantage over single-cloud native tooling: one correlated view of exposure across every cloud you run. Agentless scanning is fast to deploy but weaker on live runtime signals, so teams that need runtime detection often end up adding an agent-based layer too. Security Command Center's higher tiers bring Mandiant threat intelligence into the picture and are strongest when GCP is your primary or only cloud.

On cost, the labels differ more than the marketing suggests. Ternary is built around FinOps Foundation practices with deep GCP and BigQuery roots. CloudZero focuses on unit cost, such as cost per customer and per feature. nOps leans on automated commitment management. CoreStack targets governance-heavy enterprises. The real differentiator is allocation and unit economics, not "find idle VMs" - Google's own recommender already does the idle-resource part.

Be fair to your own stage here. For a single-project GCP startup, none of these are necessary yet, and the label and tag hygiene they all depend on is the actual prerequisite. If your resources are not tagged, you will pay for dashboards nobody trusts. One narrow exception: for hybrid and lift-and-shift migrations, Google Cloud VMware Engine and the Broadcom/VMware tooling around it matter, but that is a migration concern, not a day-2 management one.

What do GCP infrastructure tools not solve for your developers?

Every tool listed so far is built for the people who own the infrastructure, not the people who ship on it. That is why the most common bottleneck on GCP is not provisioning a GKE cluster, it is the ticket a developer files to get an environment and the days they wait for it.

The symptoms are consistent across the teams we see: Terraform pull requests queued behind one platform engineer, developers waiting days for a staging namespace, preview environments nobody ever got around to automating, and non-production GKE node pools running 24/7. That last one is expensive at scale; Flexera's 2026 State of the Cloud report put wasted cloud spend at 29%, its first increase in five years.

Managed Kubernetes does not close this gap. Google runs the GKE control plane, and you still own ingress, DNS, TLS certificates, secrets, database wiring, RBAC, and CI plumbing. Kubernetes itself is now the default substrate: the CNCF 2025 Annual Survey found that among container users, 82% run Kubernetes in production, up from 66% in 2023. The wiring around it is still yours to build.

The pressure got worse in 2026. AI coding tools are now used by a wide majority of developers - the Stack Overflow 2025 Developer Survey reported that 84% use or plan to use them, up from 76% - and autonomous agents increasingly open pull requests on their own. Every agent-generated PR needs an isolated, disposable environment to be reviewed honestly, and manual environment provisioning is the first thing to break under that volume.

This is the fifth job, developer self-service, and IaC, CNAPP, and FinOps tools deliberately do not cover it. The honest options for this layer are Google Cloud Run (excellent until you need VPC-heavy, stateful, or many-service setups), Backstage (a CNCF portal framework where you still build every plugin and the plumbing behind it), and internal developer platforms. The demand is real and measured: Google's DORA research finds that internal developer platforms improve individual productivity and organizational performance, and Gartner has forecast that by 2026, 80% of software engineering organizations will have platform teams.

What is the fastest way to get started on GCP with best practices already in place?

The fastest path to a production-grade GCP setup is to not rebuild the standard pieces yourself. Qovery provisions a GKE cluster with sane networking, IAM, ingress, TLS, and observability defaults, and gets your first application deployed shortly after - inside your own GCP project, with the same experience on AWS, Azure, Scaleway, or an existing Kubernetes cluster.

Start with the time comparison. A hand-rolled Terraform landing zone (VPC, subnets, node pools, IAM, an ingress controller, cert-manager, external-dns, secrets, and CI wiring) is typically weeks of platform work. Qovery's documentation describes installing on GCP and deploying a fully managed GKE Autopilot cluster in less than 20 minutes, with the standard defaults already applied.

"Best practices in place" means something concrete: private networking, per-environment isolation, role-based access scoped by project and cluster, databases backed by managed cloud services rather than pets running in the cluster, and managed cluster upgrades so the Kubernetes version does not rot.

On top of that you get a real SDLC out of the box: git-push deployments, preview environments created per pull request and deleted on merge, and deployment rules that auto-stop non-production environments so idle staging stops burning GCP credits. This is also where the coding-agent problem gets handled: every agent-generated pull request gets its own live preview environment, so agent output is reviewed in a running environment rather than only in a diff. Qovery also has an autonomous agents capability in preview that picks up issues, works in isolated cloud environments, and opens pull requests.

Because Qovery runs in your own cloud account (BYOC), the bill, committed use discounts, VPC, and IAM stay in your name. Committed use discounts are worth protecting: Google documents savings of up to 55% for standard machine types and up to 70% for memory-optimized types on three-year commitments. The same model runs identically on AWS, Azure, Scaleway, or your existing Kubernetes cluster, which matters for the many teams running GCP plus something else.

What you skip by starting here: writing and maintaining your own Terraform module library, your own Helm chart conventions, your own preview-environment controller, and your own developer portal. And to be clear about who this is not for - if you need a single Cloud Run service, you are a pure data-platform team, or you have no Kubernetes and no plans for it, Qovery is the wrong choice and Cloud Run or plain gcloud will serve you better.

How does Qovery fit alongside Terraform and Google-native tooling on GCP?

Qovery is an internal developer platform that deploys and operates applications inside your own GCP project, so it sits on top of Terraform and Google-native tooling rather than replacing them. Terraform keeps owning landing zones, VPCs, org policies, and shared data services; Qovery owns the application delivery loop on GKE.

The coexistence pattern is clean. A Terraform module provisions the shared VPC, Cloud SQL, and organization policies that your cloud team is accountable for. Qovery provisions and operates the GKE cluster and gives developers self-service on top of it. Qovery never replaces org-level policy, landing zones, the networking topology your cloud team owns, or your existing compliance tooling.

The capabilities Qovery brings to that loop are the verified ones from the section above: git-push deployments, preview environments per pull request, auto-stop for non-production, managed cluster upgrades, role-based access scoped by project and cluster, and databases backed by managed cloud services. Because it is Kubernetes-native and cloud-agnostic, the same model runs on AWS, Azure, Scaleway, or a self-managed Kubernetes cluster, which is why it fits teams running GCP alongside another cloud.

The honest way to judge this layer is by time to first deploy, not by feature count.

How do you choose a GCP tooling stack for your team size?

Match the stack to your stage. A five-engineer team needs Terraform or OpenTofu, gcloud, a billing export, and a self-service layer they did not build themselves. A 200-engineer multi-cloud org needs all five layers with a named owner for each.

• Startup (1-15 engineers): Terraform or OpenTofu, plus Cloud Run or one small GKE cluster, plus a Cloud Billing export. Skip CNAPP and FinOps tools entirely, and do not build a platform team's worth of tooling with five engineers.
• Scale-up (15-100 engineers): add GKE, an internal developer platform for self-service, Security Command Center Premium, and label-based cost allocation.
• Enterprise (100+, multi-cloud or regulated): add Wiz or Orca, Ternary or CloudZero, policy-as-code, CoreStack-style governance, and a platform team that owns the golden paths.

Two anti-patterns show up again and again. The first is buying a platform or FinOps tool before you have labelled resources and a working IaC pipeline; you will pay for dashboards nobody trusts. The second is reinventing the wheel - six months of platform engineering to rebuild preview environments, RBAC, and cluster upgrades that already exist off the shelf.

If you want a checklist you can copy, use one question per job. "Who changed this?" is IaC. "What do we have running?" is Cloud Asset Inventory. "Is this exposed?" is CNAPP. "Why did the bill jump?" is FinOps. "Why does an environment take three days?" is the self-service layer.