# Go-Spring: an IoC and configuration runtime for Go that wires other people's frameworks

> Go-Spring is an Apache-2.0 IoC container, layered config engine and lifecycle layer for Go, with 70+ Starters that wrap Gin, gRPC, Redis, Kafka, dubbo-go, Kitex, Kratos and go-zero. It owns no transport, and that is the whole argument.

**go-spring/go-spring** — [released] IoC IDLs-First Go ( All-in-One Development Framework on IoC and IDLs-First for Go ).

- Repository: https://github.com/go-spring/go-spring
- Stars: 1,804 · Forks: 233
- Language: Go
- License: Apache-2.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/go-spring-go-spring

## The gap Go-Spring claims: assembly, not transport

The README states the problem plainly: Go's standard library is complete at the runtime level and deliberately minimal at the application level. There is no dependency-injection model, no layered-configuration convention, no starter-style auto-configuration, no unified lifecycle or governance layer. Java fills that with Spring. Go-Spring's stated mission is to fill the same seat for Go.

The target reader is not someone writing a first Go service. It is a team already running Gin for HTTP, gRPC for internal calls, Redis and MySQL for state, and possibly dubbo-go or Kitex for RPC, who now maintains four or five configuration formats and no shared place to set a timeout. Go-Spring positions itself as the layer beneath those choices rather than a replacement for any of them. The README is explicit that it "competes with nothing in your stack; it assembles your stack."

That framing is the project's strongest claim and its biggest risk. A framework that owns nothing is only as useful as the Starters it ships, and 70+ Starters is a lot of surface area to keep aligned with upstream SDK releases.

## How the container, config engine and Starters fit together

The repository is split into strictly ordered layers, and the README says dependencies flow one way, downward. Foundation holds stdlib and log: zero-dependency utilities plus a structured logging engine. Core is the spring module, which contains the IoC container, DI, the layered config engine and application lifecycle, and nothing else. The cloud module is the ecosystem abstraction library: governance center, discovery, cache, repository, i18n and validation, and it imports no spring package. Above that sit the Starters, which pair a third-party SDK with gs wiring. Tooling is the gs CLI, gs-http-gen and gs-mock.

The rule the README gives for keeping this clean is short: abstractions go in cloud, third-party SDKs and gs wiring go in a starter, pure semantics with no ecosystem dependency go in stdlib. A starter wires, cloud abstracts, spring runs.

Configuration is the part with the most concrete mechanism. The README describes one layered engine reading CLI arguments, environment variables, files, then Nacos, etcd, Consul, Vault or Kubernetes, with gs.Dync[T] for hot reload. Governance is centralized: timeout, retry, breaker and rate-limit plus fault injection are applied uniformly across Redis, GORM, HTTP, gRPC, gin and dubbo from a single ${govern} config, with pluggable rule sources including file, an HTTP console, or direct listeners on nacos and etcd.

That is the architectural bet. Instead of each component carrying its own retry settings, one config block governs all of them. It is elegant when it works and it means the governance center becomes a dependency you cannot easily remove later.

## Where the modules live and how a component gets wired

The README does not give a step-by-step install walkthrough, so the entry points are the repository's own layout: the spring module for the container, the gs CLI under gs/gs for tooling, and the layout/ and contrib/ directories for project scaffolds and templates. Module paths and versions should be taken from versions.yaml and each module's own go.mod rather than guessed. The README does not print a go get line, so there is no install command to copy here; the authoritative reference is the module file inside the directory you want.

A Starter follows the same pattern. If you are wiring Gin, the corresponding starter module under starter/ is what you add; the README lists Gin, gRPC, Redis, MySQL, Kafka, Dubbo and Kitex as examples of the 70+ Starters.

The documented integration mechanism is gs.Module. The README says dubbo-go, Kitex, Kratos, go-zero, GoFrame, gRPC, tRPC and Thrift each appear as one Starter among 70, integrated by the same gs.Module mechanism as Redis or MySQL. What a reader should expect after wiring a module is that the component's configuration comes from the layered engine rather than from a hand-built struct, and that governance settings for it come from the ${govern} block.

Before writing application code, check ARCHITECTURE.md. The README points there for the full module inventory and the architecture constraints, and those constraints are what tell you which layer a given import belongs to.

## Where Go-Spring is the wrong tool

The honest limitation is the one the README's own comparison table hints at. Go-Spring owns no protocol and no transport. If your problem is service-to-service calls and you want a framework that decides your transport, your service model and your code generation in one opinionated package, Kratos or go-zero give you that in a single decision. Go-Spring gives you a container and a config engine and then asks you to pick the transport separately. That is more freedom and more assembly work.

The second limitation is conceptual weight. The README frames the project around two decades of Java Spring paradigms and names dependency injection, auto-configuration and the Starter mechanism as the things being reimagined. Teams that left Java partly to escape that model will find the vocabulary familiar in a way they may not want. A plain Wire or fx setup has a much smaller surface to learn.

