Cloud Deployment Manager: GCP’s Native IaC Tool and Why Most Teams Skip It

Cloud Deployment Manager is Google’s native infrastructure-as-code service — declarative YAML (or Python/Jinja2 templated) configuration that describes GCP resources, deployed and managed as a single unit Google tracks and can update or tear down coherently. It’s a genuinely capable tool, and it’s also the rare GCP service where the honest, practically useful advice is “understand it, then very likely use something else” — specifically Terraform, which has become the de facto standard for GCP infrastructure-as-code even among teams running entirely on Google Cloud.

That’s not a knock on Deployment Manager’s technical design so much as an observation about ecosystem gravity: most teams manage infrastructure across more than one provider or tool (GCP plus a SaaS DNS provider, GCP plus GitHub Actions configuration, GCP plus a third-party monitoring tool), and a single tool that handles all of it coherently beats a GCP-only tool that requires a second system for everything else. Understanding both what Deployment Manager does well and why the ecosystem moved elsewhere is genuinely useful context for making an informed choice rather than defaulting to either option out of habit.

A Basic Deployment Manager Template

resources:
  - name: my-web-server
    type: compute.v1.instance
    properties:
      zone: us-central1-a
      machineType: zones/us-central1-a/machineTypes/e2-medium
      disks:
        - deviceName: boot
          type: PERSISTENT
          boot: true
          autoDelete: true
          initializeParams:
            sourceImage: projects/debian-cloud/global/images/family/debian-12
      networkInterfaces:
        - network: global/networks/default
          accessConfigs:
            - name: External NAT
              type: ONE_TO_ONE_NAT

gcloud deployment-manager deployments create my-deployment \
  --config=vm-template.yaml

# Update the deployment after changing the template
gcloud deployment-manager deployments update my-deployment \
  --config=vm-template.yaml

# Tear down everything the deployment created
gcloud deployment-manager deployments delete my-deployment

This is a genuinely clean declarative model — you describe desired state, Deployment Manager computes and applies the diff, and it tracks every resource it created as part of the named deployment, letting you delete the whole thing cleanly later. Functionally, this is the same core value proposition Terraform and CloudFormation offer.

Where Deployment Manager Is Genuinely Limited

┌────────────────────────┬──────────────────────────────────────┐
│ Limitation                 │ Practical impact                            │
├────────────────────────┼──────────────────────────────────────┤
│ GCP-only                    │ A second tool is needed for any        │
│                             │ non-GCP resource — DNS at another       │
│                             │ registrar, a SaaS integration, another  │
│                             │ cloud entirely                          │
│ Smaller community and       │ Fewer community modules, examples, and  │
│ ecosystem                   │ Stack Overflow answers than Terraform    │
│ No built-in state           │ Deployment Manager tracks state          │
│ inspection/drift detection  │ implicitly but lacks Terraform's mature  │
│ as mature as alternatives   │ `plan`/drift-detection workflow           │
│ Limited templating power    │ Jinja2/Python templates work but are     │
│ compared to Terraform's     │ less ergonomic than HCL for complex,     │
│ module system                │ reusable, parameterized infrastructure    │
└────────────────────────┴──────────────────────────────────────┘

None of these are fatal flaws for a genuinely GCP-only environment with simple infrastructure needs — but they compound as infrastructure complexity and organizational scope grow, which is exactly the trajectory most real infrastructure teams follow over time.

Where It’s Still a Reasonable Choice

Despite the general recommendation toward Terraform, Deployment Manager has legitimate niches:

• Teams that are strictly, permanently GCP-only with no foreseeable multi-cloud or multi-tool infrastructure need, where the native integration (no provider plugin, direct API access, no state file to manage separately) is a genuine simplicity advantage.
• Simple, foundational bootstrapping — some organizations use Deployment Manager for the very first layer of infrastructure (creating the initial project structure, IAM bindings, and networking that everything else depends on) precisely because it doesn’t require any external tooling or state backend to get started.
• Google Cloud Marketplace solutions, some of which are built and distributed using Deployment Manager templates under the hood, meaning understanding it has some value even for teams that don’t choose to author their own infrastructure with it, simply to read and reason about what a Marketplace solution actually deploys.

Even within these niches, it’s worth periodically revisiting whether the assumptions still hold — a “permanently GCP-only” team can find that assumption doesn’t survive contact with a genuine new business need a year or two later, and foundational bootstrapping infrastructure has a habit of quietly growing well past what anyone originally intended it to cover when it was first set up.

Terraform: Why It Won the Ecosystem

resource "google_compute_instance" "web_server" {
  name         = "my-web-server"
  machine_type = "e2-medium"
  zone         = "us-central1-a"

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-12"
    }
  }

  network_interface {
    network = "default"
    access_config {}
  }
}

The same resource, expressed in Terraform’s HCL, looks structurally similar to the Deployment Manager YAML — the meaningful difference isn’t syntax, it’s ecosystem breadth. The same Terraform configuration language and workflow (plan, apply, state management) works identically whether you’re provisioning a GCP VM, an AWS S3 bucket, a Datadog monitor, or a GitHub repository’s branch protection rules, through the same provider plugin model. For any organization whose infrastructure genuinely spans more than one system — which is nearly every organization past a certain size — that consistency is worth more than any GCP-specific advantage Deployment Manager offers.

How a Deployment Actually Gets Applied and Tracked

