pgsty/minio 포크를 선택했음. 2026-03-02에 Ruohang Feng이 MinIO를 포크하고 안정적인 배포판과 CVE 패치를 유지하겠다고 한 프로젝트임.
종단 간 테스트에서 즉시 시작·종료되고 로컬 디렉터리를 읽고 쓰는 S3 시뮬레이터로 사용하는데, 이 역할에는 아주 잘 맞고 불만도 없음. 관리자가 실명을 걸고 자신의 평판을 내세우니 신뢰할 만하다고 봄. 다만 내 용도는 대부분의 사용 사례보다 단순함.

다른 제품을 소개하는 건 좋지만, 원문은 MinIO가 사라져 더는 선택할 수 없는 것처럼 느껴지게 함. 둘 다 사실이 아님. 회사는 다른 방향으로 갔지만 기존 소스는 그대로 있고, 그 버전도 충분히 쓸 만함.
우리도 여전히 운영 환경에서 문제없이 사용 중임. 기존 컨테이너 이미지도 남아 있고 원하는 곳에 복사해 둬도 됨. 지원이나 새 기능이 필요하면 직접 포크하거나 위 포크를 사용하면 됨.

한번 써봐야겠음. 현재는 기능이 축소되기 전 마지막 MinIO 버전으로 고정해 사용 중임.

나도 이쪽으로 전환했고 잘 작동함. 폴더 하나를 저장 백엔드로 사용할 수 있어 구성이 상당히 단순해짐.

온프레미스에서 Sentry를 운영하면서 기본 SeaweedFS가 동시 쓰기에서 계속 실패해 Garage로 교체해야 했음. 잠깐 원인을 파봤지만 교체하는 편이 더 쉽고 빨랐고, Garage는 단일 노드에서도 약 10TB까지 테스트하며 잘 사용함. SeaweedFS도 멋진 프로젝트라고 보며 설정 문제였을 수도 있지만, 더 조정할 만큼의 가치는 없었음.
Garage의 초기 설정은 불편함. 여러 관계형 데이터베이스 이미지와 달리 Docker 이미지가 키·버킷·권한을 자동으로 생성해 주지 않아 처음 수동으로 설정할 때 번거로웠음. 다만 문서는 꽤 좋고, AI 에이전트로 사용자 정의 초기화가 들어간 Docker 이미지를 만드는 데는 약 15분이면 됨.
가장 불편했던 건 저장된 위성 데이터를 탐색하려고 WinSCP를 직접 연결했을 때 초기 연결이 멈추던 현상임. 원인은 알아내지 못함.
Zenko도 사용했지만, 오래된 컨테이너 이미지 등을 보면 프로젝트가 건실하게 유지되는 느낌은 아니었고 사실상 방치된 듯했음. 그래도 일부 활동은 이어지고 있음.

예전에 SeaweedFS를 사용했는데 구성 요소가 더 많고 기능도 풍부해 보였음. 홈랩에는 과해서 Garage로 옮김.
Garage는 매우 안정적이지만 메타데이터 엔진과 파일은 반드시 NVMe에 둬야 함. 그렇지 않으면 작은 파일 처리 속도가 느려짐. 버킷별 보존 기간 설정 같은 기능도 없어서, 정말로 S3 버킷 역할에 집중한 제품임.

테스트·개발 환경에서는 동기화를 끄면 성능을 어느 정도 회복할 수 있음. 다만 데이터를 잃어도 괜찮은 용도에만 적합함.

SeaweedFS를 쓸 때는 찾을 수 있는 문서가 빈약해서 어려웠음. 반면 Garage는 문서가 상당히 잘 갖춰진 편이었음.

테스트용 3노드 클러스터에 Garage를 설치하자마자 데이터가 손상되고 파일을 잃었음. 다시 쓰고 싶지 않음.

글의 평가 기준이 이상함. 제목은 단일 노드 로컬 S3용이라고 하지만, 실제로 찾는 건 MinIO 호환성이며 이는 전혀 다른 질문임.
1년쯤 전 MinIO를 떠나면서 나도 대안을 조사한 끝에 Garage를 선택함. GUI는 없었지만 복잡도는 MinIO와 비슷하게 느껴졌음. Nomad에서 컨테이너로 실행하는 3노드·5노드 구성을 각각 운영하게 되면서 조금 더 복잡해졌을 수는 있음.
설정이 부담스러웠던 기억은 없음. 내가 원한 건 MinIO를 그대로 흉내 내는 제품이 아니라 기본적인 S3 유사 기능이었음. AWS S3의 기본 기능을 구현하는 객체 스토리지를 만들면서, 제3자 독점 제품의 특이한 동작을 맞추는 데 주력하는 사람이 얼마나 되겠음?
원문은 Garage로 바꾸려면 코드 수정이 필요하다고 하지만, 실제 S3 사용 코드에서는 거의 그대로 대체 가능했음. 여러 distribution/registry 인스턴스와 Grafana Loki·Mimir, influx3를 연결해 쓰는데, 설정 변경은 예상대로 키·시크릿·URL을 바꾸는 정도였음.

내가 만든 hs5는 바로 이런 용도로 설계함. https://github.com/uroni/hs5.
MinIO 등과 달리 객체를 개별 파일로 저장하지 않는 것이 특징이며, DuckDB도 직접 통합해 둠. README에는 Garage, SeaweedFS, RustFS, Ceph와의 비교가 있음.

개념적으로 단순해서 마음에 듦. 적어도 겉으로는 나도 이해할 수 있을 정도임. 서버를 중단하지 않고 index.lmdb와 data0를 안전하게 백업할 방법이 있음?

아직도 CNCF가 후원하는 S3 관련 활동이 없다는 게 아쉬움. 클라우드 네이티브 생태계에서 이렇게 중요한 부분인데, 규모 있는 활용 사례라면 어디든 바이너리 데이터를 저장할 방법이 필요함.
그렇다고 내가 직접 시작하거나 SeaweedFS 같은 프로젝트를 CNCF에 들어갈 만한 커뮤니티 지원 프로젝트로 만들려는 것도 아니니, 나 역시 책임에서 자유롭지는 않음.

동시성과 장애 후 데이터 일관성은 어떻게 처리함? 원자적 갱신이나 조건부 PUT 같은 동작을 범용 백엔드 위에서 올바르게 구현하기는 상당히 어려워 보임.

그냥 지나칠 뻔했는데, 스토리지·인증 플러그인 생태계가 훨씬 크고 짧은 소개만 보고 예상했던 것보다 전반적으로 성숙해 보임.

이전 직장에서 RustFS를 운영 환경에 사용함. 아카이빙 서비스의 백엔드였는데, 베어메탈 서버에서 잘 작동했고 기존 S3 API 사용 서비스와도 매끄럽게 통합됨.
다만 내부망에서 운영했으므로, 특히 본문에 나온 CVE를 고려하면 공개 인터넷에 노출해서 쓸 때는 결과가 다를 수 있음.