Feng Ruohang
77bdc4c0cd
Two coupled changes that must land together, because the same files carry both: the server now identifies itself as Silo, and every path that would have called home to a MinIO-operated service is closed. Product identity - build-constants.go: store name, UA name and startup banner become Silo. The Go identifiers (MinioStoreName, MinioBannerName, ...) keep their names on purpose - renaming exported symbols would churn the compatibility surface for a cosmetic gain, and the rebrand guard freezes that surface. - main.go, server-startup-msg.go, ftp-server.go and the user-visible log, help and error strings across cmd/ and internal/ switch to Silo. Original MinIO copyright, LICENSE, NOTICE and CREDITS are untouched; --version now prints the upstream copyright, the pgsty modification notice, and the trademark policy's approved "based on MinIO technology" attribution. - api-headers.go: the HTTP Server header becomes "Silo". This is the one externally observable identity change, so TestCommonHeadersUseSiloProductName pins it - probes that sniff for "MinIO" must move to capability detection. - Prometheus metric HELP strings keep their MinIO wording. They are part of the metrics contract the guard protects, not product copy. Configuration directory - config-dir.go: new installs use ~/.silo. If only ~/.minio exists it is still read, with a one-time notice and no files moved. If both exist ~/.silo wins and an ambiguity warning is emitted; an explicit --config-dir always wins. Covered by TestSelectDefaultConfigDir. The internal .minio.sys layout is never renamed - this rule applies to the user config directory only. Upstream service lockdown - globalInplaceUpdateDisabled is now true at initialization rather than being set from MINIO_UPDATE. common-main.go still parses MINIO_UPDATE so upgrading nodes do not fail on an unknown key, but warns that the value is ignored; there is no way to re-enable the updater. TestInplaceUpdateCannotBeEnabled guards that. Without this, an admin with mc could have overwritten /usr/bin/silo with an upstream MinIO binary. - verifyBinary and commitBinary refuse early; the ServerUpdate v1/v2 admin routes and the peer-rest update endpoints stay registered and keep returning the existing programmatic error, so clients see a stable failure rather than a 404. - MinioReleaseBaseURL and defaultMinisignPubkey are emptied: no dl.min.io download root, and upstream's minisign key is no longer a trust root for anything this fork ships. - cmd/callhome.go is deleted and internal/config/subnet/ is reduced to parsing its old keys and reporting that the integration is disabled. config-current.go warns instead of failing when callhome or SUBNET settings are present, so an upgraded node with those keys still starts. - internal/config/errors.go replaces the MinIO Slack and support entry points with Silo documentation and issue links. Error codes and programmatic fields are unchanged. Verified: the compatibility baseline is unchanged except for the deliberate removal of the /api/health/upload SUBNET route; go build, go vet and the full cmd/ and internal/ unit suites pass; a locally built binary starts, serves S3/Admin/metrics on the unchanged /minio/* routes, answers with Server: Silo, and falls back to a pre-existing ~/.minio with the expected notice. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A conservatively maintained MinIO fork
Security maintenance, versioned release artifacts, and operational continuity for existing deployments.
Website · Documentation · Download · Blog · Releases · Security · 中文
Important
Silo is an independent, community-maintained fork of the open-source MinIO server, published by Pigsty from
pgsty/minio. It is not affiliated with, endorsed by, or sponsored by MinIO, Inc. “MinIO” is used only to identify the upstream project and compatibility lineage.
Overview
Silo maintains one downstream release line based on MinIO RELEASE.2025-12-03T12-00-00Z. It provides maintained builds and release artifacts for existing MinIO-compatible deployments after upstream community distribution ended. Pigsty uses this fork for object storage as an optional PG backup repo.
The official project portal is silo.pgsty.com. It brings documentation, downloads, release and security notes, and project background together. English is served at the site root; Chinese is available under /zh/.
Find the Right Resource
| Looking for | Canonical location |
|---|---|
| Project overview and navigation | Silo Website (中文) |
| Installation methods and downloads | Download & Install (中文) |
| Operations, administration, development, and reference | Documentation (中文) |
| Project news, release notes, and security notes | Blog, including releases and security |
| Versioned binaries, checksums, and source archives | GitHub Releases |
| Bug reports and feature discussions | GitHub Issues |
| License, attribution, and trademark information | License, Attribution, and Trademark |
Maintenance Policy
The active release line covers:
- build and dependency maintenance;
- applicable security fixes and advisories;
- focused fixes for reproducible defects;
- versioned binaries, packages, checksums, and multi-architecture images;
- the web console, client, documentation, and Pigsty integration.
Changes are kept narrow and tested where practical. Maintenance is best effort; no response, remediation, or release schedule is guaranteed.
Out of scope
- a separate product roadmap, new storage engine, or speculative S3 features;
- broad rewrites or changes that materially expand the downstream delta;
- historical releases or multiple support branches;
- commercial support, SLAs, 24×7 coverage, or SUBNET access;
- deployment design, access control, monitoring, backup, or recovery.
Compatibility
Silo aims to preserve:
- MinIO-compatible S3 APIs, configuration, environment variables, and CLI conventions;
RELEASE.YYYY-MM-DDTHH-MM-SSZtags, container entrypoints, and common deployment workflows.
Compatibility is the default constraint. Silo preserves existing wire, client, configuration, and operational behavior whenever doing so remains safe. Compatibility is broken only when necessary to close a major security issue, and the release notes must identify the affected behavior and migration path. Treat each release as a downstream upgrade: pin versions, review release notes and security advisories, keep a rollback path, and test before production use.
Downloads and Release Artifacts
Use Download & Install to choose an installation method. GitHub Releases remains the source for versioned server binaries, checksums, and source archives.
| Artifact | Location |
|---|---|
| Source | github.com/pgsty/minio |
| Container image | pgsty/minio, multi-arch for linux/amd64 and linux/arm64 |
| Server binaries and checksums | GitHub Releases for Linux, macOS, and Windows on amd64 and arm64 |
| Linux packages | RPM, DEB, and APK artifacts, also distributed through the Pigsty repository |
| Client | pgsty/mc, bundled in the container as mcli with an mc compatibility alias |
| Console | Maintained georgmangold/console fork, embedded in the server build |
| Shared library | pgsty/silo-pkg v3.7.0, consumed through a replace directive while preserving github.com/minio/pkg/v3 import paths (release notes) |
Quick Start
For local evaluation:
mkdir -p data
export MINIO_ROOT_USER=minioadmin
export MINIO_ROOT_PASSWORD=change-me-long-password
docker run -d --name silo \
-p 9000:9000 \
-p 9001:9001 \
-e MINIO_ROOT_USER \
-e MINIO_ROOT_PASSWORD \
-v "$PWD/data:/data" \
pgsty/minio:latest server /data --console-address ":9001"
Open the console at http://localhost:9001; the S3 API listens on http://localhost:9000.
The image includes the compatible client as mcli:
docker exec silo mcli alias set local http://127.0.0.1:9000 \
"$MINIO_ROOT_USER" "$MINIO_ROOT_PASSWORD"
docker exec silo mcli mb local/demo
docker exec silo mcli ls local
Warning
For production, pin a release, use unique credentials and TLS, monitor the service, keep independent backups, and test recovery.
Build the server from source:
go build -o minio .
./minio --version
For other installation paths—including native packages, binaries, Podman, Kubernetes, source, and Pigsty Ansible—use Download & Install. For production deployment and administration, start with the Silo documentation. Pigsty users can also use the Pigsty MinIO module.
Security
Security fixes target the active master branch and are recorded in the advisory log and the portal's security notes. Report vulnerabilities privately as described in SECURITY.md and VULNERABILITY_REPORT.md. Report issues that also affect upstream MinIO there as well.
Contributing
Useful contributions include security and dependency updates, reproducible bug fixes, tests, release automation, packaging, and documentation.
Issues and pull requests should include the affected version, reproduction steps, impact, expected behavior, tests, and compatibility notes. Discuss large changes in an issue first.
Background
This project was created in response to changes in the upstream community distribution and maintenance model. The maintainer’s analysis, alternatives considered, and early maintenance record are documented below:
| Essay | Subject |
|---|---|
| MinIO Is Dead | Changes to the upstream project and distribution model |
| MinIO Is Dead, Long Live MinIO | Establishing the fork and its release pipeline |
| Two months into maintaining a MinIO fork | Initial security and maintenance work |
License and Trademark
The server remains licensed under the GNU Affero General Public License v3.0. See CREDITS for upstream authorship and attribution. MinIO is a trademark of MinIO, Inc. Silo and pgsty/minio are independent community efforts and are not affiliated with or endorsed by MinIO, Inc.