A base image is the starting point for most container-based development workflows. Developers start with a base image and layer on top of it the necessary libraries, binaries, and configuration files used to run their application. Google Cloud's buildpacks publishes base images with multiple configurations of the available system packages and languages.
Base images are hosted in every region where Artifact Registry is available. You can customize the base image path by replacing the first portion of the URI with your region of choice:
REGION-docker.pkg.dev/serverless-runtimes/STACK/runtimes/RUNTIME_ID
Replace:
- REGION with the preferred region, for example
us-central1. - STACK with the preferred operating system stack, for example
google-24. - RUNTIME_ID with the runtime ID used by your function, for example
python313.
For example, buildpacks references the Node.js 24 base image using the google-24 stack,
hosted in us-central1 with the following URL:
us-central1-docker.pkg.dev/serverless-runtimes/google-24/runtimes/nodejs24.
For more information on the supported runtimes, see the Runtime lifecycle.
Security patches
To provide security patches, Google-provided base images depend on upstream providers, such as open source projects and operating system distributions. Upstream providers routinely identify security vulnerabilities and release patch updates to their components. Google receives those updates and includes them in a new base image version using the following process:
- Google creates a new image containing the patched dependencies and tags
this image with
public-image-next. - Google tests the image with updated components and dependencies in staging environments.
- After tests are successful, Google starts updating all base images of running workloads to use the new base image.
- After testing and updates are complete, Google promotes the new image tag
to
latestandpublic-image-current, and deprecates the previouslatesttag.