S3-compatible object storage — a MinIO fork maintained by PIGSTY

Website · Documentation · Download · Release Notes · Compatibility · Security · 中文

Important

Silo is an independent, community-maintained fork of the open-source MinIO server, published by Pigsty from pgsty/silo. It is not affiliated with, endorsed by, or sponsored by MinIO, Inc. “MinIO” is used only to identify the upstream project and compatibility lineage.

Note

This repository was renamed from pgsty/minio to pgsty/silo, and its default branch from master to main, on 2026-08-06. If you need the artifacts maintained under the original MinIO identity, they are on the archived minio branch and in the releases up to RELEASE.2026-08-04T00-00-00Z; those assets and the docker.io/pgsty/minio image stay published and unmodified. The rename changed product and artifact names only — MINIO_* variables, minio_* metrics, x-minio-* headers, /minio/* routes, and the on-disk format are unchanged.

Overview

Silo maintains one downstream release line derived from the open-source MinIO server. It provides maintained builds and release artifacts for existing MinIO-compatible deployments after upstream community distribution ended. Pigsty uses Silo for object storage, including as an optional PostgreSQL backup repository.

The fork follows one rule: the product and its delivery surfaces are renamed; the protocol and your data are not. The silo executable, packages, service, and container image carry the new name, while the S3 API, MINIO_* variables, minio_* metrics, x-minio-* headers, reserved routes, and the on-disk format stay unchanged. The differences are recorded in the compatibility notes.

The official project portal is silo.pgsty.com. It brings documentation, downloads, release and security notes, and project background together.

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
Release notes for this server	Silo release notes
Differences from upstream MinIO	Silo vs. MinIO compatibility notes
Project news and security advisories	Blog · release and security notes
Versioned binaries, checksums, and source archives	GitHub Releases
Bug reports and feature discussions	GitHub Issues
Vulnerability reporting	SECURITY.md and VULNERABILITY_REPORT.md
License, attribution, and trademark information	LICENSE · NOTICE · CREDITS · portal license, attribution, and trademark pages

Related Projects

Repository	Description
pgsty/silo	This repository — the Silo object storage server, an S3-compatible MinIO fork
pgsty/mc	The Silo command-line client, shipped as mcli with the mc command name
pgsty/silo-console	Admin web console, embedded in the server build
pgsty/silo-pkg	Shared Go packages maintained for the Silo forks
pgsty/pigsty	Pigsty — the PostgreSQL distribution that ships Silo as its object storage

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.

Governance

The server, client, console, and shared packages are maintained under one release process: DCO-signed commits, reviewed pull requests, and versioned RELEASE.YYYY-MM-DDTHH-MM-SSZ tags whose artifacts ship with checksums, SPDX SBOMs, Sigstore-signed manifests, and GitHub build attestations. Each release is announced with a release note on the portal; security handling follows SECURITY.md and the advisory log. Upstream copyright, license, and third-party notices are preserved in LICENSE, NOTICE, and CREDITS.

Compatibility

Silo aims to preserve:

• the github.com/minio/minio module path and github.com/minio/* import paths;
• MinIO-compatible S3 APIs, wire behavior, MINIO_* environment variables, metrics, protocol headers, reserved routes, and storage metadata;
• RELEASE.YYYY-MM-DDTHH-MM-SSZ tags and legacy minio … container argv translation.

Silo-owned delivery surfaces use the silo executable, package, service, Helm chart, and pgsty/silo container image. Native artifacts intentionally do not install a minio binary alias.

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 the release notes, compatibility 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/silo
Container image	pgsty/silo, 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	pgsty/silo-console, embedded through the compatibility import path github.com/minio/console
Shared library	pgsty/silo-pkg v3.11.0, consumed through a replace directive while preserving the github.com/minio/pkg/v3 import path

Each new release publishes per-archive and per-package SPDX JSON SBOMs. The archive and package checksum manifests have detached keyless Sigstore bundles, while GitHub artifact attestations record signed provenance for every downloadable artifact and the multi-architecture container image.

After downloading an archive and its release files, verify integrity, the published SBOM, the signed manifest, and build provenance independently:

# Integrity: choose the line for the artifact you downloaded.
grep -F '  silo_<version>_linux_amd64.tar.gz' \
  silo_<version>_checksums.txt | sha256sum --check

# The archive SBOM is a separate checksummed release artifact.
grep -F '  silo_<version>_linux_amd64.tar.gz.sbom.json' \
  silo_<version>_checksums.txt | sha256sum --check

# Signature over the archive/SBOM checksum manifest.
cosign verify-blob \
  --bundle silo_<version>_checksums.txt.sigstore.json \
  --certificate-identity-regexp \
    '^https://github.com/pgsty/(minio|silo)/\.github/workflows/release\.yml@refs/(tags/RELEASE\..+|heads/(master|main))$' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  silo_<version>_checksums.txt

# Signed build provenance (online verification against this repository).
gh attestation verify silo_<version>_linux_amd64.tar.gz \
  --repo pgsty/silo

For packages, use silo_<version>_packages_checksums.txt and its adjacent Sigstore bundle with the same identity and issuer constraints. Inspect the verified SPDX JSON SBOM with your preferred SPDX tooling. Verify the multi-architecture container provenance by digest:

gh attestation verify \
  oci://index.docker.io/pgsty/silo@sha256:<manifest-digest> \
  --repo pgsty/silo

The platform SBOM attestations are attached to the amd64 and arm64 image digests rather than the multi-architecture manifest. Verify each one explicitly:

gh attestation verify \
  oci://index.docker.io/pgsty/silo@sha256:<platform-digest> \
  --repo pgsty/silo \
  --predicate-type https://spdx.dev/Document/v2.3

Verification by digest avoids trusting a mutable image tag.

Native package migration

The silo RPM, DEB, and APK do not declare Provides, Obsoletes, Replaces, or package-level Conflicts against minio. They can therefore be installed beside an existing MinIO package without silently replacing it. The two systemd units conflict at runtime, so switch them explicitly rather than starting both.

Before switching, record the old unit's enabled/active state and User/Group, and back up /etc/default/minio. Silo reads that legacy defaults file first and then /etc/default/silo; administrator-set values in the latter take precedence. If the existing data must continue to run under its original UID/GID, create /etc/systemd/system/silo.service.d/10-legacy-user.conf:

[Service]
User=<legacy-user>
Group=<legacy-group>

Run systemctl daemon-reload, then disable and stop minio.service before enabling and starting silo.service. Verify health, S3, Admin API, metrics, and logs before masking or uninstalling the old service. Do not recursively change data ownership as part of the package migration; keep the old package and unit available during the rollback window.

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" \
  docker.io/pgsty/silo: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 silo .
./silo --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 development 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.

There is no CLA: contributions are accepted inbound=outbound under the project license (AGPL-3.0-or-later) and contributors keep their copyright. Every commit must be signed off (git commit -s) per the Developer Certificate of Origin; see CONTRIBUTING.md.

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, Who Takes Over?	Alternatives considered
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 source is distributed under the GNU Affero General Public License v3.0 or later. This fork derives from minio/minio: NOTICE retains the upstream product notice, CREDITS records licenses and notices for included third-party components, and the Git history records downstream modifications.

MinIO is a trademark of MinIO, Inc. The name is used here only to identify the upstream project and compatibility lineage. Pigsty, Silo, and pgsty/silo are independent community efforts and are not affiliated with, endorsed by, or sponsored by MinIO, Inc.

The portal separately publishes the project license summary, documentation attribution, and trademark notice.