Feng Ruohang
45b1e4bc00
The unreleased native-restore fixes after RELEASE.2026-10-26T00-00-00Z let the lock decide who owns a restore. Sincefa42a0982a single-pool worker holds the object lock for the whole tier download, and since7f38bf628a busy lock means "a restore runs".7f38bf628also keeps the restore's data in a marked multipart upload. Two regressions followed: - While an old version restored, every GET, HEAD and write of the same key waited for the download. On a single pool this is new; with several pools the released code already held the lock that long. - An ordinary upload whose completion failed after staging its metadata became InvalidUploadID for every caller, and could not be aborted for an hour. The marker that hid restore uploads could not tell them apart once a completion had rewritten the upload's xl.meta. A restore now runs in two phases: - The worker erasure-codes the tier copy into the tmp volume of the version's set, without the object lock, as heal does. A drive that fails any part, or misses a part when CheckParts runs before the commit, takes no part in the commit. - A restore lock per version tells whether a restore runs. POST takes it before the object lock and hands it to the worker. It is a liveness hint: only the checks under the object lock decide what is written. - The commit takes the object lock briefly, on one pool or several. It reads the version again and checks the attempt's ownership, the version identity, the tier copy, the part layout and the erasure layout. It then publishes with RenameData drive by drive, never through erasure renameData's undo, and needs the write quorum. The replaced data directory goes only when every published drive reports the same one. - A publication that reached some drives but not the write quorum converges under the same lock hold, in bounded retries after it: back to the unrestored version on every drive that holds it, or to a committed restore when the copy turns out to be on a write quorum. Each pass first checks that every drive holds what the version held before the commit, the commit wrote, or a convergence wrote, and stops on anything else. It deletes no directory. Multipart goes back to main: erasure-multipart.go and bucket-object-lock.go are identical to69fcf50cd. The commit lock, the marker and the restore exceptions of multipart completion and of the null-version Object Lock check are gone, and single-pool completion again takes the upload lock first and the object lock right before it commits. With several pools, abandoned-data cleanup now takes the pools lock that writes take, as heal does, so it cannot remove a directory that a commit moved in place and has not yet referenced. The restore capability becomes protocol 2, and a queued worker checks it again. Recovery after a coordinator crash during publication, and storage RPCs that complete after their caller returned, stay excluded. Main has the same exposure, and they are tracked separately. Tests: - New regression tests cover both problems. They fail onf85d4a5fa, and the multipart one also passes on main. - Fault-injection tests cover a publication below the write quorum, including seven of twelve drives on 8+4; lost answers; convergence retries and stops; the old data directory; a stale inline marker; a recreated tmp volume; a published revision read across its expiry; a second POST; a target deleted during the download; a tier 404; and pools-locked abandoned cleanup. - Thirteen tests of the upload marker from7f38bf628are dropped, and so is TestNativeRestoreConcurrentCompletion fromfa42a0982, which completed the restore's upload from a client. Four tests are reframed for the new semantics, including the lock-domain restore test, which now gates the commit. - Three self-recursive WriteMetadata test doubles are fixed, and the helpers of the dropped tests are removed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> 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.
SILO 20261026000000
SILO 20261026000000 is available as platform archives, Linux packages, and standard or distroless Docker images for amd64 and arm64. The release tag is RELEASE.2026-10-26T00-00-00Z; the package version is 20261026000000.0.0, built from source c3ad836aed0d.
This release fixes LDAP long-DN login, IAM policy refresh, multi-pool deletion safety, tiered-object expiry, multipart replication checksums, and remote rollback-option propagation. It embeds Console v2.5.1 (fff1618d9abb) and uses silo-pkg v3.15.2, Go 1.27.3, and upstream minio-go v7.4.2-0.20261025165926-320af050c445. Use mcli 20261026 for administration; the container images bundle it as mcli.
The Server IAM cache repair enables Console's Reset to default action. Existing storage timeouts and cancellation behavior remain: a timeout does not prove that a disk operation stopped or a write did not commit. Read the coordinated release notes and remaining storage limits before upgrading. See CONTRIBUTORS.md for the people behind the code, reports, and documentation.
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:RELEASE.2026-10-26T00-00-00Z 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
Silo preserves S3 and storage-format compatibility, including existing MINIO_* variables, minio_* metrics, x-minio-* headers, /minio/* routes, and .minio.sys data. CI guards selected compatibility identifiers; release notes document intentional security and behavior changes. Silo-owned delivery surfaces use the silo executable, package, service, Helm chart, and container image; no minio server binary alias is installed.
The supported release stack is pgsty/silo + pgsty/silo-console + pgsty/mc + pgsty/silo-pkg; compatibility with unmodified upstream MinIO/MC is best effort. The Server, Console, and client retain their historical module paths where needed, while maintained code imports github.com/pgsty/silo-pkg/v3 directly. The SDK github.com/minio/minio-go/v7 is an explicit upstream dependency. See the current go.mod for versions and replacements.
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.
TLS and Go upgrades
Server 20260916 restored Go's default key exchange; Server 20261018 retains it with Go 1.27.2.
TLS key exchange follows Go's defaults across the S3 listener, node links,
replication, identity providers, etcd, and external HTTP services. If an endpoint
cannot accept ML-KEM, GODEBUG=tlsmlkem=0 disables the default hybrid exchanges
for the process; certificate verification remains enabled. This option does not
disable ML-DSA signatures or resolve every TLS reset. Prefer updating the
incompatible endpoint before removing the temporary setting.
If only the new SecP hybrids cause problems, GODEBUG=tlssecpmlkem=0 disables
those groups while retaining X25519MLKEM768.
For builds targeting Go 1.27, setting either SSL_CERT_FILE or SSL_CERT_DIR
on macOS replaces Keychain trust with on-disk roots and Go's verifier. Stale or
incomplete CA paths can break previously trusted connections; unset inherited
values to restore Keychain trust. Explicit certificates in the configured CAs
directory remain additive to the selected root pool.
Go 1.27 binaries require macOS 13 or later. See the
Go release notes and the
Go 1.27 TLS and OIDC discovery guide.
Documentation ownership
User documentation is maintained at silo.pgsty.com,
with source in pgsty/silo.pgsty.com.
The remaining docs/ tree contains inherited references, examples, and tooling
fixtures. Investigation logs, AI work records, and temporary reports are kept
outside this repository; reusable findings belong in the companion site.
See AGENTS.md for repository ownership and maintenance rules.
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
Every human issue or pull-request author is part of the SILO community, including open and unmerged work. We also recognize security reports, including reports sent by email, with the reporter's permission. Merged fixes, adopted proposals, and actionable reports receive priority, with first participation guiding the remaining order. Gold rings highlight reviewed significant contributions.
View contribution notes and actual PR status.
Star History
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