Google Cloud Client Libraries for Go: Go SDK for GCP

What are the Google Cloud Client Libraries for Go?

Google Cloud Client Libraries for Go is the googleapis/google-cloud-go monorepo: official Go packages, each wrapping one Google Cloud Platform API — storage, firestore, pubsub, and others — under the shared cloud.google.com/go module path. Every service lives in its own subdirectory in that single repo rather than as a standalone repo, and each package calls GCP's REST or gRPC endpoints so your code doesn't build those requests by hand.

Key Features and Supported APIs

• ✓One Go package per GCP service under the cloud.google.com/go module path, installed independently with go get — you only pull in the service you actually use.
• ✓Application Default Credentials (ADC) wired in by default, so a client on Compute Engine, GKE, or App Engine needs no manual credential setup.
• ✓Explicit credential control when ADC isn't enough: the GOOGLE_APPLICATION_CREDENTIALS environment variable, option.WithCredentialsFile, or the newer auth/credentials package paired with option.WithAuthCredentials.
• ✓Follows Go's own two-most-recent-major-release support policy rather than an arbitrary separate compatibility list — currently Go 1.25 and Go 1.26, per the README.
• ✓Repo topics list cloud-bigquery, cloud-datastore, cloud-pubsub, and cloud-storage among the service families covered.
• ✓A separate, continuously updated reference-docs page at cloud.google.com/go/docs/reference lists the full set of released APIs, rather than the root README enumerating every package.

Installing Go Client Libraries for Google Cloud

Installing a Google Cloud Go client library is one go get pointed at the specific service package you want — the README's own example is go get cloud.google.com/go/firestore@latest, and you swap firestore for whichever GCP service package you actually need. The README also flags that some packages inside the monorepo are still under development and can make backwards-incompatible changes, so pin a version instead of always tracking @latest in anything you ship. Beyond that single command, day-to-day usage details live in each package's own documentation rather than the root README.

Authenticating Your Go Google Cloud Applications

Every Google Cloud Go client defaults to Application Default Credentials (ADC): call something like client, err := storage.NewClient(ctx) and, inside Compute Engine, GKE, or App Engine, it picks up credentials automatically with no extra steps. Working locally, run gcloud auth application-default login from the Google Cloud CLI first, and ADC will find those credentials on your filesystem. When ADC isn't the right fit, point at a service-account key file directly — set GOOGLE_APPLICATION_CREDENTIALS to its path, or pass option.WithCredentialsFile("path/to/keyfile.json") into the client's New constructor. For finer control, the auth/credentials package builds an auth.Credentials value you hand to a client via option.WithAuthCredentials.

Who Should Use These Go Client Libraries?

Use Google Cloud Client Libraries for Go if you're building a Go service that already targets specific GCP products — Cloud Storage, Firestore, Pub/Sub, BigQuery — and you want per-service packages plus ADC handling credentials for you inside GCP. Skip it if your app runs on another cloud, if you need a language other than Go, or if you'd rather provision GCP resources declaratively than call them from application code — that's a job for something like Terraform, not a client library.

Alternatives to Go Client Libraries for GCP

Google Cloud Go Client Libraries FAQ

The problem it solves

A Go program that needs to talk to more than one Google Cloud service — Cloud Storage for files, Pub/Sub for messaging, BigQuery for analytics — would otherwise mean hand-building REST or gRPC calls against each service's own API shape, then repeating that work every time a new GCP product gets added to the project. google-cloud-go solves that by keeping one Go package per GCP service inside a single monorepo under the cloud.google.com/go module path, so wiring in Firestore or BigQuery next to Cloud Storage is another go get, not a new integration effort.

Best use cases

• •A Go backend running on Compute Engine, GKE, or App Engine that reads and writes Cloud Storage buckets, since ADC needs no extra configuration in those environments.
• •Wiring a Go service to Pub/Sub or BigQuery for event- or data-pipeline work, matching the cloud-pubsub and cloud-bigquery topics on the repo.
• •Local development against real GCP resources via gcloud auth application-default login instead of shipping a service-account key file around.
• •Swapping in tighter, explicit auth control — a credentials file or the auth/credentials package — for a Go app that runs outside Google's own infrastructure.

Related repositories