Cloud Deploy is a managed service that automates delivering your application to a series of environments in a planned order.

When a team finishes building a new version of an application, that version still has a journey to make. It must usually be tried in a development environment, then in a testing or staging environment, and finally in production, where real customers use it. Each step has risks, and each step needs the same careful work: putting the right files in the right place, starting the new version, checking that it works and, if something goes wrong, going back to the earlier version.

Cloud Deploy takes over this journey. You describe your environments and the order in which a release should travel through them. Cloud Deploy then handles the movement, keeps a record of what is running where, lets you pause for approvals, and supports gradual strategies and rollbacks. According to Google’s documentation, it currently delivers to Google Kubernetes Engine (GKE) clusters, Cloud Run services and jobs, and GKE attached clusters, which can run in other clouds or on premises.

What Cloud Deploy is not

Cloud Deploy does not build your application and does not write your code. Building is the job of a continuous integration system, such as Cloud Build. Cloud Deploy begins where building ends. It takes the finished product, usually a container image, and delivers it. Keeping these two jobs separate is a deliberate design choice, and we will see why it helps in later chapters.

Understanding the pain explains every feature of the service.

In a small project, delivery can be as simple as copying a file to a server. As the project grows, the simple way breaks down. There are more environments, more people, more services and more releases. Small mistakes, such as deploying the wrong version to production or forgetting a setting, have larger consequences. Teams often respond by writing long scripts and checklists, which slowly become fragile and known by only one or two people.

A handful of words describe the entire service. Learn them once and the documentation becomes readable.

Continuous integration builds the product. Continuous delivery ships it. Cloud Deploy handles the second half.

Continuous integration, usually shortened to CI, means that every time a developer saves code, an automatic process builds the application and runs tests. Continuous delivery, CD, means the tested result is automatically prepared and moved through environments toward production. Google Cloud offers a set of services that fit together across both halves.

flowchart LR
  A["Developer commits code"] --> B["CI build and tests"]
  B --> C["Container image in registry"]
  C --> D["Create release in Cloud Deploy"]
  D --> E["Dev target"]
  E --> F["Staging target"]
  F --> G["Production target"]
  G --> H["Observability and feedback"]
        

Google’s documentation stresses that any CI tool, script or system can trigger a release, and any source repository or artifact repository can be used. You are not forced to use Cloud Build for the first half, although it fits naturally.

The pipeline is the heart of the service: it says where releases go and in what order.

A delivery pipeline is defined in a configuration file written in YAML, a simple text format of names and values that people can read easily. According to the documentation, it includes a name, a description, the promotion sequence, optional labels and annotations, and optionally the definitions of the targets themselves. Targets can alternatively live in their own files. The pipeline file is kept alongside your project so that changes to delivery are reviewed like any other change.

Rules about pipelines and targets

Several pipelines may share the same target. For example, two different services might both deliver to the same shared staging cluster. But within a single pipeline, a given target can appear only once in the sequence. This keeps the path unambiguous: a release cannot loop back to a station it already visited.

A target is a destination environment, and the type of target decides how deployment happens.

The documentation lists the supported runtimes as GKE clusters, Cloud Run services or jobs, and GKE attached clusters. Google’s pages also describe custom targets, which let teams deliver to other kinds of destinations through their own deployment logic. Check the current documentation for the full and latest list.

What a target definition holds

A release freezes everything needed to deploy a specific version, so that what you test is exactly what you ship.

A release is created when your CI process or a script calls Cloud Deploy. It points to the exact container images to use, the rendering source, which is the set of files describing your application, and the skaffold configuration. Cloud Deploy then renders the final instructions for each target in the pipeline and stores them. Because the rendered result is stored with the release, it does not change afterwards.

This is a quiet but powerful idea. When you promote a release from staging to production, you are not rebuilding anything. You are moving the same, already-tested bundle forward. The image that passed tests in staging is the very same image that runs in production.

A rollout is the live act of deployment, and it has a life cycle you can watch.

Every deployment of a release to a target is a rollout. The first release in a pipeline automatically creates a rollout to the first target, and every promotion afterwards creates a new rollout. A rollout moves through states such as waiting for approval, in progress, succeeded or failed. Behind the scenes Cloud Deploy uses Cloud Build to run the deployment step in the same region as your pipeline.

