Recent changes about MinIO

[chenlica]

MinIO stops distributing free Docker images: https://news.ycombinator.com/item?id=45665452

How does it affect our project that uses MinIO?

[aglinxinyuan]

There is speculation that MinIO may no longer remain free, though nothing has been confirmed.
We may need to reconsider the decision to rely solely on a single library without any alternatives.
https://linuxiac.com/minio-with-yet-another-controversial-move/

[chenlica]

If this discussion is no longer needed, I will close it.

[aglinxinyuan]

You can close it.

[chenlica]

I would like to continue this discussion. In particular, all MinIO images have been deleted: https://hub.docker.com/r/minio/minio. We need to find alternatives of MinIO.

[parshimers]

I think all CI depends on MinIO, which is very unfortunate. MinIO also has been unmaintained for more than a year now, and contains a variety of severe unmitigated vulnerabilities. Kicking the can by doing a variety of things to keep using MinIO seems tempting but I think it should be avoided unless absolutely necessary.
I think RustFS would be one simple solution, at least for deployments that don't have an amount of data that would rule it out.
In general it is better to be agnostic as possible to S3 backends. In AsterixDB a variety of them work with the S3 storage back-end. In this way hard dependencies like this won't arise.

I have a patch here that I had Claude cook up that at least attempts to move everything to RustFS: parshimers@22ba482

It's quite a lot of code, so I think someone with more knowledge of some of these areas needs to be involved.

[Ma77Ball]

Summary

The official minio/minio and minio/mc images are gone from Docker Hub. Only unmaintained legacy mirrors remain, and the last community build ships an unpatched high-severity CVE. Texera CI pulls MinIO as the S3 store behind LakeFS and Iceberg, so fresh runs fail at image pull. We need to pick a replacement. RustFS and SeaweedFS have been suggested; Garage, Silo, and Chainguard's MinIO rebuild are also compared below.

What happened upstream

• Oct 2025 MinIO Community Edition went "source-only": no more prebuilt binaries or images. The final published image contains CVE-2025-62506 (restricted service accounts can escalate to unrestricted ones), which the maintainers declined to patch.
• Dec 2025 Project entered maintenance mode: no new features, no PR reviews, security fixes case-by-case only.
• Apr 2026 Upstream repo archived. Docker Hub removed minio/minio and minio/mc entirely; all tags return 404 / pull access denied. bitnami/minio is also gone. Quay still serves frozen, unmaintained tags.

Impact on Texera

MinIO appears in four places:

1. Compose/K8s stack S3 blockstore behind LakeFS (versioned dataset collections).
2. Iceberg storage the Lakekeeper REST catalog writes table data to the same endpoint.
3. Local dev bin/local-dev.sh starts MinIO on :9000.
4. CI GitHub Actions brings up the stack; docker pull minio/minio:<tag> now fails and breaks every fresh run.

Why pinning a legacy tag or unofficial mirror is not acceptable:

• The latest images carry CVE-2025-62506 with no fix coming.
• Unofficial mirrors are unaudited and can introduce a supply-chain risk for an Apache project.
• Building from an archived AGPL repo makes us maintainers of dead code.

One thing in our favor: everything talks to MinIO through the generic S3 API (LakeFS, Lakekeeper, AWS SDKs). We are not coupled to MinIO itself. Requirements for a replacement: S3 multipart upload + path-style addressing, single-container deployment, healthcheck endpoint, static key config, amd64/arm64 images, and an ASF-friendly license (Apache-2.0 preferred; AGPL is a complication).

Candidates

	License	S3 coverage	Maturity	Drop-in?	Main upside	Main risk
RustFS	Apache-2.0	Broad (multipart, versioning, policies, lifecycle, SSE); some Object Lock/encryption gaps	Young was alpha-labeled "not for production"; verify current status	Near MinIO-shaped config, web console included	Purpose-built MinIO successor, clean license, single container	Stability; young project may churn
SeaweedFS	Apache-2.0	Solid core via S3 gateway; some IAM/policy edge cases differ	Production-proven since ~2015; O(1) reads at any object count	No master + volume (+ filer + gateway) processes, new config	Most mature Apache-2.0 option	Heavier than a CI blockstore needs; larger migration
Garage	AGPL-3.0	Core ops only; versioning/lifecycle incomplete	Moderate; small codebase	No different config model	Tiny footprint (~1 GB RAM), dead-simple ops	AGPL + gaps that LakeFS may hit
Silo (pgsty/silo, community MinIO fork)	AGPL-3.0	Identical to MinIO: same MINIO_* vars, mc, healthcheck, on-disk format	Fork is new; codebase is MinIO's	Yes, image-name swap only	Zero-effort fix; reuses existing data volumes	Fork longevity; AGPL; inherits MinIO's architecture
Chainguard MinIO	AGPL-3.0 upstream	Identical to MinIO at freeze	Rebuilt from source, CVE-patched, SLSA L3	Yes image-name swap only	Immediate, security-patched, free tier	Depends on Chainguard's free tier; upstream frozen, no new features

