MinIO — Dependencies#

Module info#

• Module: github.com/minio/minio
• Go version: 1.24.0 (toolchain go1.24.8)
• Direct dependencies: 95 (first require block, excluding // indirect entries)
• Indirect dependencies: 164 additional entries in go.mod; 355 unique modules in go.sum (879 lines total — each module appears twice: hash + go.mod hash)

Dependency categories#

Core infrastructure#

Networking/HTTP#

Data/Storage#

Authentication/Security#

Cloud provider clients (tiering/gateway)#

Event notification targets#

MinIO supports forwarding object events to 7+ external systems — all are direct dependencies, not optional plugins:

Distributed coordination#

Observability#

Protocols (FTP/SFTP)#

Testing#

No dedicated test frameworks appear as direct dependencies. testify, gomock, and similar are pulled in only as transitive/indirect dependencies via minio-go and madmin-go.

Other notable#

Stdlib reliance#

MinIO is a heavy stdlib user. Across the cmd/ package (453 files), the most-used stdlib packages are:

Notably, net/http is used directly for both client and server — MinIO builds its own HTTP handler stack on top of stdlib rather than delegating to a full framework. context ubiquity reflects MinIO’s thorough propagation of cancellation and deadline through all I/O paths. encoding/json is supplemented (not replaced) by json-iterator/go and simdjson-go on hot paths.

Shared dependencies#

These direct dependencies are commonly shared across many projects in the 50-project corpus, making them connection points for cross-project comparison:

Vendoring#

No vendor directory. MinIO uses the Go module proxy for dependency resolution. This is appropriate for a server application with many direct dependencies — the module cache provides reproducibility. The absence of vendoring is a conscious tradeoff: the source tree stays smaller and dependency updates are simpler, at the cost of requiring internet access (or a proxy) to build from scratch.

Notable dependency decisions#

1. The klauspost ecosystem is a dependency core. Klaus Post’s libraries — reedsolomon, compress, pgzip, readahead, cpuid, filepathx — are woven throughout MinIO’s hot paths. He is both an external dependency author and a MinIO core contributor. This creates an unusually tight coupling between MinIO and a single contributor’s library suite, but that coupling is justified by the consistent SIMD-optimization philosophy and the co-evolution of the libraries.

2. MinIO forks its own critical dependencies. Rather than using gorilla/mux, MinIO maintains minio/mux. Rather than urfave/cli, they maintain minio/cli. Rather than any upstream XML parser, they wrote minio/xxml. This pattern of controlled forking for performance-critical paths is a hallmark of the project’s “own the critical path” philosophy.

3. Event targets are always compiled in — no plugin model. All 9 notification target systems (Kafka, MQTT, Elasticsearch, MySQL, PostgreSQL, Redis, NATS, NSQ, RabbitMQ) are unconditional direct dependencies. MinIO chose compile-time inclusion over runtime plugins, trading binary size and build time for operational simplicity: no plugin loading, no ABI stability concerns.

4. Both yaml.v2 and yaml.v3 coexist. This is a legacy artifact — MinIO is a large, multi-year project that hasn’t fully migrated its YAML code. Seeing both versions in go.mod is a common pattern in mature Go projects and speaks to the cost of large-scale internal migrations.

5. Self-reliance via minio/ sub-projects.* MinIO depends on minio-go/v7 (its own S3 client), madmin-go/v3 (its own admin client), minio/pkg/v3 (shared utilities), and minio/console (the web UI). The project is effectively a mini-ecosystem, and the server binary consumes its own public APIs. This creates a useful dogfooding dynamic but also tight version coupling within the MinIO GitHub organization.

6. No DI framework. With 95 direct dependencies, the absence of uber/dig, uber/fx, or google/wire is notable. MinIO uses manual constructor-based wiring throughout — consistent with its single-package cmd/ architecture where all components are co-located and wired in initialization functions.

7. etcd appears but is not central. etcd client is a direct dep for DNS-based service discovery in some deployment modes, but MinIO’s primary distributed coordination uses its own internal/dsync (quorum-based distributed RWMutex) and internal/grid (custom WebSocket RPC). etcd is optional infrastructure, not the coordination backbone.