You can deploy Cloud Functions directly from Artifact Registry, but what’s really wild is how it fundamentally shifts your build and deployment pipeline from a "build-then-deploy" model to a "build-once, deploy-many" paradigm.
Let’s see this in action. Imagine you’ve built a container image for your Cloud Function and pushed it to Artifact Registry. Your gcloud command to deploy might look like this:
gcloud functions deploy my-function \
--gen2 \
--region=us-central1 \
--runtime=nodejs20 \
--source-artifact=us-central1-docker.pkg.dev/my-project/my-repo/my-function-image:latest \
--entry-point=handler \
--trigger-http
Here, source-artifact points directly to the container image in Artifact Registry. This isn’t just a shortcut; it’s a declarative instruction to the Cloud Functions service to pull that specific image and run it. The runtime and entry-point are still specified, but the core executable code is now a immutable artifact.
This pattern solves the problem of inconsistent build environments and slow deployment cycles. Traditionally, you’d build your function’s source code, then deploy that source. If your build environment changed, or if you needed to deploy the same code to multiple environments (dev, staging, prod), you’d rebuild each time. By using Artifact Registry, you build your container image once. This image becomes the single source of truth for your function’s code and dependencies. You can then deploy this exact same image to different Cloud Functions instances, or even to different regions, with high confidence that it will behave identically.
The mental model here is that your Cloud Function is now a container. The Artifact Registry image is the blueprint. When you deploy, you’re not giving Cloud Functions source code to compile; you’re telling it which pre-built, tested, and versioned container image to run. The --gen2 flag is crucial because it signifies you’re using the newer generation of Cloud Functions, which is built on Cloud Run and inherently supports container-based deployments. The --source-artifact flag is what tells Cloud Functions where to find that container image.
Internally, when you deploy using --source-artifact, Cloud Functions uses Cloud Build under the hood to orchestrate the deployment. It doesn’t re-build your code. Instead, it pulls the specified image from Artifact Registry, stores it in its internal image registry, and then provisions a Cloud Run service with that image. The trigger configuration (like --trigger-http) is then applied to this Cloud Run service. This makes deployments incredibly fast and reliable because you’re deploying a finalized, tested artifact, not a recipe for building one.
The most impactful lever you control in this setup is image tagging. Using immutable tags like sha256:abcdef123456... (which you can get from the build process) instead of latest for your --source-artifact is critical for robust rollbacks and auditing. If a deployment goes wrong, you can simply redeploy the previous specific image tag, knowing it’s exactly what was running before. This granular control over the deployed artifact is what makes this pattern so powerful for production environments.
The next concept you’ll want to explore is setting up automated CI/CD pipelines to build and tag these container images directly into Artifact Registry upon code commits.