Also considered and rejected: Ceph RGW (most battle-tested S3, but massive operational overkill for a CI blockstore) and LocalStack S3 (fine for mocking, but dev and single-node deployments need a real store).

Open questions

1. Has anyone run RustFS or SeaweedFS behind LakeFS in production or CI?
2. Any ASF policy concerns with compose files referencing an AGPL image (Silo) as an unbundled runtime dependency, even temporarily?
3. Should CI and local dev stay on the identical store, or is a lighter store acceptable for CI only?
4. Do we know of Texera deployments with existing MinIO data volumes that need an in-place migration story?

[Ma77Ball]

Update after testing the swap:

• The MinIO images are already gone from Docker Hub, even our pinned tags and :latest, so CI and local dev are broken now.
• Everything left that replaces MinIO is AGPL, which we can't use as an Apache project: pgsty/minio, Chainguard, and bitnamilegacy/minio all ship AGPL. The mc client is AGPL too, so bucket setup needs to move to aws-cli.
• bitnamilegacy/minio doesn't help either: it's frozen, unmaintained, and still has the CVE.

I think we should switch to RustFS (Apache-2.0) on main for now. It's the closest S3 replacement, so lakeFS and Iceberg keep working the same way. The only changes needed are the credential env vars, the healthcheck, and using aws-cli for bucket setup.

[chenlica]

I agree with the plan of switching to RustFS for now.

[parshimers]

I raised a PR to switch to RustFS on main. I think a couple folks have already looked at it, it is here: #8542. I encourage everyone to give the PR a try if they have a development setup at hand, I would like to be sure it actually unblocks development work entirely.
There needs to be a broader discussion about how this switch of the default object store might apply to existing instances and what those users can do today given the circumstance forced upon all of us by MinIO.

[Yicong-Huang]

Great! Thanks @parshimers for the prompt fix! Also glad to see that the fix in #8542 has been merged.

Just to add to the procedure, I think it would be better to disable the blocking test first and then work on the fix separately. This way, we have much less pressure to rush the fix and can take the time to address the issue properly, without interrupting the momentum of other development work.

[parshimers]

Good point Yicong. I'm not sure why that didn't occur to me at first. I suppose I had the preconception that it was too big a piece of the system to not have work, but that's not exactly the case. It is involved in many things, but not everything. I think disabling the tests to unblock and then re-enabling them with the fix is a better practice overall. Here we just got (hopefully) lucky that RustFS is a very close dependency match

[Ma77Ball]

It might be better to add flags to turn this on and off more seamlessly. Otherwise, disabling MinIO tests would take just as long as composing a solution given AI tooling. Overall, I think it is a good solution, but it needs some groundwork to integrate more seamlessly. I can work on a PR to implement this feature if you prefer.

[parshimers]

I am wondering if the release manager for 1.3.0 (@mengw15) and 1.2.1 (@xuang7) have any thoughts. Clearly, this has a big impact on released (or soon to be released) versions.

[mengw15]

Thanks for the ping. From the 1.3.0 side:

1. Yes, the impact on the release is big. With the MinIO images gone, release/v1.3 cannot deploy its default object store and its own CI is red, so the branch is unstable as it stands. This fix needs to be backported to the release branch.
2. I don't think we should look for a different fix for the release branch. It should stay consistent with the fix on main (feat(deploy): replace MinIO with RustFS as the default object store #8542).
3. I have raised the backport PR for v1.3: feat(deploy, v1.3): replace MinIO with RustFS as the default object store #8550. It is a clean cherry-pick of feat(deploy): replace MinIO with RustFS as the default object store #8542; reviews welcome.

[parshimers]

I see. That was how I feared it might be, thank you for the confirmation. Also thank you for raising the backport PR, I will give it a look.
I am unsure of the policies about upgrades or such between versions of Texera. I think this would be a backwards-incompatible change. Is there some existing guidance about upgrades, and promises that are made to users about that?

[mengw15]

For 1.3.0 itself this is not a compatibility concern: the branch has never been released, so #8550 goes in as-is.

The open question is the 1.2.0 → 1.3.0 upgrade: a 1.2.0 deployment with data in the bundled MinIO would come up with an empty RustFS. There is no written upgrade policy today.

[xuang7]

Adding a bit more context from the v1.2 side:

Existing v1.2 deployments should keep running as long as the MinIO images are already cached, but fresh installs and anything that needs to re-pull the images now fail because minio/minio and minio/mc are no longer available.

I agree that we should stay consistent with #8542 and replace MinIO with RustFS. I will open a separate backport PR for release/v1.2.

For existing deployments, RustFS appears to be able to read MinIO's data directory after fixing the volume permissions, but this still needs more testing.

[parshimers]

It would be interesting to try that functionality that RustFS has to directly read MinIO volumes, I saw it as well. Even if we didn't make any promises about intra-version compatibility, it would be a nice thing to describe and offer as a solution for this upgrade if it does work.