stateDiagram-v2
  [*] --> PendingApproval: target needs approval
  [*] --> InProgress: no approval needed
  PendingApproval --> InProgress: approved
  PendingApproval --> Rejected: rejected
  InProgress --> Succeeded: deployment healthy
  InProgress --> Failed: deployment error
  Failed --> InProgress: retry
  Succeeded --> [*]
  Rejected --> [*]
        

What you can do with a rollout

Skaffold is the engine under the hood, and rendering is how one set of files becomes many environment-specific instructions.

Skaffold is an open source command line tool originally designed to speed up development for container applications. Cloud Deploy uses it for three jobs: rendering, deploying and verifying. You keep a skaffold configuration file with your project, and Cloud Deploy runs Skaffold through Cloud Build when needed.

Rendering means producing the final deployment instructions for each target. Your application usually has common instructions, such as which container to run, along with differences per environment, such as how many copies to run or which database to connect to. The render step combines the common files, the per-target differences and the exact image references into a finished set for each target. Render events can send notifications so tools or people know when rendering started and whether it succeeded.

Putting every concept together in a single story.

sequenceDiagram
  participant Dev as Developer
  participant CI as CI build
  participant CD as Cloud Deploy
  participant T1 as Staging target
  participant Appr as Approver
  participant T2 as Production target
  Dev->>CI: Push a code change
  CI->>CD: Create release with image
  CD->>CD: Render for every target
  CD->>T1: Rollout to staging
  T1-->>CD: Deployment succeeded
  CD->>Appr: Production needs approval
  Appr-->>CD: Approved
  CD->>T2: Rollout to production
  T2-->>CD: Deployment succeeded
        

Some changes deserve a second pair of eyes, and approvals build that pause into the pipeline.

You can require approval for any target by setting a flag in the target definition. When a rollout to that target is ready, Cloud Deploy does not start it. Instead it waits, and publishes a message through Pub/Sub, a messaging service, announcing that approval is required. A connected system, such as a ticketing tool or a chat bot, can pick up that message and start its own approval workflow. A person with the right permission then approves or rejects the rollout.

Approval is also a permission

The right to approve is controlled by access rules, just like other actions. A common good practice is to separate roles: the person or system that creates releases should not be the only one who can approve them for production. This is called separation of duties.

Promotion moves releases forward, and notifications keep everybody informed along the way.

Promoting a release deploys it to the next target in the sequence, which creates a new rollout. You can promote through the console, the command line or automatically using automation rules, which we will explore soon. Promotion is the heart of the “ship through stages” idea.

Cloud Deploy also publishes notifications through Pub/Sub for important events. According to the documentation, these cover rendering and deployment starting, succeeding and failing, along with approvals being required, granted or rejected. Other systems can subscribe to these messages to post to a team chat, open a ticket, update a dashboard or trigger a further process.

The standard strategy is the simplest: deploy the new version in one step.

With a standard deployment, Cloud Deploy puts the new version on the target in a single step, with no gradual traffic shift between old and new versions. Rollback, verification and multi-target deployment are all supported. For many development and test environments, this simplicity is exactly right. Nobody minds if a test environment is briefly unstable, and speed matters more than caution.

A canary sends the new version to a few users first, so problems are found while they are still small.

The name comes from the old practice of miners carrying a canary bird into a mine: if the air turned bad, the small bird showed it first, and the miners had time to leave. In software, the “canary” is a small share of your traffic or infrastructure running the new version. If it behaves, you gradually increase the share. If it misbehaves, only a few users were affected and you pull back.

In Cloud Deploy, a canary rollout moves through canary phases before reaching the final stable phase. According to the documentation, a typical example for Cloud Run is a 50 percent canary, where half of the traffic goes to the new revision and half to the old one, followed by advancing to 100 percent. Percentages must be whole numbers. Canary needs an existing version for comparison, so on the very first deployment to a target, Cloud Deploy may skip the canary phases and go straight to stable.

flowchart LR
  A["Old version serves all traffic"] --> B["Canary phase 10 percent new"]
  B --> C{"Healthy"}
  C -->|"Yes"| D["Canary phase 50 percent new"]
  D --> E{"Healthy"}
  E -->|"Yes"| F["Stable phase 100 percent new"]
  C -->|"No"| G["Roll back to old version"]
  E -->|"No"| G
        

