DeleteObject ignored the If-Match request header and always deleted the object (204). AWS S3 conditional deletes require that when If-Match is provided and does not match the object's current ETag, the delete is refused with 412 Precondition Failed and the object is left intact. The precondition is evaluated in erasureServerPools.DeleteObject, while the server-pool delete lock is held, before the delete-marker short-circuit and before any version is removed. It runs against the version that will actually be deleted: pinfo.ObjInfo for a normal delete, or the specifically addressed version (read under the held lock) for a version-scoped delete, since getPoolInfoExistingWithOpts strips VersionID. The check is a pure function (no ResponseWriter writes) and returns PreConditionFailed, which toAPIError maps to 412; CheckPrecondFn is cleared before lower layers run so the precondition is evaluated exactly once. Semantics: - If-Match mismatch on a live object -> 412, object preserved. - If-Match "*" requires a live object; a delete-marker-latest -> 412, and an explicitly addressed delete-marker version -> 412 (getObjectInfo returns the marker with MethodNotAllowed; the marker is the precondition target, not a 405). - SSE-C/SSE-KMS: compared against the public ETag derived without the customer key, so a satisfiable condition is never falsely rejected. - Explicit versionId -> evaluated against that version; a missing addressed version -> NoSuchVersion whether or not the key exists; a missing object (no versionId) -> NoSuchKey; no If-Match -> unchanged (including the unconditional version-scoped delete's error behavior). Scope: atomicity is guaranteed for a single erasure set (the default deployment). Multi-pool conditional-delete atomicity (concurrent writers across pools, cross-pool version selection) is tracked as a follow-up. Tests: pure-helper unit test (delete marker, "*", SSE-C without key); object-layer tests (unversioned match/mismatch/missing, versioned delete-marker-latest and addressed delete-marker version, explicit-version selection, missing version on present and absent keys, read-quorum loss); handler tests (412/204/wildcard/404) across both backends, with red/green demonstrated per guard. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01L7qJqWwy8oFA6aCXWRzXQe Signed-off-by: Feng Ruohang <rh@vonng.com>
S3-compatible object storage — a MinIO fork maintained by PGSTY
Website · Documentation · Download · Release Notes · Compatibility · Manifesto · Security · 中文
Important
PGSTY Silo (hereinafter “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
Renamed from
pgsty/miniotopgsty/silo, default branchmaster→main, on 2026-08-06. Artifacts under the original MinIO identity stay published on the archivedminiobranch and in releases up toRELEASE.2026-08-04T00-00-00Z.
Overview
PGSTY SILO keeps one maintained release line of the open-source MinIO server alive after upstream ended community distribution: builds, packages, multi-arch images, security fixes, and the full web console. Pigsty runs it in production as its PostgreSQL backup repository.
It follows one rule — the product and its delivery surfaces are renamed; the protocol and your data are not. Everything else lives on silo.pgsty.com.
Related: pgsty/mc client (shipped as mcli) · pgsty/silo-console · pgsty/silo-pkg · pgsty/pigsty
Quick Start
docker run -d --name silo -p 9000:9000 -p 9001:9001 \
-e MINIO_ROOT_USER=minioadmin \
-e MINIO_ROOT_PASSWORD=change-me-long-password \
-v "$PWD/data:/data" \
docker.io/pgsty/silo:latest server /data --console-address ":9001"
Console on http://localhost:9001, S3 API on http://localhost:9000. The image bundles the client as mcli:
docker exec silo mcli alias set local http://127.0.0.1:9000 minioadmin change-me-long-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. Start from the documentation.
Install
| Method | Where |
|---|---|
| Container | pgsty/silo, multi-arch for linux/amd64 and linux/arm64 |
| Binaries | GitHub Releases — Linux, macOS, Windows on amd64 and arm64 |
| Packages | RPM, DEB, and APK, also via the Pigsty repository |
| Kubernetes | Helm chart, see Download & Install |
| Source | go build -o silo . && ./silo --version |
Every release ships checksums, SPDX SBOMs, Sigstore-signed manifests, and GitHub build attestations. Installation methods and verification commands are documented at Download & Install; migrating from upstream MinIO — taking over an existing minio.service and its /etc/default/minio, and keeping data ownership stable with a /etc/systemd/system/silo.service.d/10-legacy-user.conf drop-in — is covered by the migration guide and the binary & service notes.
Compatibility
The S3 API, MINIO_* variables, minio_* metrics, x-minio-* headers, /minio/* routes, the github.com/minio/* import paths, and the on-disk format (including .minio.sys) are preserved and held in place by a CI compatibility check. Only Silo-owned delivery surfaces change: the silo executable, package, service, Helm chart, and container image — no minio binary alias is installed.
Every divergence from upstream is listed in the code-verified compatibility audit. Treat each release as a downstream upgrade: pin versions, read the release notes, and keep a rollback path.
Security & Contributing
Report vulnerabilities privately as described in SECURITY.md; every fix ships with a public advisory. Contributions are accepted inbound=outbound under AGPL-3.0-or-later with no CLA — only DCO sign-off (git commit -s) is required; see CONTRIBUTING.md.
Contributors
The cards highlight community changes merged into main; the avatar wall includes every other
community member who has opened an issue or pull request.
![]() @h5vx Per-bucket CORS · #71 |
![]() @ycjlin Missing-bucket listing · #37 |
![]() @Dansyuqri Multipart checksum type · #57 |
![]() @pinginfo Notification streaming · #34 |
![]() @ZouhairCharef CVE-2026-34986 · #18 |
![]() @mfredenhagen CVE-2026-39883 · #19 |
![]() @waterkip Documentation links · #41 |
GitHub does not generate a contributor graph for forks, so CONTRIBUTORS.md — not the Insights page — is this project's attribution record. It names all 37 community contributors alongside the change or report they contributed.
Background
Upstream wound down its community edition: the web console was cut back to a stub, prebuilt community binaries stopped, and the community repository was archived. Silo exists to keep those deployments running. The fork is a means, not an identity — if upstream restores its community edition, we will narrow our scope and offer the fixes back.
The Manifesto is the project's public commitment in eleven articles, under one discipline: every article is either something already done with public evidence, or something explicitly refused. In short:
- Compatibility contract — the protocol and your data do not change, and every release documents its tested rollback target and path.
- The license cannot change — AGPLv3, no CLA, no copyright aggregation; nobody here, ourselves included, holds enough copyright to relicense on everyone else's behalf.
- The never list, append-only — no paywalling existing features, no registration wall on downloads, no telemetry (upstream's phone-home paths are removed outright), no CLA, no license change, no trademark enforcement against normal use.
- Security and release discipline — a public advisory for every fix, and a release every one to two months, at most a quarter apart. Judge both against the public record.
Essays: MinIO Is Dead · Who Takes Over? · Long Live MinIO · Promise Kept
License & Trademark
Silo is AGPL-3.0-or-later, derived from minio/minio with upstream copyright and third-party notices preserved in NOTICE and CREDITS. MinIO is a trademark of MinIO, Inc.; the name is used here only to identify the upstream project and compatibility lineage.
Details: license · attribution · trademark








