Kho lưu trữ MinIO không còn được duy trì nữa
(github.com/minio)- Tệp README.md đã được chỉnh sửa để nêu rõ rằng dự án không còn được duy trì nữa
- Cụm từ “chế độ bảo trì” trước đây đã bị xóa và thay vào đó là cảnh báo “THIS REPOSITORY IS NO LONGER MAINTAINED”
- Ở đầu README có đưa ra hai lựa chọn thay thế là AIStor Free và AIStor Enterprise
- Các lỗi liên kết trong tài liệu đã được sửa, và URL kênh Slack đã được chỉnh lại cho đúng
- Thay đổi này xác nhận rằng kho mã nguồn mở MinIO đã được chuyển sang trạng thái chỉ đọc (archive)
Các thay đổi chính trong README.md
-
Mục “Maintenance Mode” trước đây đã bị xóa hoàn toàn và được thay bằng một khối chú thích mới
- Khối mới bao gồm dòng “THIS REPOSITORY IS NO LONGER MAINTAINED”
- Dưới mục “Alternatives” có nêu rõ hai sản phẩm thay thế
- AIStor Free: phiên bản độc lập miễn phí dành cho cộng đồng
- AIStor Enterprise: phiên bản phân phối có kèm hỗ trợ thương mại
-
Liên kết hướng dẫn đăng ký liên quan đến AIStor trong tài liệu cũ đã bị xóa và được rút gọn thành phần mô tả thay thế ngắn gọn
Các chỉnh sửa và sắp xếp khác
- Liên kết Slack đã được sửa từ
https//slack.min.iosai thànhhttps://slack.min.io - Trong ví dụ biến môi trường, lỗi gõ sai (
GOARCh) đã được sửa thànhGOARCH - Lỗi chính tả trong câu chữ giấy phép AGPLv3 (
liabilites) đã được sửa thànhliabilities - Phần “Legacy Binary Releases” được thêm một dòng trống để cải thiện khả năng đọc
Trạng thái kho lưu trữ
- Ở đầu trang GitHub hiển thị dòng “This repository was archived by the owner on Feb 13, 2026. It is now read-only.”
- Điều này có nghĩa là kho đã được lưu trữ (archive) và không còn có thể thay đổi hay nhận đóng góp nữa
Ý nghĩa
- Cùng với việc sửa README, kho đã chính thức được chuyển sang trạng thái ngừng bảo trì và lưu trữ
- Thay vì phiên bản mã nguồn mở MinIO, người dùng được hướng dẫn chuyển sang dòng sản phẩm AIStor Free/Enterprise
- Hỗ trợ cộng đồng vẫn tiếp tục được duy trì theo best-effort thông qua GitHub và Slack
1 bình luận
Ý kiến Hacker News
Tôi không nghĩ việc MinIO đóng mã nguồn mở là có vấn đề
Trên toàn thế giới có quá nhiều người chỉ dùng miễn phí
Tôi đã thử nghiệm các phương án thay thế từ vài tháng trước, và sau MinIO, tôi cho rằng RustFS sẽ là bên chiến thắng
Tôi đã so sánh Garage, SeaweedFS, Ceph và RustFS; RustFS và SeaweedFS là nhanh nhất, còn việc cài đặt và console của RustFS là thuận tiện nhất
Ceph quá phức tạp nên rất khó triển khai nếu không hiểu sâu mã nguồn
Cũng có chỉ trích rằng CLA của RustFS là một “mồi nhử”, nhưng tôi nghĩ đó không phải biện pháp quá đáng mà là cách giảm rủi ro pháp lý
Milvus cũng đánh giá cao RustFS, và xét theo các chỉ số kỹ thuật, tôi tin rằng cuối cùng RustFS sẽ chiến thắng
Bài viết đánh giá RustFS của Milvus
Vấn đề người dùng miễn phí thực sự tồn tại, và trong thời đại AI nó còn nghiêm trọng hơn
Nhiều người dùng dự án miễn phí, nhưng tỷ lệ chuyển đổi thành khách hàng trả phí là rất thấp
Milvus cần object storage tốt hơn để đảm bảo độ ổn định và hiệu năng, và RustFS là một ứng viên sáng giá
Tuy nhiên về lâu dài, nếu hệ sinh thái không đáp ứng được điều này thì chúng tôi cũng sẽ cân nhắc tự xây dựng
Cần có thảo luận về tính bền vững của mô hình giấy phép mã nguồn mở
Mô hình thời Apache 2.0 đang cho thấy giới hạn, và cách chỉ đơn giản “hy vọng doanh nghiệp sẽ hỗ trợ” không còn hiệu quả nữa
Quyết định của MinIO đáng được chú ý như một tín hiệu của sự thay đổi này
Việc thiết lập khá phức tạp nhưng hiện tại nó rất ổn định
Claude Code đặc biệt xuất sắc trong việc quản lý Ceph, và xử lý phục hồi hay chỉnh sửa CRUSH map cũng dễ dàng
Tôi nghĩ câu “không hiểu sâu mã nguồn thì không thể triển khai” là hơi phóng đại
Nếu Ceph phù hợp với nhu cầu của bạn thì rất đáng thử
Chỉ cần cài một binary duy nhất và viết file cấu hình
/etc/garage.tomlCó thể chạy bằng
garage serverhoặc để AI viết script khởi tạoAIStore của NVIDIA cũng là một hệ thống tương thích S3 rất tốt, có thể xem tại trang chính thức của AIStore
Nó nhanh hơn MinIO nhưng hiệu quả sử dụng dung lượng kém hơn một chút
SeaweedFS mang cảm giác rất giống một dự án cá nhân và sẽ khá rủi ro nếu không sao lưu thường xuyên
Tôi muốn tránh RustFS vì vấn đề CLA khiến nó có vẻ như sẽ là bản tái diễn của vụ MinIO
Nó hoạt động theo đơn vị volume, và các cập nhật cũng được thực hiện theo đơn vị volume
Trong khi đó, object storage thông thường còn được dùng làm backend cho phân tích nên cần khả năng quét tốc độ cao
Vì vậy SeaweedFS có những đánh đổi khác với object storage đa dụng
Khi tôi ngừng vận hành một dịch vụ mã nguồn mở, cảm giác kiệt sức mãn tính đã biến mất
Làm việc miễn phí không hề vui, và việc duy trì song song phiên bản trả phí với phiên bản cộng đồng cũng rất mệt
Mối quan hệ với những người dùng không trả tiền cuối cùng chỉ đem lại căng thẳng
Có vẻ nhóm MinIO cũng rút ra bài học tương tự
Đó là mô hình COSS (Commercial Open Source Software), cung cấp phiên bản cơ bản miễn phí và bán các tính năng trả phí cho khách hàng doanh nghiệp
Việc chuyển sang mã nguồn đóng chỉ đơn thuần là một quyết định kinh doanh
Tôi đã dùng SeaweedFS trong production suốt thời gian dài, và hiện vẫn vận hành cùng Wasabi
SeaweedFS vẫn rất tuyệt cho nhu cầu local storage tốc độ cao
Ngay từ đầu lẽ ra phải nói rõ kế hoạch
Nếu không, điều đúng đắn là giữ lời hứa ban đầu
Tôi đang quản lý storage engine tên là TidesDB, đau lưng thì đau nhưng vẫn làm vì thích
Trải nghiệm này có thể mang tính chủ quan, nhưng rõ ràng nó vẫn có thể rất vui
Tôi đã migration thành công từ MinIO sang Ceph
Tôi cũng thử SeaweedFS, nhưng khi phân tích bug với sự trợ giúp của Claude thì thấy cấu trúc code rất lộn xộn
Tuyệt đối không nên dùng SeaweedFS ngoài mục đích thử nghiệm. Nguy cơ mất dữ liệu là rất lớn
Đã có nhiều nỗ lực thay thế khác nhau, nhưng cuối cùng Ceph vẫn là bên xử lý tốt nhất độ phức tạp của bài toán
Gần đây tôi đang migration MinIO sang Ceph
Tôi đã dựng một cụm Ceph 3 server bằng cephadm và đang sao chép 120TB dữ liệu với tốc độ 420MB/s
Ceph phức tạp hơn MinIO nhưng khả năng mở rộng rất tốt và rất ổn định
Thật đáng tiếc khi console của MinIO biến mất
Tôi chọn Ceph vì Elasticsearch không thích snapshot S3 của Garage
Chỉ cần chú ý đừng để ổ đĩa trên các node bị đầy
Thật ấn tượng khi nhiều người đang vội vàng thử các phương án thay thế chưa được kiểm chứng trong production
Rủi ro thực sự của phụ thuộc hạ tầng không nằm ở việc mã nguồn đóng, mà là chi phí chuyển đổi
Dù tương thích S3 thì migration thực tế vẫn mất từ vài tuần đến vài tháng vì những khác biệt tinh vi
Tôi tự hỏi có bao nhiêu người dùng MinIO thực sự đã tài liệu hóa kế hoạch migration của mình
AIStore được nhắc đến như một phương án thay thế MinIO
Ngoài ra còn có nhiều lựa chọn mã nguồn mở khác:
Garage, RustFS, SeaweedFS, Supabase Storage, Scality Cloudserver, Ceph
Nó cung cấp S3 gateway và proxy các lời gọi S3 sang SFTP, FTP, NFS, SMB, IPFS, Dropbox, Google Drive, v.v.
Nó hoàn toàn stateless và có thể kết nối với nhiều backend khác nhau
Trong code đã có sẵn các chuẩn bị cho việc chuyển đổi giấy phép sau này
Ceph là hệ thống gần với tính năng S3 nhất, nhưng cấu hình phức tạp và nhạy cảm với độ trễ
Garage phù hợp cho lưu trữ đơn giản, nhưng thiếu các tính năng nâng cao của S3 như ACL phức tạp hay giới hạn theo đường dẫn
Clustering của nó thân thiện với WAN nhưng không cần cấu hình theo rack như Ceph
Có vẻ hiện vẫn chưa có lựa chọn đơn giản như vậy
Nó thiếu tính năng quản trị, nhưng về mặt toàn vẹn dữ liệu thì tôi tin Ceph hơn
Ceph cho cảm giác được tạo ra bởi những người thực sự hiểu sâu về distributed systems
Liên kết PR
Nếu xem chuỗi HN trước đó, có thể thấy MinIO đã chuyển sang chế độ maintenance từ trước
Từ lúc đó việc chuyển sang mã nguồn đóng đã gần như được báo trước
MinIO vốn đã thiếu minh bạch, xa rời tinh thần mã nguồn mở khi xóa các issue chỉ trích hoặc khóa bình luận
Vì vậy ngay khi nó chuyển sang maintenance mode tôi đã chuyển sang Garage
Tôi đang chuẩn bị một PR nhưng vẫn chưa gửi
Phần lớn dự án mã nguồn mở nghiêm túc đều được ngành công nghiệp hỗ trợ, và lập trình viên web thông thường rất khó đóng góp
Tôi khuyên nên fork và lưu local để đề phòng kho MinIO có thể bị xóa
Kho public trên GitHub nếu bị xóa thì fork vẫn còn, nhưng nếu bị chuyển sang private thì các fork cũng biến mất
Hệ sinh thái Ruby với gem prawn_plus cũng từng có chuyện tương tự
Xem tài liệu chính sách fork của GitHub
Với những người chỉ dùng MinIO để test local, đây có thể trở thành một cái bẫy khép dần
Nếu bạn đang vận hành các giải pháp observability cần object storage như Thanos, Loki, Mimir hay Tempo
Thì có thể cân nhắc VictoriaMetrics, VictoriaLogs, VictoriaTraces thay thế
Chúng dựa trên block storage, có thể mở rộng tới quy mô petabyte, và cung cấp hiệu năng cùng độ sẵn sàng cao mà không cần quản trị thủ công nhiều