# google/go-cloud: portable cloud APIs for Go applications

> The Go Cloud Development Kit wraps blob storage, pub/sub, secrets, runtime configuration and SQL behind stable Go interfaces. It is a good fit for teams that need to move between AWS, GCP and Azure, and a poor fit for anyone who needs every provider-specific feature.

**google/go-cloud** — The Go Cloud Development Kit (Go CDK): A library and tools for open cloud development in Go.

- Repository: https://github.com/google/go-cloud
- Website: https://gocloud.dev/
- Stars: 9,911 · Forks: 859
- Language: Go
- License: Apache-2.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/google-go-cloud

## The problem google/go-cloud solves for Go teams

Write a Go service against the Google Cloud Storage SDK and moving it to S3 means rewriting the storage layer. Authorization, tracing and client construction differ per provider, and none of that code is interesting. The Go CDK replaces those provider SDKs with one set of Go interfaces. The README describes the intent as "Think `database/sql` for cloud products", which is the clearest way to read the design: the interfaces are the product, and the providers are drivers behind them.

The audience is Go application developers who expect to run on more than one cloud, either because the product is sold to customers who bring their own cloud account, or because a migration is plausible enough to plan for. A team that has committed to a single provider and uses that provider's distinctive services is not the audience. The library does not try to hide the cloud; it tries to make the parts that are genuinely interchangeable interchangeable.

## Portable APIs, driver packages and URL openers

The repository is organised by API rather than by provider. Top-level directories include blob/, pubsub/, runtimevar/, docstore/, secrets/, mysql/, postgres/ and server/, with aws/, gcp/ and azure/ holding driver implementations and contrib/ holding smaller ones. Each API package defines the interface; each provider subpackage implements it.

The entry point is usually an opener that takes a URL. The README's blob example calls `blob.OpenBucket(ctx, "s3://my-bucket")` and receives a `*blob.Bucket` without naming an AWS type anywhere. The scheme selects the driver, and credentials come from the environment the provider SDK already understands. The same pattern appears in the other APIs, so configuration can move into a URL or a connection string rather than into code.

The second mechanism is Wire. The README states that the project works well with the Wire code generator, which "creates human-readable code that only imports the cloud SDKs for services you use". That matters because the go.mod file pulls in the AWS SDK v2, several Azure SDK modules and a long list of cloud.google.com packages. Importing a driver package normally drags its provider SDK into the binary. Wire generates the wiring explicitly so unused drivers stay out, which keeps compile times and binary sizes down and avoids `init()` side effects. The trade-off is a build step and generated files in your repository.

## Installing google/go-cloud and opening a bucket

Installation is one module fetch. The README says to change into your project directory first so that module mode behaves as expected, then run:

```bash
go get gocloud.dev
```

The README notes that the Go CDK builds at the latest stable release of Go, and that earlier versions may compile but are not supported. The go.mod in the repository declares `go 1.26.0`, so treat that as the floor rather than an aspiration.

A first real use is opening a bucket and reading an object. The README gives this example:

```go
ctx := context.Background()
bucket, err := blob.OpenBucket(ctx, "s3://my-bucket")
if err != nil {
    return err
}
defer bucket.Close()
blobReader, err := bucket.NewReader(ctx, "my-blob", nil)
if err != nil {
    return err
}
```

What you should see is a `*blob.Bucket` regardless of which scheme you passed. Swap `s3://my-bucket` for a `gs://` or `azblob://` URL and the surrounding code does not change, provided the corresponding driver package is imported somewhere in the build. That import is what registers the scheme, so a URL with no matching driver fails at open time rather than at compile time.

The repository also ships runnable examples under samples/, including samples/gocdk-blob/, samples/gocdk-pubsub/, samples/gocdk-docstore/ and samples/gocdk-runtimevar/. Those directories are the fastest way to see a complete program, including the driver imports that the README snippet omits.

## Where the portable interface costs you

The Go CDK exposes the intersection of what its drivers can do, not the union. Anything a single provider offers and the others do not has no place in the interface, so you either drop it or reach past the abstraction and use the provider SDK directly. Once you do that, the portability argument for that code path is gone.

Optional interfaces soften this but do not remove it. A driver may implement additional methods beyond the core interface, and code that type-asserts for them becomes provider-specific again, silently. The failure mode is quiet: a type assertion that fails returns the zero value and a false, and if that error is ignored the program keeps running with degraded behaviour.

The project's own status statement is the other constraint. The README says "The APIs are still in alpha", while also saying the maintainers think they are production-ready. Both can be true, but alpha means the interface may change between releases. The release cadence visible in the repository is roughly quarterly, with v0.46.0 in June 2026, v0.45.0 in March 2026 and v0.44.0 in December 2025, and the version numbers are still below 1.0. Anyone pinning to a minor version should expect to read release notes before upgrading.

