MinIO забросили: автор сравнил 6 альтернатив для локального S3

В конце 2025 года компания, стоящая за MinIO, решила забросить проект ради других коммерческих направлений. Для множества демо-стендов и пайплайнов сборки, которые использовали MinIO как локальную эмуляцию S3-хранилища, это стало проблемой: привычный инструмент перестал развиваться. Автор блога rmoff решил протестировать доступные замены и найти простейший вариант для локального однонодового развёртывания.

Критерии отбора: обязательно готовый Docker-образ (большинство демо разворачивается через Docker Compose), обязательная совместимость с S3 API, бесплатность с явным предпочтением открытой лицензии по определению OSI (например Apache 2.0), простота настройки на одном узле и наличие живого сообщества или коммерческого «хозяина» проекта, чтобы не пришлось повторять этот поиск через полгода. Плюсом считалось удобство для разработчика: простая конфигурация, хорошая документация. Многоузловые и распределённые развёртывания, продакшен-поддержка и графический интерфейс в расчёт не брались, только сценарий локальных демо.

Отправная точка, простой стенд на Docker Compose: DuckDB читает и пишет данные в формате Iceberg, которые хранятся в S3-совместимом хранилище, сначала предоставленном MinIO. Автор поочерёдно подставлял в этот же стенд каждую альтернативу, стараясь менять как можно меньше кода, и проверял результат тем же тестовым скриптом.

Результаты по каждому кандидату. S3Proxy (версия 3.0.0): Docker-образ с более чем 5 млн загрузок, лицензия Apache 2.0, настройка очень простая, автор решил использовать его. RustFS (версия 1.0.0-alpha.79): образ с более чем 100 тыс. загрузок, лицензия Apache 2.0, есть собственный графический интерфейс, настройка даже проще, чем у S3Proxy, но проект совсем новый и в альфа-статусе, вердикт «возможно, но пока рано». SeaweedFS (версия 4.06): образ с более чем 5 млн загрузок, лицензия Apache 2.0, простая настройка, есть собственный базовый веб-интерфейс; S3-совместимость в проекте появилась ещё в версии 0.91 в 2018 году, хотя сайт выглядит скорее как коммерческий продукт («SeaweedFS Enterprise») без явной ссылки на GitHub. Сразу после публикации блога аккаунт SeaweedFS в X (Twitter) ответил автору, что отмеченное им неудобство конфигурации уже устранено и войдёт в ближайший еженедельный релиз. Автор решил использовать SeaweedFS. Zenko CloudServer (версия 9.2.8, ранее известный как S3 Server, часть набора инструментов Zenko от компании Scality): образ с более чем 5 млн загрузок (включая устаревшие образы на Docker Hub), лицензия Apache 2.0, настройка простая, но автора поначалу запутали пересекающиеся названия cloudserver/zenko/scality, итоговый вердикт «пожалуй, да». Garage (версия 1.0.0): образ с более чем 1 млн загрузок, лицензия AGPL; настройка оказалась сложной, помимо основного контейнера потребовался отдельный контейнер для первичной инициализации и TOML-файл конфигурации, а формат идентификаторов ключей доступа (обязательно начинается с «GK» и 12 байт в шестнадцатеричном виде) оказался неочевидным, автору пришлось обращаться за помощью к знакомому. Итог, отказ: конфигурация слишком сложна для этой задачи. Apache Ozone (версия 2.1.0): образы с более чем 1 млн загрузок, лицензия Apache 2.0; проект выделен из Apache Hadoop в 2020 году, а изначально создавался как часть проекта HDFS ещё в 2015-м. Ни автору, ни использованному им ИИ-помощнику Claude не удалось развернуть Ozone менее чем на четырёх узлах, однонодовый локальный вариант здесь фактически недостижим, итог, однозначный отказ. Ceph Object Gateway автор даже не стал тестировать: после знакомства с инструкцией по установке решил, что инструмент слишком тяжеловесен для его задачи.

Из всех рассмотренных проектов только Apache Ozone принадлежит фонду (Apache Software Foundation), лицензии остальных в теории может в любой момент изменить сама компания-разработчик, как это уже произошло с MinIO. Отдельно автор отмечает риск зависимости от одного человека: у части проектов долгая и здоровая история, но развивает их фактически один активный участник, и неясно, подхватит ли их сообщество, если этот человек уйдёт.

