SILO: S3-Compatible Object Storage by Pigsty

Upstream wound down its community edition: the web console was cut back to a stub, prebuilt binaries stopped, and the server repository was archived. Pigsty runs its own PostgreSQL backups on this code, so it needed a maintainer either way. Everything else follows from that. The reasoning is written out in the PGSTY SILO Manifesto.

It keeps existing MinIO-compatible deployments running: versioned binaries and packages you can download, security fixes with public advisories, and the full web console. No build step and no commercial license. This is maintenance work, not a new product.

A short list, kept short on purpose. AGPLv3 with no CLA: contributions come in under DCO sign-off, so copyright stays with each author. No paywalls, no registration walls, no telemetry. A release every one to two months, at most a quarter apart. A public advisory for every security fix we ship. The Manifesto also lists what we refuse to promise, such as fix-time SLAs.

One person, named. The fork is maintained under the PGSTY organization by Ruohang Feng (Vonng), who wrote the Pigsty PostgreSQL distribution. He has deployed and run a 25 PB MinIO cluster, and does the packaging and releases here. Article 9 of the Manifesto says in advance what happens if that arrangement ends.

Most of the code, and most of the first-pass review, is written by coding agents. A human reads every diff, decides the trade-offs, and merges; nothing lands without CI and that review. We keep the agents' working notes and trade-off write-ups, because when a fix turns out to be wrong, the reasoning behind it is the thing you want. The security advisories and release notes are what this arrangement produces in public. Judge it on those.

No. The .minio.sys metadata directory and the object layout are unchanged from upstream, held in place by a CI compatibility check, and tested for interoperability with MinIO. New features do not touch the on-disk format; if one ever has to, it will be opt-in and marked non-reversible before you can turn it on. The compatibility audit has the details.

The S3 API, MINIO_* environment variables, minio_* metrics, x-minio-* headers, and /minio/* routes are unchanged. For a container deployment that usually means changing the image name and keeping the same volume. The differences that do exist are recorded per version in the compatibility notes, and the migration guide covers Docker, packages, and the rollback path.

Yes, with the usual caveats. Pigsty's production PostgreSQL backups run on Silo, and this page links third-party reports from people running it elsewhere. That is evidence, not a warranty. Pin a release, test it against your own workload, and rehearse the rollback in the migration guide before you need it.

Silo carries AGPLv3, the same license as the upstream it forked. Our position (a position, not legal advice) is that using Silo through its S3 API does not make your application a derivative work, and we will not use the license as a threat or a sales instrument. We also could not relicense it if we wanted to: there is no CLA, contributions come in under DCO, and copyright stays spread across everyone who wrote a line. Article 3 of the Manifesto has the full statement.

Released artifacts and documentation are meant to stay up, and we will keep them up as long as we can. The build is documented and provenance-attested, so anyone can rebuild equivalent artifacts from source without us. That part does not depend on us being around. If active maintenance stops for six months, we will say so publicly and archive the project rather than let it go quiet. Article 9 of the Manifesto has the exit plan.