Scope is deliberately closed as well. The README states that the project prefers to focus on maintaining existing APIs and drivers and is unlikely to accept new ones into the repository, suggesting external repositories instead. The only external driver the README lists is gocloud-ext, which provides `blob` drivers for HTTP and WebDAV (`httpblob`) and for SFTP (`sftpblob`). If your storage backend is not one of the built-in drivers, you are writing the driver yourself.

## How it compares with writing against each provider SDK

The realistic alternative is not another portability library; it is using the AWS SDK for Go v2, the Azure SDK for Go and the Google Cloud client libraries directly, behind an internal interface your team defines. That approach costs more code but gives you the complete feature set of each provider, including the parts the Go CDK does not model.

The difference is where the abstraction lives. With the Go CDK the interface is maintained upstream, tested against every driver, and shared with other users, so a bug in the S3 driver is fixed once. With a homegrown interface you own the mapping for every provider and every feature, and the interface tends to grow toward whichever provider you wrote first. The Go CDK's constraint is also its benefit: because the interface cannot grow to fit one provider, it stays portable.

A middle path is to use the Go CDK for the commodity layers (blob, secrets, runtimevar) and the provider SDKs for anything distinctive. The URL openers make that easy to mix, since a `blob.Bucket` and a hand-built S3 client can coexist in the same process.

## Maintenance, licensing and upgrade cost

The repository is not archived and the last push was on 2026-09-21. Releases arrive on a quarterly-ish rhythm, and the module is published as gocloud.dev on pkg.go.dev. Because the APIs are declared alpha, the practical upgrade cost is the interface surface you actually use: the fewer portable APIs a service touches, the smaller the diff when a release changes one.

The go.mod file is large. It requires the AWS SDK for Go v2 modules, Azure SDK modules including azcore, azidentity, azblob and azservicebus, and Google Cloud packages for storage, pubsub, firestore, kms, secretmanager and iam, among others. That dependency graph is the thing Wire is meant to keep out of your binary, but it still affects your module graph and your vulnerability scanning.

The licence is Apache-2.0, the same permissive licence used by the Go project itself, which permits commercial and closed-source use and requires preserving notices. That is a description of the licence text, not legal advice; if your organisation has a policy on dependency licences, run it through that policy.

## What to check before committing to the Go CDK

Read the package reference for the specific API and driver you plan to use, not just the README example. The README shows blob storage; the other APIs have their own interfaces and their own gaps, and the driver matrix is what determines whether your target cloud is covered.

Check which optional interfaces your chosen driver implements, and decide up front whether your code is allowed to type-assert for them. If it is, document which drivers are expected to satisfy the assertion, because that is where portability quietly ends.

Confirm your Go toolchain. The module targets `go 1.26.0`, and the README states that older versions may compile but are not supported. Then look at samples/ for a program close to what you are building; the driver import lines there are the part the README snippet leaves out.

## Conclusion

Adopt google/go-cloud if your Go service already needs to run on more than one cloud, or if you want a local test implementation of blob storage and pub/sub behind the same interface as production. Do not adopt it if you depend on provider-specific features that the portable APIs do not expose, or if you need a stable, non-alpha API surface. Before writing code, read the package reference for the driver you intend to use and check which optional interfaces it implements, because the portable interface is the contract and each driver may support only part of it.

## FAQ

### What is google/go-cloud?

It is the Go Cloud Development Kit, a Go library that provides stable, idiomatic interfaces for common cloud uses such as blob storage, pub/sub, runtime variables, document storage, secrets and SQL connections. The README describes the goal as letting you write once and run on any cloud.

### How do I install google/go-cloud?

The README gives a single command, `go get gocloud.dev`, run from inside your project directory so that module mode behaves as expected. The project builds at the latest stable release of Go, and the module declares go 1.26.0.

### Is google/go-cloud a native cloud service?

No. It is a Go library and set of tools that sits in front of cloud provider SDKs, with driver packages for AWS, Google Cloud and Azure. It does not host anything itself; it calls the providers you configure through URLs such as s3://my-bucket.

## Sources

- [google/go-cloud on GitHub](https://github.com/google/go-cloud)
- [License: Apache-2.0](https://github.com/google/go-cloud/blob/master/LICENSE)
- [Project website](https://gocloud.dev/)
- [README](https://github.com/google/go-cloud/blob/master/README.md)
- [Releases](https://github.com/google/go-cloud/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/google-go-cloud