[Feature Request]: Replace MinIO as default object storage - MinIO open-source is officially dead #13840

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (Language Policy).
• Non-english title submitions will be closed directly ( 非英文标题的提交将会被直接关闭 ) (Language Policy).
• Please do not modify this template :) and fill in all the required fields.

Is your feature request related to a problem?

MinIO's open-source community edition has been officially abandoned. The GitHub repository is now archived and read-only. RAGFlow's default docker-compose-base.yml still ships with a pinned MinIO image (quay.io/minio/minio:RELEASE.2025-06-13T11-33-47Z) that will never receive security patches again. This is a serious issue that affects every default RAGFlow deployment.

What happened to MinIO

The collapse of MinIO's open-source edition didn't happen overnight — it was a staged dismantling over the course of 2025:

1. May 2025 — MinIO stripped the full admin console and management GUI from the community edition (PR [Question]: Display data on web #3509), replacing it with a bare-bones object browser. Bucket management, user administration, and policy configuration were moved behind the commercial AIStor paywall (~$96,000/year).

2. October 2025 — MinIO stopped publishing Docker images to Docker Hub and Quay.io, with no prior notice. This happened during the release of a critical security update (RELEASE.2025-10-15T17-29-55Z), meaning users couldn't even get the CVE fix through normal channels.

3. December 3, 2025 — MinIO placed the community repository in "maintenance mode." No new features, no enhancements, no PRs accepted. Critical security fixes evaluated on a case-by-case basis only.

4. February 12, 2026 — MinIO updated the README to: "THIS REPOSITORY IS NO LONGER MAINTAINED" and archived the repository. It is now fully read-only. No PRs, no issues, no contributions.

The community edition is now distributed as source-code-only. All users are directed toward MinIO's commercial product, AIStor.

Why this matters for RAGFlow

1. Security risk in every default deployment

The image quay.io/minio/minio:RELEASE.2025-06-13T11-33-47Z currently pinned in docker-compose-base.yml is frozen in time. It will never receive another security patch. Any CVEs discovered after June 2025 remain unpatched. Since MinIO stopped publishing container images in October 2025, there is no official upgrade path — users would need to build from source themselves.

Every new RAGFlow user who runs docker compose up gets an object storage layer with known security debt and zero remediation path.

2. Supply chain risk

MinIO's Docker images are no longer available on Docker Hub or Quay.io for newer releases. The pinned image still works today because it was cached in registries before the cutoff, but there is no guarantee this will remain the case indefinitely. A registry cleanup or policy change could break fresh RAGFlow deployments.

3. No upstream support

With the repository archived, there is:

• No community support (Slack is best-effort only)
• No bug fixes
• No compatibility updates for newer OS/kernel versions
• No response to newly discovered vulnerabilities

4. Reputational and compliance risk

Organizations evaluating RAGFlow for production use will flag a dead dependency during security reviews. For SOC2, ISO 27001, HIPAA, and PCI compliance, running unmaintained software at the storage layer is a non-starter.

What RAGFlow already has (and what's missing)

RAGFlow already supports S3-compatible storage backends through STORAGE_IMPL and service_conf.yaml. Users can configure alternatives like AWS S3, Alibaba Cloud OSS, or other S3-compatible services. This is good architectural foresight.

However:

• The default deployment still depends on MinIO — this is what 90%+ of users will run.
• There is no mention of this issue in the 2026 Roadmap (ROADMAP 2026 #12241), release notes, or documentation.
• No migration guide exists for moving from the bundled MinIO to an alternative.
• Users who try alternatives encounter bugs (e.g., [Bug]: OSS service cannot be initialized correctly when configured as a replacement for MinIO. #6522, [Bug]: No files are detected for the s3 compatible storage #13149).

Describe the feature you'd like

1. Acknowledge the issue publicly - Add a note to the documentation and README about MinIO's status.
2. Replace the default object storage in docker-compose-base.yml with an actively maintained S3-compatible alternative. Strong candidates:
   • SeaweedFS - mature, Go-based, S3-compatible, Apache 2.0 license
   • Garage - lightweight, S3-compatible, AGPL v3
   • RustFS - high-performance, S3-compatible, Apache 2.0 license, designed as a MinIO drop-in replacement
   • A community fork of MinIO (e.g., Vonng's fork that restores the admin console and ships patched binaries)
3. Provide a migration guide for existing users to move their data from the bundled MinIO volume to the new default.
4. Improve and test the S3-compatible backend path - Several issues ([Bug]: OSS service cannot be initialized correctly when configured as a replacement for MinIO. #6522, [Question]: How to set up in order to use S3 objective storage instead of MINIO? #7717, [Bug]: No files are detected for the s3 compatible storage #13149) show that switching away from MinIO is not seamless today.

Describe implementation you've considered

No response

Documentation, adoption, use case

Additional information

No response