The third is scope creep in the project's own stated direction. The README describes Process as Code, treating the development process itself as an assemblable, reusable, versionable application, and calls it "a bold direction, and a hypothesis worth testing." That is the project's own words, and it is a signal about where maintainer attention may go. If you adopt Go-Spring for the container and the config engine, you are adopting a project whose stated ambitions extend well past that.

Finally, the release history is uneven. v1.1.3 landed on 2022-10-12, and the next listed release, v1.3.0, arrived on 2026-05-04. That is a long quiet stretch between the 1.1 and 1.3 lines, and anyone pinning an old version should read the changelog between them rather than assume a drop-in upgrade.

## Go-Spring against Wire, fx and dig

The README's own comparison puts Wire, fx and dig in the DI-library column and says they "solve injection only: no config engine, no starter model, no lifecycle or governance. Parts, not an ecosystem."

The difference in approach is real. Wire generates injection code at build time, so the wiring is visible in generated Go source and carries no runtime container. fx and dig build a runtime graph with lifecycle hooks. Go-Spring builds a runtime container plus a layered configuration engine plus a governance layer, and it expects components to arrive through Starters rather than through hand-written providers.

If your only problem is that constructors take too many arguments, Go-Spring is heavier than you need. The container is the smallest part of it. The value appears when the configuration engine and the governance center are doing work that would otherwise be duplicated per component: one place to define a timeout that applies to Redis, GORM, HTTP and gRPC at once.

The README points to spring/README.md for the fuller DI-framework comparison, which is where a reader should go before deciding between a generator like Wire and a runtime container.

## Licence, maintenance and upgrade cost

Go-Spring is Apache-2.0. That is a permissive licence with an explicit patent grant, and it is compatible with the third-party SDKs the Starters wrap in the ordinary case. It does not remove the obligation to check the licences of those upstream SDKs, since a Starter is a thin layer over someone else's code and your dependency tree inherits theirs. This is not legal advice; the LICENSE file in the repository root is the authoritative text.

The repository is not archived, and the last push was on 2026-06-23, which is the same date as the v1.3.2 release. Before that, v1.3.0 was released on 2026-05-04, and v1.1.3 on 2022-10-12. So the recent cadence is two releases within roughly seven weeks, following a gap of more than three years from the 1.1 line.

Upgrade cost is dominated by the Starters, not the core. The core container and config engine are one module, and the README describes cloud as importing no spring package, which limits how far a core change can ripple. But 70+ Starters each track an upstream SDK, and an upstream major version can force a starter major version. Budget for reading release notes per starter you depend on. The versions.yaml file at the repository root is the place to check what the project itself considers the current set.

## Conclusion

Go-Spring fits teams running several Go frameworks at once who want one configuration and governance layer under all of them, and who accept a Spring-shaped mental model. It is the wrong choice if you want a small DI library with no configuration engine, or if you have already committed to Kratos or go-zero and are happy inside that framework's own config, layout and codegen. Before adopting, read ARCHITECTURE.md and confirm which Starters you actually need, check the v1.3.2 changelog for the modules you will import, and decide whether the ${govern} governance center is something you will configure or something you will carry.

## FAQ

### What is a good Go-Spring alternative?

The README positions Wire, fx and dig as DI libraries that solve injection only, without a config engine, starter model, lifecycle or governance. It also names Kratos and go-zero as framework-centric ecosystems, which it describes as excellent but orbiting their own framework. Which one replaces Go-Spring depends on whether you want injection alone or a whole application platform.

### Is Go-Spring another Go RPC framework like dubbo-go or Kitex?

No. The README states Go-Spring owns no protocol and no transport, and describes itself as the assembly and runtime layer beneath and beside such frameworks. In the repository, dubbo-go, Kitex, Kratos, go-zero, GoFrame, gRPC, tRPC and Thrift each appear as one Starter among 70, integrated by the same gs.Module mechanism as Redis or MySQL.

### What does Go-Spring use for dependency injection and configuration in Go?

The core spring module holds the IoC container, DI, the layered config engine and application lifecycle. The config engine reads CLI arguments, environment variables, files, and then Nacos, etcd, Consul, Vault or Kubernetes, with gs.Dync[T] for hot reload.

### Is Go-Spring actively maintained?

The repository is not archived and the last push was on 2026-06-23, the same date as the v1.3.2 release. The release history before that is uneven: v1.3.0 was released on 2026-05-04, while v1.1.3 dates to 2022-10-12.

## Sources

- [Official README](https://github.com/go-spring/go-spring#readme)
- [Project repository](https://github.com/go-spring/go-spring)
- [Release notes](https://github.com/go-spring/go-spring/releases)

---

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