Google Cloud Deploy API
Browse all Google APIs✓ Official Vendor SpecDeveloper ToolsCi Cdoauth232 EndpointsREST
For Agents
Promote releases through staged delivery pipelines on GKE, Cloud Run, and Anthos, with approval gates, rollback, and rollout management. Useful for managed continuous-delivery workflows on GCP.
Use for: I need to promote the latest release from staging to production, Approve the pending rollout waiting on the production target, Roll back the production deployment to the previous successful release, List every release on our service in the last 30 days
Not supported: Does not build artefacts, run application traffic, or store source code — use for staged release promotion, approval, and rollback only.
Google Cloud Deploy is a managed, opinionated continuous-delivery service that promotes container images and Kubernetes manifests through a series of target environments such as staging and production. The API exposes delivery pipelines, releases, rollouts, targets, and approval steps so agents can promote a release to the next stage, abandon a release, approve a pending rollout, or roll back to a previous successful deployment. Cloud Deploy integrates with Cloud Build for build artefacts and with GKE, Cloud Run, and Anthos for deployment targets.
Install Jentic One Beta
Connect the Cloud Deploy API to your agent
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Cloud Deploy API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
1
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh2
Step 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
Capabilities
What an agent can do with Cloud Deploy API.
Create a delivery pipeline that defines the sequence of target environments
Cut a release that promotes a specific container image through the pipeline
Approve, advance, or abandon a pending rollout
Roll back to a previous successful release on a given target
Cancel a rollout that is mid-flight on a target environment
List targets, releases, and rollouts to surface delivery state to dashboards
Configure custom target types for delivery to non-default runtimes
Use Cases
Patterns agents use Cloud Deploy API for, with concrete tasks.
★ Staged Release Promotion to GKE
Platform teams use Cloud Deploy to promote a tested container image through dev, staging, and production GKE clusters with explicit approval gates between stages. Each promotion is an advanceRollout call; production rollouts wait on an approveRollout call from a release manager. Setup typically takes a day per service; subsequent releases take seconds.
Call POST /v1/{name}:advance on the rollout resource with phaseId set to the target phase, then POST /v1/{name}:approve once production is ready
Automated Rollback on Failure
SRE workflows watch for elevated error rates after a rollout and call rollbackTarget to restore the previous release. The API returns a new rollout that re-applies the prior image and Kubernetes manifests, so service health returns to baseline without a manual rerun of the original pipeline.
Call POST /v1/{name}:rollbackTarget with the target resource name and an optional release reference to specify which release to roll back to
Release Awaiting-Approval Dashboard
Release managers use the rollouts list endpoint with a filter on approvalState to surface every rollout currently waiting for sign-off. The dashboard pairs the data with deployment metadata so reviewers can approve or abandon with full context. The same endpoint backs alerting that escalates if a rollout stalls past a threshold.
Call GET on the rollouts collection with filter=approvalState=NEEDS_APPROVAL across the configured delivery pipelines
AI Agent Release Approver via Jentic
An agent invoked by an on-call engineer searches Jentic for the right Cloud Deploy operation, gathers the rollout context, and either advances, approves, or rolls back the release based on the engineer's intent. Jentic injects a scoped OAuth token at execution time so the agent never holds long-lived credentials.
Search Jentic for 'approve google cloud deploy rollout', execute against POST /v1/{name}:approve with approved=true, and report the resulting rollout state
Key Endpoints
32 endpoints — google cloud deploy is a managed, opinionated continuous-delivery service that promotes container images and kubernetes manifests through a series of target environments such as staging and production.
METHOD
PATH
DESCRIPTION
POST
/v1/{+name}:advance
Advance a rollout to its next phase
POST
/v1/{+name}:approve
Approve a rollout awaiting sign-off
POST
/v1/{+name}:abandon
Abandon a release that should no longer be promoted
POST
/v1/{+name}:cancel
Cancel an in-flight rollout
POST
/v1/{+name}:rollbackTarget
Roll back a target to a previous release
GET
/v1/{+name}/operations
List long-running operations on a resource
GET
/v1/{+name}/locations
List Cloud Deploy locations available to a project
POST
/v1/{+name}:advance
Advance a rollout to its next phase
POST
/v1/{+name}:approve
Approve a rollout awaiting sign-off
POST
/v1/{+name}:abandon
Abandon a release that should no longer be promoted
POST
/v1/{+name}:cancel
Cancel an in-flight rollout
POST
/v1/{+name}:rollbackTarget
Roll back a target to a previous release
GET
/v1/{+name}/operations
List long-running operations on a resource
GET
/v1/{+name}/locations
List Cloud Deploy locations available to a project
Why Jentic?
Three things that make agents converge on Jentic-routed access.
Credential isolation
Google Cloud OAuth 2.0 credentials and service account keys are stored encrypted in the Jentic vault. Agents receive short-lived access tokens scoped to cloud-platform — raw service account JSON never enters the agent context.
Intent-based discovery
Agents search Jentic by intent (e.g. 'approve google cloud deploy rollout' or 'rollback cloud deploy target') and Jentic returns the matching operation with its parameter schema, so the agent can call the right endpoint without reading Discovery docs.
Time to first call
Direct Cloud Deploy integration: 2-5 days for OAuth, pipeline modelling, and long-running operation polling. Through Jentic: under an hour — search, load schema, execute.
Related APIs
Alternatives and complements available in the Jentic catalogue.
FAQs
Specific to using Cloud Deploy API through Jentic.
What authentication does the Cloud Deploy API use?
The Cloud Deploy API uses OAuth 2.0 with the cloud-platform scope. Tokens are issued for a Google service account or end user. Through Jentic, the OAuth credential lives in the Jentic vault and the agent receives a short-lived access token only — the underlying service account JSON never enters agent context.
Can I promote a release to the next environment with this API?
Yes. Call POST /v1/{name}:advance on the rollout resource to move it to the next phase, or create a new rollout against the next target if the pipeline is configured for serial promotion. Production rollouts that require approval pause on a NEEDS_APPROVAL state until /v1/{name}:approve is called.
What are the rate limits for the Cloud Deploy API?
Cloud Deploy quotas are published per-method in the Google Cloud console under the Cloud Deploy quota page; typical defaults are several hundred read requests per minute per project, with concurrent rollout limits per target type (GKE, Cloud Run, custom).
How do I roll back a production release through Jentic?
Search Jentic for 'rollback google cloud deploy target' and execute against POST /v1/{name}:rollbackTarget on the target resource. The API creates a new rollout that re-applies the previous successful release; the agent can poll the rollout for completion and report the resulting state.
Does Cloud Deploy support custom deployment targets?
Yes. Custom target types are first-class resources — define a customTargetType with a render and deploy action, and reference it from a target inside a delivery pipeline. The same approval, advance, abandon, and rollback verbs apply to custom targets.
Is Cloud Deploy free?
Cloud Deploy charges a per-target-environment monthly fee documented on the Cloud Deploy pricing page. Builds run by Cloud Build and the runtime resources targeted (GKE, Cloud Run) are billed separately under their own services.
GET STARTED