google/go-cloud

The Go Cloud Development Kit (Go CDK): A library and tools for open cloud development in Go.

View on GitHub ↗Jump to charts ↓Open shareable report

Summary Information

Updated 20 minutes ago
Added to GitGenius on September 6th, 2026
Created on March 21st, 2018
Open Issues & Pull Requests: 3 (+0)
GitHub issues: Enabled
Number of forks: 854
Total Stargazers: 9,912 (+0)
Total Subscribers: 215 (+0)

Repository Insights (GitGenius)

Median issue/PR response: 7.6 hours
Mean response time: 8.2 days
90th percentile: 5.6 days
Tracked items: 68

How this project is maintained

Around half of the issues opened in the past year never receive a reply. Only 18% of issues opened in the past year have been closed. Three people close 90% of everything that gets resolved.

Charts & Analytics

Fetching additional details & charts...

Issue Activity (beta)

Open issues: 1
New in 7 days: 0
Closed in 7 days: 0
Avg open age: 174 days
Stale 30+ days: 1
Stale 90+ days: 1

Recent activity

Opened in 7 days: 0
Closed in 7 days: 0
Comments in 7 days: 0
Events in 7 days: 0

Top labels

  • needs info (1)

Most active issues this week

No issue events were indexed in the last 7 days.

Detailed Description

Go Cloud Development Kit is a library that provides cloud-agnostic interfaces for Go applications to seamlessly work across multiple cloud providers.

The tool solves the problem of cloud vendor lock-in and the complexity of writing cloud-portable code. Rather than forcing developers to learn and use provider-specific SDKs for each cloud service, Go CDK offers stable, idiomatic interfaces modeled after Go's standard library patterns like database/sql. This allows the same code to run on any cloud without modification. The approach works by providing generic APIs for common cloud operations such as blob storage, publish/subscribe messaging, runtime variables, document storage, secrets management, and relational databases, while delegating the actual cloud-specific implementation details to pluggable drivers.

Developers should adopt this tool if they need to build applications that run across multiple cloud providers or want to avoid being locked into a single cloud vendor's ecosystem. It suits projects ranging from small applications to large enterprise systems that may need flexibility in deployment targets. The project explicitly states that it prefers to focus on maintaining existing APIs and drivers rather than accepting new ones into the main repository, suggesting that external drivers for additional services should be hosted separately.

The project maintains its core APIs in alpha status while considering them production-ready and actively soliciting feedback from early adopters. Development focuses on stability of existing interfaces and drivers rather than rapid expansion of the API surface. The modular architecture is intentional, allowing new APIs and drivers to be developed externally without bloating the main repository or affecting compile times and binary sizes for users who only need specific cloud services.