How traffic splitting is done

The mechanism depends on the runtime. On Cloud Run, traffic is divided between revisions. On GKE, Google’s documentation describes approaches that use Kubernetes service networking or the Gateway API. Because the details are specific to each setup, read the current canary guide for your runtime before configuring it.

Planning a good canary

A successful canary is planned before it starts. First, choose the signals that show health, such as the share of requests that fail, how long responses take and any business measure that matters, like completed purchases. Second, choose how long each phase should last. A phase that is too short may end before rare problems appear, while a phase that is too long slows every release. Third, decide what happens on failure: who is alerted, whether an automatic rollback should occur and how the team learns from it afterwards.

It also helps to think about who sees the canary. If the new version receives a random slice of traffic, the same user may see old and new behavior on consecutive requests, which can be confusing if the two versions differ visibly. For changes that affect what users see, teams sometimes combine canaries with feature switches, which are settings inside the application that turn new behavior on for chosen groups. The delivery service controls which code is running, and the feature switch controls who sees the new behavior.

Every release plan should include a way back.

You can roll back on any target. According to the documentation, a rollback creates a new rollout of the last successfully deployed release, using the same parameters that were used for that earlier deployment. Notice that a rollback is itself a recorded rollout, so your history stays complete and honest: it shows the bad release, the decision and the return.

Rollbacks are quick because the earlier release is already rendered and stored. Nothing needs to be rebuilt. The risk is not in the mechanics, but in what has changed outside the application, such as database structure changes that the old version cannot understand. A safe release plan always asks whether the previous version can still run against the current data.

Real products often run in many places at once, and the service can deploy to several at the same time.

Imagine a global application that runs in clusters in several regions. Deploying to each region one by one, by hand, would be slow and error-prone. The documentation describes parallel deployment: one stage of the pipeline can deploy to multiple targets at the same time, and this works with every deployment strategy. In practice, a team defines a parent target that groups child targets, and a single rollout fans out to the children.

flowchart TD
  R["Release approved for production"] --> P["Production group target"]
  P --> A["Region A cluster"]
  P --> B["Region B cluster"]
  P --> C["Region C cluster"]
        

Parallel deployment also affects how you think about failure. If one regional target fails while the others succeed, you have a partial rollout, and the team must decide whether to retry the failed region, roll it back or pause everything. Writing this decision down in advance, as a short runbook, turns a stressful improvisation into a calm checklist.

Why it helps

The trade-off is blast radius. Releasing to all regions together means that a hidden bug reaches all regions together. Many teams therefore deploy first to one pilot region and only then to the rest, using separate stages. Pricing also considers multi-target pipelines, as discussed in the cost chapter.

Automation rules remove repetitive clicking while keeping control where it matters.

An Automation is a resource attached to a delivery pipeline. It selects one or more targets and holds rules describing what should happen automatically. Each time a rule fires, a record called an automation run is created. You can suspend an automation without deleting it, and a pipeline can hold a large number of rules, documented as up to 250.

How an automation is organized

Think of an automation as a small rulebook with a clear subject. It names the targets it watches, called selectors, and then lists rules. When a rollout on a watched target reaches a certain state, the matching rule acts. For example, “after a successful rollout to staging, wait thirty minutes, then promote to the production pilot”. Every action leaves a record, so you can read exactly why the pipeline moved. Platform logs are still produced when an automation is suspended, which lets you test a new rule safely before it is allowed to act.

Waiting times are an underrated feature. A short wait after a successful staging rollout gives monitoring a chance to reveal slow-burning problems. A longer wait between canary phases gives rare errors time to show up. Choosing these waits is a business decision about how much patience you can afford, and they are easy to adjust as you learn.

Combining rules wisely

A common arrangement uses automatic promotion between development and staging, where speed matters, but keeps manual approval for production. A repair rule on production gives a safety net: if a deployment fails, it retries a couple of times and then returns to the last good version without waking anyone at night.

Deploying is not the same as working. Verification checks that the new version is actually healthy.

