# Google Cloud's buildpacks are the standard, the builders are the product > The GoogleCloudPlatform/buildpacks repository publishes the builder images and language buildpacks that Cloud Run, GKE, Anthos, App Engine and Cloud Functions use to turn source into a container image. It implements the Cloud Native Buildpacks specification, so the interesting question is not whether the standard is portable but what Google adds on top of it. **GoogleCloudPlatform/buildpacks** — Builders and buildpacks designed to run on Google Cloud's container platforms - Repository: https://github.com/GoogleCloudPlatform/buildpacks - Stars: 1,174 · Forks: 224 - Language: Go - License: Apache-2.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/googlecloudplatform-buildpacks ## What a builder is, and why the distinction matters The repository contains a set of builders and buildpacks designed to run on Google Cloud's container platforms, and the readme lists them: Cloud Run, GKE, Anthos, and Compute Engine running Container-Optimized OS. It also says they are used as the build system for App Engine and Cloud Functions. That last sentence is the one that changes how you read the project. These are not a side project for people who prefer buildpacks on Google Cloud. For a large part of Google Cloud, this repository is how your source code becomes a running service. The vocabulary comes from the Cloud Native Buildpacks specification, and the readme links the four concepts that matter for an application developer. A builder is a container image that contains buildpacks and the detection order in which builds are executed. A buildpack is an executable that inspects your app source code and formulates a plan to build and run your application. A buildpack group is several buildpacks which together provide support for a specific language or framework. And a run image is the container image that serves as the base for the built application. So a build is a negotiation. The builder runs the detection phase, where each buildpack in the group inspects your source and either claims it or passes, and then the build phase, where the claiming buildpacks produce a plan and the run image becomes the base of the final image. The readme states the compatibility plainly: they are 100 percent compatible with Cloud Native Buildpacks, and the project implements that specification. The repository is Go, module github.com/GoogleCloudPlatform/buildpacks, on Go 1.23, and it depends on the buildpacks libcnb library at version 2.0.0.. The audience is two groups. Google Cloud customers deploying to those platforms, and the engineers who want to know what the platform does to their source before the image appears. ## The buildpacks you inherit, and the ones Google adds The repository layout separates the standard machinery from the Google specific part, and the directories make that split concrete. There is a builders directory, a stacks directory, a pkg directory, an internal directory, a cmd directory and a tools directory, plus a kokoro directory for the continuous integration configuration and a licenses directory. The stacks directory is where the run images live, and the distinction between a builder and a run image is what makes the design composable. The build happens in a build image, and the result is placed on top of a run image that becomes the base of your application container. That is why the readme has a documentation page on custom build and run images, and why the language specific pages are separate from the platform specific ones. The language coverage is broader than the topic list suggests. The readme links language specific configuration pages for Node.js, Python, Go, Java, Ruby, PHP and Os-only, the last being the configuration for a build that uses only the base operating system image with no language runtime. The Google specific configuration is documented separately, on a page for service specific configs, alongside the page on setting environment variables and the page on custom build and run images. So there are three axes to configure: the language, the platform service, and the base images. That is the honest shape of the project. The language buildpacks are largely the standard ones, and the value Google adds is the set of builders, the stacks, and the service specific transformations, which is also where the interesting differences between the platforms live. ## The App Engine builders are a separate set with extra transforms The readme calls out the App Engine and Cloud Functions builders as distinct, and explains how. These builders create container images designed to run on those two services, and most of the buildpacks are identical to those in the general builder. The differences are two: there are additional buildpacks which add transformations specific to each service, and in order to optimize execution speed, each language has a separate builder. That second point is worth pausing on, because it is a design decision with a cost. A separate builder per language means smaller, more specialised images and a faster cold start for a given language, but it also means the number of builder images to maintain, and it means you pick a builder for a language and a service rather than a single universal builder. The example in the readme shows the shape of the invocation for an App Engine Java 17 runtime image: ```bash pack build --builder gcr.io/serverless-runtimes/google-22-full/builder/java ``` The builder image path carries the information. gcr.io/serverless-runtimes is the registry, google-22-full is the stack, and builder/java is the language. The name of the image is a specification of what the build will produce, and you can read the runtime generation and the language off it without opening anything. If you rely on a custom App Engine entrypoint in your app.yaml, the entry point is passed as an environment variable to the build, and the readme gives the second form: ```bash pack build --builder gcr.io/serverless-runtimes/google-22-full/builder/java --env GOOGLE_ENTRYPOINT="your entry point command" ``` This is the mechanism that connects the App Engine configuration model to the container world. The GOOGLE_ENTRYPOINT environment variable is how the platform tells the image which process to start. ## pack, kpack, tekton, skaffold: the same builders from different entry points The project is not tied to one client. The readme says the builder images are suitable for use with pack, with kpack, with tekton, and with skaffold, and with other tools that support the Buildpacks v3 specification. The specification version is the compatibility boundary, and the repository's own topic list includes buildpacksv3, which is the point. The four named tools cover different workflows. pack is the command line client, which is what the readme's own examples use. kpack, tekton and skaffold are the other tools the readme names. The same builder image works across all of them, which is the practical payoff of the standard. If your organisation runs Skaffold locally for the inner loop and Tekton in the cluster for the outer one, they can share a builder. The alternative approach, and the one worth naming explicitly, is a Dockerfile. A Dockerfile is explicit, auditable line by line, and it produces exactly the image you wrote, which is a real advantage when you have unusual build steps or when reproducibility is a legal requirement. Buildpacks are the opposite trade. You do not write the build, the buildpack detects your source and decides, which means the build is fast and consistent across services and languages but it is also opaque, and it is fast partly because it skips steps you might have wanted. The other difference is where the base image comes from. With a Dockerfile you choose your own base, and you inherit its patches and its update policy. With buildpacks the run image is chosen by the builder, which is what lets Cloud Run and App Engine start the image quickly. ## Running the image locally, and the environment variables that will bite you The readme does not stop at the build. The application container image can then be executed locally: ```bash docker run --rm -p 8080:8080 ``` That is worth doing, because it is the moment the platform specific behaviour stops being abstract. And the readme immediately flags the catch: locally, your application might depend on App Engine environment variables that would need to be set in the local environment. That is the fundamental difference between a buildpack image and a service image. The buildpack can bake in a default configuration, but the platform still injects configuration at run time, and the image is written on the assumption that those variables are there. A container that works on the platform can fail on your laptop, and the failure will look like a configuration bug rather than a build bug. So the local run is a smoke test, not a proof. It tells you that the image starts and that the process is listening, and it does not tell you that the service specific configuration is complete. For the App Engine builders in particular, this is the point at which the custom entrypoint matters. The GOOGLE_ENTRYPOINT variable tells the image what to run, and the platform's own variables tell it where the port is, what the instance identity is and what the environment looks like. Reproducing that locally means setting them by hand, which is exactly the work the platform was saving you from. ## Support stops at the Google Cloud boundary There is a short paragraph in the readme that decides who should use this, and it is easy to skim past. Google Cloud's buildpacks are only officially supported when used with Google Cloud products. Customers of Google Cloud can use the standard support channels for help using buildpacks with Google Cloud products. Not with buildpacks in general, and not with the images on their own. That is a reasonable position for a vendor, and the readme is straight about it. It also tells you what the risk looks like in practice. If you use these builders to produce images for Cloud Run, App Engine or Cloud Functions, you are inside the supported envelope. If you take a builder image and use it to produce an image for your own Kubernetes cluster, on your own hardware or on another cloud, you are outside it, and the compatibility claim with the Cloud Native Buildpacks specification is the only guarantee you have. That guarantee is not nothing. Being 100 percent compatible with the specification means a different builder, built by the community with the same specification, should be able to run the same buildpacks, and the buildpacks themselves are the standard pieces. What you lose is the guarantee about the specific Google stack images, the service specific transformations and the runtime behaviour. The project also asks for security issues to be reported through the SECURITY.md file, and it has a normal contribution process: a contributing guide, a label for good first issues, a label for issues that need help, and a label for discussion issues. The licence is Apache 2.0, in the LICENSE file at the root, with a separate licenses directory in the tree for the third party components that the images carry. ## No tagged releases, and a build image you pin by digest The repository is not archived, and the last push was on 2026-10-19. There are no GitHub releases, and that is not an oversight so much as a consequence of how the project is consumed. A builder image is not a library you add to a package manifest. It is a container image reference that appears in a build command, and the reference in the readme, gcr.io/serverless-runtimes/google-22-full/builder/java, encodes a stack generation and a language. When the stack rolls forward, a new builder image appears, and the old one remains available for the applications that still need it. The pinning mechanism is the image reference and the digest, not a release tag, and the long tail of stack generations is what makes that necessary. The same logic applies to the Go module in the repository, which is versioned separately and used by anyone who wants to work on the buildpacks themselves rather than consume them. The go.mod pins the Go version at 1.23 and pulls in the buildpacks libcnb library, the Google container registry client, the Docker client, the secret manager client, a retryable HTTP client, TOML and YAML parsers, and the semver library, which is the set of things you need to talk to a registry, run a container, read configuration and compare versions. The practical upgrade advice follows from all of this. Applications built on Cloud Run, App Engine or Cloud Functions do not upgrade themselves, the platform chooses the builder, and the risk of a builder change breaking your build is handled by the platform's own release process. Anyone using these builders directly, which is what the pack examples in the readme are for, has to manage the pin themselves, and that is where the missing release tags matter most. ## Conclusion Google Cloud's buildpacks are worth adopting if you deploy to Google Cloud and want the platform to decide how your source becomes an image, because the same builders back App Engine and Cloud Functions and the App Engine line adds the service specific transforms you would otherwise hand write. They are the wrong choice if you need reproducible builds you can audit line by line, if you need to build an image that runs somewhere other than Google Cloud, or if your build needs something the language buildpack does not do. Before you adopt them, read the documentation on Google Cloud's buildpacks overview and the language page for your stack, and check the service specific configurations page, because the App Engine and Functions builders add transformations that a plain Cloud Run build does not have. ## FAQ ### What is Google Cloud's buildpacks repository? It contains the builders and buildpacks designed to run on Google Cloud's container platforms, which are Cloud Run, GKE, Anthos and Compute Engine running Container-Optimized OS. The readme also states that they are used as the build system for App Engine and Cloud Functions, and that they are 100 percent compatible with Cloud Native Buildpacks. ### How do I build a container image with Google Cloud's buildpacks? With the pack client and a builder image. The readme's App Engine example is pack build --builder gcr.io/serverless-runtimes/google-22-full/builder/java, and a custom App Engine entrypoint is passed with --env GOOGLE_ENTRYPOINT="your entry point command". ### Can I run the image that Google Cloud's buildpacks produce locally? Yes, the readme shows docker run --rm -p 8080:8080 for the built application image. It warns that your application might depend on App Engine environment variables that would need to be set in the local environment, so a local run is a smoke test rather than a faithful reproduction of the service. ### Which languages do Google Cloud's buildpacks support? The readme links language specific configuration pages for Node.js, Python, Go, Java, Ruby, PHP and Os-only, the last being a build that uses only the base operating system image with no language runtime. ### Is Google Cloud's buildpacks officially supported outside Google Cloud? No. The readme states that they are only officially supported when used with Google Cloud products, and that customers of Google Cloud can use the standard support channels for help using buildpacks with Google Cloud products. ## Sources - [GoogleCloudPlatform/buildpacks on GitHub](https://github.com/GoogleCloudPlatform/buildpacks) - [Issues](https://github.com/GoogleCloudPlatform/buildpacks/issues) - [License: Apache-2.0](https://github.com/GoogleCloudPlatform/buildpacks/blob/main/LICENSE) - [README](https://github.com/GoogleCloudPlatform/buildpacks/blob/main/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-buildpacks