MinIO が「ローカルで S3 を使うための定番」として置かれてきた場面は多いですが、その前提が揺らいだことで、代替候補を探す動きが一気に現実味を帯びました。この記事は、単一ノードで動くローカル S3 を前提に、Docker Compose へ差し込みやすい置き換え先を実際に試した記録です。単に「動くか」ではなく、「どれだけ MinIO の穴埋めとして自然か」をかなり厳しめに見ています。だからこそ、デモや検証環境を回している人にはかなり実用的な話です。
元記事の出発点は、2025年後半に MinIO の会社側が商業的な方向へ舵を切り、MinIO を使ったローカル S3 のデモや、S3 互換性を確かめる build pipeline が少し面倒になった、という事情です。筆者はそこで「単一ノードのローカル S3」として MinIO の代替を探します。ただし条件はかなり絞っていて、Docker image があること、S3 互換であること、無料で使えてできれば OSS ライセンスであること、1台構成で簡単に動くこと、そして継続性が見えやすいことを重視しています。multi-node や分散ストレージ、運用コスト、GUI の充実度は今回の対象外です。
検証の土台は、DuckDB と Iceberg REST Catalog を使い、S3 上の Iceberg データを MinIO に置くシンプルな Docker Compose です。DuckDB から INSERT INTO cat.test.products VALUES (1, 'Widget', 9.99), (2, 'Gadget', 19.99), (3, 'Doohickey', 14.99); を流すと、データは Parquet や Avro、snapshot ファイルとして S3 側に書かれます。MinIO では mc ls で warehouse/test/products/data/ 以下に実体が見え、記事中の test.sh で、投入前後のバケット内容と DuckDB からの読み戻しを確認できるようにしています。
そこから代替候補を順に試していきます。S3Proxy は Docker image があり、Apache 2.0 で、S3 互換性もあり、設定もかなり簡単でした。軽量で扱いやすい一方、内部で使っている jclouds が 2025 年半ばに Apache Attic へ移されており、気にする人は気にするだろう、と筆者は触れています。RustFS は設定が簡単で Apache 2.0、S3 互換もあり、Docker image もあるものの、最近かなりよくないセキュリティ脆弱性が見つかったこと、まだ alpha リリースであることが気になるとしています。SeaweedFS も同様にかなり素直に差し替えられ、Docker image も豊富で Apache 2.0、S3 互換あり。さらに、後からプロジェクト側が「初期設定の追加要件を外す予定だ」と反応しており、使いやすさはさらに上がりそうだ、と補足されています。
一方で Zenko CloudServer は、MinIO からの差し替え自体はしやすいものの、名称が cloudserver / zenko / scality と入り組んでいて最初は少し分かりづらかったようです。Garage はもっと厳しく、初期設定のために別コンテナまで必要で、TOML 設定も要るため、ローカルデモ用途には面倒すぎると判断されています。Apache Ozone は、S3 互換ではあるものの、少なくともこの用途では重く、筆者も Claude も 4 ノード未満での構成をうまく組めなかったといいます。Ceph Object Gateway は、インストール手順を見た時点で対象外にした、というかなり率直な扱いでした。
比較表では、各候補の設定のしやすさ、ライセンス、商用バックエンドやガバナンス、Docker pulls、GitHub stars、初回コミット時期、主要コミッター数などが並べられ、筆者は見た目の新しさだけでなく、継続性や採用のしやすさまで見ていることを示しています。結論としては、MinIO の「単一ノードのローカル S3」としての代替なら、S3Proxy、SeaweedFS、場合によっては Zenko CloudServer が現実的で、Garage、Ozone、Ceph はこの用途には重すぎる、という整理です。
この記事でいちばん面白いのは、性能でも機能でもなく、「置き換えの手間」を中心に比較している点です。普通、S3 代替の話になると、分散できるか、冗長化できるか、スループットはどうか、といった本番向けの話に寄りがちです。でもここで本当に効いているのは、Docker Compose に1個足して、既存のデモがそのまま動くかどうかでした。そこを基準にすると、Garage や Ozone のような“ちゃんとしている”ソフトが急に重たく見えてくる。これは少し皮肉ですが、デモ用途では非常に正しい見方だと思います。
とくに印象的なのは、筆者が Garage についてかなり素直に「Do I have better things to do with my time? Also, yes.」と書いているところです。これは単なる愚痴ではなく、ローカル検証の世界では、優れた設計よりも初期導入の摩擦の小ささが勝つ、という現実をよく表しています。良いプロダクトでも、最初の1回が面倒だと、デモや CI では選ばれません。逆に S3Proxy や SeaweedFS のように、「とりあえず動かす」までの距離が短いものは、実力以上にありがたく見えるはずです。
SeaweedFS の扱いがかなり良いのも納得感があります。設定は大きく複雑化せず、auth のために別ファイルが要るとはいえ、筆者はそれを Docker Compose に埋め込んで済ませています。しかも、記事公開直後にプロジェクト側が「その追加要件は外す」と反応した。こういう反応の速さは、ローカル開発者にとってかなり大きいです。技術的に正しいだけでなく、「今の困りごと」をちゃんと見ている感じがあるからです。
一方で、SeaweedFS のサイトがやや分かりにくく、ぱっと見で OSS だと気づきづらいという指摘もあります。これは地味ですが重要です。ローカル用途の道具は、実際の機能だけでなく、見つけやすさや初見の安心感も評価に入ります。README で迷わせる製品は、どんなに中身が良くても採用されにくい。筆者が「簡単に差し替えられる」ことを強く評価したのは、まさにそこだと思います。
RustFS は、少なくとも表面上はかなり魅力的です。Docker image があり、Apache 2.0 で、S3 互換もあり、設定も簡単。ところが、最近の重大なセキュリティ脆弱性の存在、alpha であること、そしてウェブサイトのリンク構造に“新しいプロジェクト感”が強く出ていることが、筆者の評価を下げています。これは過剰反応というより、実務的な警戒でしょう。デモ用のローカル S3 とはいえ、CI や開発環境で継続して使うなら、未成熟さはそのまま運用リスクになります。
私もここはかなり同意します。ローカル用途だから脆弱性を無視してよい、とはならないからです。特に Docker Compose に入れてしまうと、気軽さの代わりに更新漏れが起きやすい。見た目が整っていて設定も楽な新興プロジェクトほど、しばらくは「試す」ことと「採用する」ことを分けて考えたほうがいい。RustFS は前者には向いていても、後者にはまだ慎重さが要る、というのが自然な読みです。
この記事は代替候補の紹介に見えますが、実際には「MinIO の代わりは何でもいいわけではない」と言っています。必要なのは S3 互換だけではなく、既存の demo や test を壊さず、初期導入が軽く、しばらくは安心して置いておけることです。そうなると、分散型で高機能な製品はむしろ不利になります。ローカル S3 の世界では、壮大な設計よりも、手元での雑な実験を支えてくれる気楽さのほうが価値を持つからです。
この見方は、MinIO の後継探しに限らず、開発ツール全般に当てはまると思います。便利そうな新機能が増えるほど、設定や依存関係が重くなり、結局「何も考えずに立ち上がる」道具が勝つ。筆者が S3Proxy と SeaweedFS を上位に置いたのは、その現実を正面から見たからでしょう。MinIO を失ったこと自体は面倒ですが、代替候補を見比べることで、ローカル環境では何が本当に大事かがむしろはっきりした、というのがこの記事の面白さだと思います。