A deployment can succeed technically, meaning the files were applied and the processes started, while the application itself is broken. Maybe it cannot reach its database, or it answers every request with an error. Verification adds an automatic check after deployment. Cloud Deploy supports verification through Skaffold, where you define a test, often a container that runs a few requests against the new version and reports whether they passed. If verification fails, the rollout is marked as failed and the failure can trigger your repair rules.

Cloud Deploy also supports hooks, which are extra steps that run before or after a deployment. A pre-deployment hook might prepare something, such as announcing a maintenance window. A post-deployment hook might run a cleanup or notify another system. Exact capabilities and configuration vary, so read the current documentation on verification and hooks before relying on them.

Staging and production should be alike, but never identical, and the differences must be managed carefully.

Every environment needs some different values. Production might run ten copies of a service while development runs one. The address of the database differs. The log detail level differs. If you copy whole files and edit them by hand for each environment, the files drift apart and mistakes creep in. Cloud Deploy supports passing parameters into the rendering step so that one shared description can produce environment-specific results. The documentation describes deploy parameters that can be attached at the pipeline, target or release level; confirm the current rules about where each can be used.

When the built-in destinations do not fit, you can describe your own.

Not every organization runs on Google Kubernetes Engine or Cloud Run. Some deliver to virtual machines, to other cloud platforms, to internal systems or to special hardware. Google’s documentation describes custom targets, in which you provide the rendering and deployment logic yourself, often as containers that Cloud Deploy runs, and the service continues to supply the pipeline structure, promotion, approvals, history and automation around it.

The attraction is that you keep a single, consistent delivery process, even though the destinations differ. The cost is that you now own the code that does the deployment, including its testing and maintenance. Use custom targets only when no built-in target can meet your needs, and read the current documentation to learn what is supported.

Delivery tools have the keys to production, so who can do what must be planned carefully.

Google Cloud controls access through Identity and Access Management, called IAM. In Cloud Deploy, different actions need different permissions: creating pipelines and targets, creating releases, approving rollouts, promoting, and managing automations. The service also uses a service account, which is a non-human identity, to render and deploy. That identity needs permission to act on the target environment, such as updating a Cloud Run service or a cluster.

Principles to follow

A delivery pipeline is a favorite target for attackers, because whatever it ships runs with trust.

If an attacker slips a malicious image into your pipeline, the pipeline itself will deliver it all the way to production. Protecting the supply chain means making sure that only trusted, verified software travels through. Several Google Cloud capabilities relate to this, including vulnerability scanning of images in the registry and policy tools that can require images to be signed or attested before deployment. Cloud Deploy fits into this picture because releases refer to specific image identifiers and because it records what was deployed. The exact integrations and their availability change, so confirm the current documentation for features such as attestation checks.

You cannot manage what you cannot see, and delivery produces useful signals at every step.

Cloud Deploy collects metrics and audit details throughout pipeline execution. Logs from rendering and deployment are available through Google Cloud’s logging service, audit logs record who did what, and Pub/Sub notifications announce key events. Combined with application metrics from your running services, these signals answer the questions that matter during and after a release.

Making signals useful to people

Raw logs are rarely read in the middle of an incident. What people need is a short, clear story: which release, which target, which stage, what changed and what the current state is. Teams often build a simple dashboard or chat summary fed by delivery notifications, showing the latest release in each environment, any rollout waiting for approval and any recent failures. A new team member can then understand the state of delivery within a minute, without learning the whole system first.

Alerts deserve the same care. An alert should tell the receiver what happened, why it matters and what to do first. Alerts that fire constantly teach people to ignore them, so tune them to the few conditions that truly need a human, such as a production rollout failing, a canary showing rising errors or an approval waiting too long.

Useful delivery measures

Many organizations track a few simple measures of delivery health, popularized by research on high-performing teams. Deployment frequency shows how often you ship. Lead time shows how long a change takes from commit to production. Change failure rate shows how often releases cause problems. Time to restore shows how fast you recover. Delivery records from Cloud Deploy supply raw material for these numbers.

The service itself is priced simply, and the supporting services are where most costs hide.

According to the pricing page, the unit of billing is an active delivery pipeline. A pipeline counts as active in a billing month if at least one release or rollout was created for it. The first active multi-target pipeline in a billing account is free. Each additional active multi-target pipeline was listed at five US dollars per month. Single-target pipelines, which use exactly one target, are not charged. Pricing is tied to the pipeline name, so deleting a pipeline and creating another with the same name counts as one pipeline.

