Component Versions

Verified on 2026-09-13. SILO releases its four components independently. A merged dependency update does not change an existing binary or image.

Published components

Release notes: Server 20260903, Console v2.4.0, mcli 20260913, pkg v3.14.0. The published Server image still bundles its original client and Console. Installing a standalone update does not replace those embedded components. Package-repository mirrors may lag GitHub; the download page links directly to the published artifacts.

Coordinated source on main

The September 13 refresh landed as pkg #7, MC #42, Console #53 and #54, and Server #181.

• pkg: v3.14.0 → 827f8109ff11bf6239a35d8d6d137cb5738539c3.
• MC: v0.0.0-20260913012246-4f609a4da3bb → the published 20260913 tag.
• Console selected by Server: v0.0.0-20260913015128-417559bb2c97; accepted on main by merge 449c185a8d14 with the same tree.
• Server integration: 5d955b5b7444f8a3ab550ce92713607998f89c0d.
• Upstream minio-go: v7.3.1-0.20260910142817-60bd07042d49.

Server and Console changes after their latest tags remain unreleased. This includes the password-permission split, Console streaming ZIP downloads and its revised image-promotion gate, and Server’s later storage, replication and signed-header fixes. Server main now builds curl 8.22.0 and bundles mcli 20260913; existing Server images retain their published contents. The Server changelog and Console changelog separate those changes from published releases.

The latest published Server is affected by SN-2026-011. Its fix is on main; upgrading only pkg, mcli or standalone Console does not patch an installed Server. Source validation and vulnerability scans do not establish that a fixed Server binary has been published.

Dependency and release order

1. Verify the upstream SDK commit and required fixes. Keep the upstream github.com/minio/minio-go/v7 path; the retired silo-go fork is not part of the maintained graph.
2. Validate and publish pkg under github.com/pgsty/silo-pkg/v3, including its migration notes. Resolve the tag through the Go proxy and checksum database.
3. Update MC to that pkg and SDK, validate it, then publish the calendar-tagged mcli release. Go consumers select its canonical pseudo-version.
4. Update Console’s direct pkg requirement and explicit MC replacement, validate its embedded frontend and integration, and publish Console when a release is intended. An accepted immutable source commit can also be selected explicitly.
5. Update Server’s direct pkg/SDK requirements and both PGSTY replacements, client archive hashes, image and Helm client pins. Validate the complete graph before a separate Server release, image publication and cluster rollout.

Go does not inherit a dependency module’s replace directives. Server must explicitly select both maintained Console and MC even when Console already selects MC. Console and MC retain their historical MinIO module paths; pkg uses its own path directly. Legacy transitive minio/pkg/v3 from colorjson/dperf is separate from the maintained policy implementation.

The main stack uses Go 1.27.1; pkg retains a Go 1.26 library floor and was also race-tested with Go 1.26.8. The Go x/* dependencies were refreshed. The effective go-systemd version stays v22.6.0 because v22.7.0 fails to compile on NetBSD; Console’s tablewriter v0.0.5 replacement preserves its MC API. These are documented compatibility pins, not missed automatic upgrades.

Other dependencies change for concrete CVE/bug fixes, not just newer major versions. The September 13 Go scans found no reachable or imported vulnerable package, but retained module-only GO-2026-5932 in unused OpenPGP code. A clean reachability result is not a claim that every selected module is advisory-free.

The supported integration target is the coordinated PGSTY stack. Compatibility with unmodified upstream MinIO/MC and other S3 implementations is best effort.