Understanding the lifecycle mechanics is useful even if you end up choosing Terraform, since the underlying deployment model — describe desired state, let the tool compute a diff, apply the diff — is shared conceptually across every infrastructure-as-code tool.

The “tracked as one unit” property is what makes deployments delete genuinely clean — Deployment Manager knows exactly which resources belong to a given deployment and removes precisely those, rather than requiring you to manually enumerate everything that was created. This is the same fundamental guarantee Terraform state provides, just implemented as a Google-managed service rather than a state file you manage yourself (or store in a remote backend like Cloud Storage, which is the common Terraform pattern).

Real-World Use Case: Why a Team Migrated Away

A common pattern: a team starts with Deployment Manager because it’s GCP-native and requires no additional tooling, then adds a second cloud provider for disaster recovery, or starts managing DNS through Cloudflare instead of Cloud DNS, or needs to provision GitHub Actions secrets as part of their infrastructure pipeline. Each of these additions requires a separate tool alongside Deployment Manager, and the team ends up maintaining two (or more) infrastructure-as-code systems with different syntax, different state models, and different mental models — a genuinely worse position than having started with Terraform and having one consistent tool handle everything from day one, even the GCP-only pieces.

Best Practices (If You Do Use Deployment Manager)

• Use it for genuinely GCP-only, relatively simple infrastructure, and evaluate Terraform seriously the moment a second system or provider enters the picture.
• Keep templates modular using Jinja2 or Python templating, rather than one monolithic YAML file, to get at least some of the reusability benefit Terraform modules provide more naturally.
• Version control every template and treat deployment as a reviewed, deliberate operation, exactly as you would with any infrastructure-as-code tool — the discipline matters more than the specific tool.
• Document the decision to use Deployment Manager over Terraform explicitly, since it’s a deviation from the ecosystem default that a future team member will likely question and deserves a documented rationale.
• Revisit the decision periodically, not just once at initial adoption. An organization’s infrastructure scope tends to grow, and what was a reasonable GCP-only assumption at adoption time is worth re-checking against current reality every year or two rather than assumed permanently settled.

Common Mistakes

Choosing Deployment Manager by default without evaluating Terraform, simply because it’s “the GCP one.” This is the single most common mistake — defaulting to the native tool without considering whether the organization’s actual infrastructure scope (likely to include more than just GCP eventually) is better served by the ecosystem standard.

Underestimating the migration cost of moving off Deployment Manager later. Infrastructure-as-code migrations are genuinely disruptive regardless of direction — choosing deliberately upfront avoids a costly and risky migration once infrastructure has grown significantly on the “wrong” tool for the organization’s actual needs.

Mixing manually-created resources with Deployment Manager-tracked ones without clear boundaries. Resources modified outside Deployment Manager’s tracked deployment can cause confusing drift the next time an update is applied — a discipline problem shared with every infrastructure-as-code tool, not unique to Deployment Manager, but worth calling out.

Frequently Asked Questions

Is Deployment Manager being deprecated? As of current guidance it remains a supported GCP service, but Google’s own documentation and most practitioner guidance increasingly point toward Terraform (including Google’s own contributions to and investment in the Terraform GCP provider) as the recommended path for new infrastructure-as-code work.

Can Deployment Manager and Terraform manage the same GCP project safely? Not cleanly, if they’re managing overlapping resources — both tools assume they own the full lifecycle of resources they track, and having two systems both believing they control the same resource leads to drift and conflicting changes. A clean split (different tools for genuinely different resource sets) can coexist, but overlapping ownership should be avoided.

Does Deployment Manager support resources beyond core GCP infrastructure, like IAM and organization policies? Yes, it supports most GCP resource types including IAM bindings and organization-level policies, which is part of why it’s a legitimate option for GCP-only foundational infrastructure specifically.

What does migrating from Deployment Manager to Terraform actually involve? Typically importing existing resources into Terraform state using terraform import, then writing equivalent HCL configuration for each resource, and validating that Terraform’s plan shows no unintended changes before considering the migration complete — a genuinely involved process worth planning as a deliberate project, not a quick afternoon task.

Does Deployment Manager have an equivalent to Terraform’s plan command for previewing changes before applying? It has a preview capability (gcloud deployment-manager deployments update --preview) that shows what would change without applying it, conceptually similar to terraform plan, though generally considered less mature and less detailed in its diff output than Terraform’s equivalent.

Can I use Deployment Manager templates written by someone else, similar to Terraform modules? Templates can be shared and reused as files, but there’s no equivalent to the Terraform Registry’s ecosystem of versioned, publicly shared modules — reuse in Deployment Manager tends to be more manual, copying and adapting templates rather than pulling a versioned module dependency.

Summary

Deployment Manager is a legitimate, technically sound tool for genuinely GCP-only infrastructure — the honest assessment isn’t that it’s bad, it’s that most organizations’ actual infrastructure footprint outgrows “GCP-only” faster than they initially expect, and Terraform’s broader ecosystem support means starting there avoids a disruptive migration later. If your infrastructure truly is and will remain GCP-only, Deployment Manager remains a reasonable, well-supported choice; for nearly everyone else, the ecosystem has already voted with its adoption patterns, and it’s worth taking that signal seriously before investing significant infrastructure-as-code effort into the native tool by default, rather than discovering the mismatch only after a second cloud provider or external tool has already entered the picture and made switching genuinely painful.