Cloud Deploy also relies on other services that are billed separately. Cloud Build runs the render and deploy steps. Cloud Storage holds the rendered files in a bucket in the same region as the pipeline. Audit logging and the logging service store records. Always confirm current numbers on the official pricing page, since prices and free allowances can change.

Ways to keep costs sensible

A typical, sensible setup that many teams can adopt and adjust.

In this arrangement, developers push code to a repository. A trigger starts a build that tests the code, creates a container image, scans it and stores it in a registry. The build then creates a release in Cloud Deploy. The release deploys to a development target automatically, then is promoted to staging with checks, and then, after human approval, to production using a canary strategy. Notifications go to a team chat, and monitoring watches the canary.

flowchart TD
  A["Source repository"] --> B["Build and test"]
  B --> C["Scan and store image"]
  C --> D["Create release"]
  D --> E["Dev target auto deploy"]
  E --> F["Staging target with verification"]
  F --> G["Approval gate"]
  G --> H["Production canary phases"]
  H --> I["Production stable"]
  D -.-> N["Notifications to chat and tickets"]
  H -.-> M["Monitoring and alerts"]
  M -.-> R["Repair or rollback"]
        

Walking through a normal day

On an ordinary morning a developer merges a small fix. Within minutes the build finishes and a release appears in the pipeline. It lands on the development target without anyone touching a button. The team lead sees the staging rollout succeed and verification pass, so she approves the production rollout before lunch. The canary starts at a small share of traffic, a dashboard shows normal error rates, and the automation advances the phases while the team eats. By the afternoon the release is stable in production, and nobody had to remember a single command. That quiet, repeatable rhythm is the real product Cloud Deploy gives a team.

On a bad day the same rhythm protects you. Suppose the canary shows rising errors. The monitoring alert fires, the rollout is stopped or rolled back, and only a small share of users ever saw the problem. The rollout history records exactly what happened, and the team fixes the bug in a new release that goes through the same steps. Nobody has to improvise under stress, because the path was already built.

Choices inside the architecture

The number and shape of your stages is a design decision with real trade-offs.

More stages mean more safety but more time and cost. Fewer stages mean speed but less protection. A good starting point for many teams is three: development, staging and production. Development accepts every change automatically and exists for quick feedback. Staging closely resembles production and runs deeper checks. Production receives only releases that passed staging, often through approval and a canary.

Thinking about teams and ownership

Environments also reflect how people are organized. In a small company, one team often owns the whole path from code to production, and a single pipeline with three stages is perfect. In a larger company, a platform team may own the targets and the rules for production, while product teams own their own releases and the early stages. This division works well when it is written down clearly: the platform team decides what protections production requires, and product teams decide how often and how fast they ship within those protections.

Be careful with shared environments. When many pipelines deliver to the same staging cluster, one team’s broken release can disturb everyone else’s tests. Teams often solve this by giving each service its own namespace or its own small environment, or by scheduling heavy tests carefully. The point is that environment design is partly a technical question and partly a question about how people work together, and both deserve attention.

Keeping staging honest

Staging is only valuable if it resembles production. Use the same kind of runtime, the same configuration structure and similar data shape and volume, as far as cost and privacy allow. A staging environment that is much simpler than production will happily approve releases that then fail for real customers.

Stories show how the pieces work together in daily life.

There is more than one way to deliver software, and each has its place.

These approaches are not enemies. Some organizations use a repository-driven tool inside clusters and still use a managed delivery service to orchestrate the promotion of releases between environments. Choose based on where your team’s strengths lie and which platforms you deliver to, and evaluate with a small pilot before committing.

Architects write down significant choices so that later teams understand the reasons.

Learning from the mistakes of others is the cheapest education.

Five classic traps in detail

When something fails, work calmly from the simplest cause to the hardest.

A calm method

A short list to review before every important launch.

Quick answers to the questions beginners ask most often.

Everything in this guide on one short page.

Cloud Deploy is a managed continuous delivery service. You describe a pipeline of targets, your build system creates releases, and the service renders, deploys, pauses for approvals, supports canary strategies and rollbacks, and records everything. It works best when combined with a good build process, honest staging, careful permissions and watchful monitoring.