В дополнении к посту автор указывает на два события уже после публикации: 30 января 2026 года разработчик Justin Cormack написал отдельный разбор технических деталей и возможностей RustFS и Garage, а 2 марта 2026 года разработчик Ruohang Feng форкнул сам MinIO в проект pgsty/minio, пообещав поддерживать стабильный дистрибутив с патчами уязвимостей (CVE).

Ключевые факты

• Компания-владелец MinIO в конце 2025 года решила забросить проект ради других коммерческих задач, из-за чего демо-стенды и пайплайны сборки, полагавшиеся на MinIO для локальной эмуляции S3, остались без обновляемой замены.
• Автор протестировал шесть альтернатив в одном и том же стенде на Docker Compose (DuckDB и формат Iceberg поверх S3-хранилища): S3Proxy, RustFS, SeaweedFS, Zenko CloudServer, Garage и Apache Ozone; Ceph Object Gateway отсеян ещё до теста как слишком тяжеловесный.
• Простейшими заменами названы S3Proxy и SeaweedFS, оба на лицензии Apache 2.0, с более чем 5 млн загрузок Docker-образа и минимальной настройкой; RustFS отмечен как перспективный, но пока альфа-версия.
• Garage (лицензия AGPL) и Apache Ozone оказались слишком сложны для локального сценария: Ozone не удалось развернуть меньше чем на четырёх узлах даже с помощью Claude.
• Только Apache Ozone принадлежит фонду (ASF), остальные проекты в теории могут сменить лицензию так же, как это сделала MinIO; отдельно назван риск зависимости от одного разработчика.

Почему это важно

MinIO много лет был стандартным способом эмулировать S3-хранилище в локальных демонстрациях, тестовых стендах и пайплайнах сборки, просто поднял контейнер и получил S3-совместимый API без облачного аккаунта. В конце 2025 года компания, стоящая за MinIO, решила забросить проект ради других коммерческих задач, и всем, кто строил инфраструктуру вокруг него, пришлось искать замену. Пост разбирает, что из открытых альтернатив реально можно поставить вместо MinIO без больших переделок.

Кому это важно

Прежде всего, разработчикам и дата-инженерам, у которых в демо, CI/CD или обучающих стендах S3 эмулируется через Docker (в примере автора, связка DuckDB и формата Iceberg поверх S3-хранилища). Материал также полезен всем, кто выбирает инфраструктурный open-source проект и хочет заранее понимать риски вроде смены лицензии, ровно то, что произошло с MinIO, или ухода единственного мейнтейнера.

Как это применить

Для простой однонодовой замены MinIO автор рекомендует S3Proxy или SeaweedFS, у обоих открытая лицензия Apache 2.0, готовый Docker-образ с миллионами загрузок и минимум правок в конфигурации. RustFS стоит держать в поле зрения, но использовать с осторожностью, проект пока в альфа-версии. Zenko CloudServer работает, но из-за того, что это часть более крупного набора инструментов Scality, настройка воспринимается менее прозрачной. Garage и Apache Ozone для этой задачи автор не рекомендует: обе системы рассчитаны на более сложные сценарии, а не на быструю локальную замену.

Можно ли доверять

Автор не просто сравнил документацию, а реально прогнал один и тот же рабочий стенд (DuckDB, Iceberg, Docker Compose) с каждой из альтернатив вместо MinIO и описал, что именно пришлось поменять. Это личный практический опыт одного разработчика, а не формальный бенчмарк: сравнение ограничено удобством настройки, лицензией и числом загрузок Docker-образа, без замеров производительности и без проверки многоузловых или продакшен-сценариев, сам автор это оговаривает.

Риски и подводные камни

Из всех рассмотренных проектов только Apache Ozone принадлежит фонду (Apache Software Foundation); лицензии остальных в теории может в любой момент изменить сама компания-разработчик, именно так поступили с MinIO. Часть проектов держится на одном активном участнике, и неочевидно, подхватит ли их сообщество в случае его ухода. Garage и Apache Ozone требуют значительно более сложной настройки, чем остальные варианты, а RustFS, совсем молодой проект в альфа-статусе, пригодный скорее для отслеживания, чем для немедленного внедрения.

«Это уже реализовано и войдёт в ближайший еженедельный релиз.»

— аккаунт SeaweedFS в X (Twitter), в ответ на пост автора