# GoogleCloudPlatform/cloud-builders: Choosing a Cloud Build Builder Image > GoogleCloudPlatform/cloud-builders provides prebuilt images for common build and deployment tools used with Google Cloud Build. It is useful for teams seeking straightforward official images, but versioned and multi-platform alternatives may fit some builds better. **GoogleCloudPlatform/cloud-builders** — Builder images and examples commonly used for Google Cloud Build - Repository: https://github.com/GoogleCloudPlatform/cloud-builders - Website: https://cloud.google.com/cloud-build/ - Stars: 1,463 · Forks: 616 - Language: Go - License: Apache-2.0 - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/googlecloudplatform-cloud-builders ## What the official Cloud Builders repository provides GoogleCloudPlatform/cloud-builders solves a practical packaging problem in Google Cloud Build. A build step needs a container image that already contains a command-line tool and is configured so Cloud Build can execute it. Instead of maintaining separate images for every common development tool, this repository publishes official images under `gcr.io/cloud-builders/`. The collection covers build tools, cloud clients, package managers, deployment utilities, and storage helpers. Listed builders include `aactl`, `bazel`, `curl`, `docker`, `dotnet`, `gcloud`, `gcs-fetcher`, `git`, `gke-deploy`, `go`, `gradle`, `gsutil`, `javac`, `kubectl`, `mvn`, `npm`, `twine`, `wget`, and `yarn`. The repository contains a top-level directory for each name, so the source for a builder and its build definition is kept in a corresponding project area. This is aimed at users of the hosted Google Cloud Build API who want recognized images for common build steps. It can also suit maintainers who want to inspect the source behind an official image. It is not a general container image catalog, a dependency resolver, or a replacement for the Cloud Build service itself. The images are inputs to build steps configured in Google Cloud Build. The README also separates public contributions from official builders. Community-contributed builders are available in the Cloud Builders Community repository. That distinction matters when choosing between an image maintained in this repository and another community project. ## How a builder image enters a Cloud Build workflow The integration point is an image reference. A Cloud Build configuration selects a prebuilt image such as `gcr.io/cloud-builders/...`, and Cloud Build uses the command-line tool packaged in that image as the build step. The repository describes each official image by the tool it runs, which makes the image-to-command relationship more predictable than an arbitrary base container. The repository also states that each builder includes a `cloudbuild.yaml`. Its default behavior pushes the resulting image to Artifact Registry. Using that default configuration requires an Artifact Registry repository created with `gcr.io` domain support. This is a meaningful deployment dependency: selecting a builder image does not remove the need to configure the destination registry when building the builder itself. The hosted service is not interchangeable with an arbitrary builder repository. Public community images can work as build steps when they are compatible with Google Cloud Build, but the README warns that some require an explicit `entrypoint`. An image that contains the desired binary is not automatically usable in the same way as an official builder. Entry point behavior is therefore one of the first things to check when adopting a replacement. The README also explains that Artifact Registry automatically redirects `gcr.io` requests for Container Registry hosts to corresponding Artifact Registry repositories. That transition path allows the official `gcr.io/cloud-builders/...` image names to remain part of the workflow even though Google deprecated Container Registry. ## Finding a builder and completing a first Cloud Build use The README does not provide a local installation command, package-manager installation procedure, or a complete copy-and-paste `cloudbuild.yaml` for a first pipeline. It directs users to the Google Cloud Build documentation for service setup and identifies the prebuilt images at `gcr.io/cloud-builders/...`. It also links to the Artifact Registry setup documentation for the repository's default `cloudbuild.yaml` behavior. Consequently, there is no justified command sequence to reproduce here. For a first real use, select a directory name from the repository list only if the build needs that tool. For example, a Go build would use the `go` builder, while a Kubernetes operation would use `kubectl`. Confirm the intended image name in the repository documentation or source before inserting it into a Cloud Build configuration. The README does not state a version tag for any builder, so a pinning policy cannot be inferred from it. Before running the builder's default `cloudbuild.yaml`, create the required Artifact Registry repository with `gcr.io` domain support. Then use the official image as the Cloud Build step and supply the command expected by that build. The README does not document a universal verification command or a repository-wide rollback procedure. Those details must come from the relevant builder source and the Google Cloud Build documentation rather than an invented example. ## Official Cloud Builders versus versioned upstream images The strongest alternative is a direct move from the official builder to an upstream or community-supported image. The README explicitly recommends alternatives for many tools because they often support several versions and platforms through tags. For Java workloads, the official `javac` builder is replaced by a choice among `openjdk`, `gradle`, and `maven`. These images expose a matrix of Java and build-tool versions across multiple platforms. That is more useful when a build must select a known Java release or Gradle version instead of accepting whatever tool version the official image contains. For Node.js packages, the `node` image provides `npm` and `yarn` entrypoints. The official repository separates those capabilities into `npm` and `yarn` builders. A project that needs a selected Node.js version can use the upstream image's version tags, subject to the tags that the provider publishes. Other examples follow the same approach. `golang` comes from the Go team, the `docker` image supports tagged versions across multiple platforms, and the Cloud SDK image provides `gcloud`, `gsutil`, and `kubectl` through multiple entrypoints. These images are compatible with hosted Cloud Build according to the README, but explicit `entrypoint` configuration may be necessary. The practical difference is control: official builders reduce configuration, while upstream images expose version and platform choices at the cost of entrypoint and compatibility checks. ## Artifact Registry requirements and the Container Registry transition Artifact Registry is part of the operating model for rebuilding these images. The README says each builder's default `cloudbuild.yaml` pushes its image to Artifact Registry, and that the repository must be created with `gcr.io` domain support first. This creates a concrete prerequisite for maintainers and teams that build their own copies rather than only consuming the published images. Google announced the deprecation of Container Registry on 2023-05-15. The README states that official Cloud Builder images are not affected by that deprecation and that Artifact Registry redirects `gcr.io` requests to corresponding Artifact Registry repositories. This distinction is important: using an old `gcr.io` image reference does not mean the official builder is being removed from service. The repository has no GitHub releases, so the README's image list does not provide a release version for each builder. It also does not establish a tag compatibility matrix. Teams that need reproducible builds should not assume that a moving reference is acceptable merely because the repository is active. They need to verify tag availability and pinning behavior in the Cloud Build documentation or the relevant image metadata. ## Maintenance scope and licensing implications The repository is not archived, and its last push was on 2026-06-22. The repository has no GitHub releases, and the README does not publish upgrade notes, a support window for individual images, or a repository-wide version policy. Changes to a builder may therefore be harder to track than changes in a repository with formal releases. The repository is licensed under Apache-2.0. That license governs the repository source and is relevant when organizations inspect, modify, redistribute, or package its contents. The license does not by itself describe the licenses of every command-line tool included in the prebuilt images. Engineers considering redistribution should review the applicable notices and image contents rather than treating the repository license as a complete inventory of third-party terms. The README also contains a future direction statement saying that most images now include notices pointing to alternatives, and that documentation for community-supported images may be improved. This signals an ongoing transition in recommendations, but it does not provide a dated migration schedule. The safest upgrade decision is tied to a specific builder directory, its `cloudbuild.yaml`, and the image tag in use. ## Conclusion Adopt an official builder when simplicity and alignment with Google Cloud Build matter more than a broad version matrix. Do not adopt one by default when the build requires a specific tool version, multiple operating-system architectures, or tightly controlled upstream packaging. Verify the builder's entrypoint, Artifact Registry setup, tag policy, and tool version before making it part of a production build pipeline. ## FAQ ### What is GoogleCloudPlatform/cloud-builders used for? It provides official prebuilt container images for tools used in Google Cloud Build, including `bazel`, `go`, `docker`, `npm`, `kubectl`, and others. Images are published under `gcr.io/cloud-builders/...` and are intended as Cloud Build steps. ### Does GoogleCloudPlatform/cloud-builders include every version of each tool? The README does not claim that the official builders provide a full version matrix. It points users to community-supported and upstream images for multiple versions and platforms, including versioned `openjdk`, `gradle`, `maven`, `node`, `docker`, and `golang` images. ### What must be configured before using a builder's default cloudbuild.yaml? The README says the default `cloudbuild.yaml` pushes images to Artifact Registry. A repository with `gcr.io` domain support must be created before using that default configuration. ## Sources - [GoogleCloudPlatform/cloud-builders on GitHub](https://github.com/GoogleCloudPlatform/cloud-builders) - [Issues](https://github.com/GoogleCloudPlatform/cloud-builders/issues) - [License: Apache-2.0](https://github.com/GoogleCloudPlatform/cloud-builders/blob/master/LICENSE) - [Project website](https://cloud.google.com/cloud-build/) - [README](https://github.com/GoogleCloudPlatform/cloud-builders/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/googlecloudplatform-cloud-builders