S3-хранилище: Garage или MinIO — что выбрать в 2026

Почему это вообще актуально прямо сейчас

Ещё в 2024 году выбор self-hosted S3-совместимого хранилища был предсказуем: берёшь MinIO, разворачиваешь за 10 минут, получаешь удобную веб-консоль и живёшь спокойно. В 2025-2026 году эта картина рассыпалась.

В мае 2025 MinIO вырезал из community-версии почти весь функционал администрирования в консоли — управление пользователями, политиками доступа, жизненным циклом объектов. Осталась только базовая просмотрелка файлов, всё остальное — через mc (CLI). В декабре 2025 проект перешёл в режим "maintenance mode", а в феврале 2026 репозиторий MinIO на GitHub был официально заархивирован — новые issue, pull request'ы и правки безопасности больше не принимаются. Полнофункциональная версия с консолью теперь называется MinIO AIStor и стоит от $96 000 в год.

Для тех, кто строил инфраструктуру на MinIO, это неприятный сюрприз. Для тех, кто только выбирает — хороший повод присмотреться к Garage.

Что такое Garage

Garage — S3-совместимое объектное хранилище, написанное на Rust, разрабатываемое французской некоммерческой организацией Deuxfleurs. В отличие от MinIO, который изначально целился в производительность и корпоративный рынок, Garage с самого начала проектировался под другую задачу: самостоятельный хостинг на разномастном оборудовании — старых серверах, домашних NAS, географически разнесённых узлах с нестабильной связью между ними.

Ключевые архитектурные решения:

• Метаданные хранятся в SQLite или LMDB — никакой отдельной базы поднимать не нужно
• Репликация рассчитана на узлы с разной производительностью и связью, а не только на однородный кластер в одном дата-центре
• Проект живёт на грант NGI0/NLnet (европейское финансирование open-source инфраструктуры), а не на венчурные деньги — модель монетизации не толкает проект к внезапному закрытию функций

Разница в администрировании — ключевой момент сравнения

Здесь начинается самое важное для практического выбора.

MinIO (сейчас): веб-консоль работает только в режиме просмотра объектов. Управление пользователями, ключами доступа, политиками и жизненным циклом бакетов доступно только через mc admin в терминале — то есть ровно то, что раньше делалось кликами, теперь требует команд.

Garage (по умолчанию): ядро Garage изначально не поставляется с веб-консолью — управление идёт через CLI (garage bucket create, garage key create и т.д.) и Admin API. Это не деградация функционала, а исходный дизайн: минималистичное ядро, разделённое с интерфейсом.

Garage + garage-webui: сообщество закрыло этот пробел отдельным проектом garage-webui — веб-интерфейс для управления кластером, бакетами и ключами доступа, разворачивается отдельным Docker-контейнером рядом с самим Garage. Плюс у Garage есть официально профинансированный (тот же грант NLnet) проект админ-интерфейса, который со временем должен стать частью экосистемы.

Разница принципиальная: у MinIO админку отобрали, у Garage её изначально не было в ядре, но комьюнити добавило отдельно — и никто не может её "отобрать" повторно, потому что это независимый open-source проект.

Сравнение по практическим параметрам

Практический пример — установка Garage с веб-интерфейсом

# docker-compose.yml
services:
  garage:
    image: dxflrs/garage:v2.0.0
    container_name: garage
    volumes:
      - ./garage.toml:/etc/garage.toml
      - ./meta:/var/lib/garage/meta
      - ./data:/var/lib/garage/data
    restart: unless-stopped
    ports:
      - "3900:3900"   # S3 API
      - "3901:3901"   # RPC (между узлами кластера)
      - "3902:3902"   # S3 Web (статический хостинг из бакета)
      - "3903:3903"   # Admin API

  garage-webui:
    image: khairul169/garage-webui:latest
    container_name: garage-webui
    restart: unless-stopped
    volumes:
      - ./garage.toml:/etc/garage.toml:ro
    ports:
      - "3909:3909"
    environment:
      API_BASE_URL: "http://garage:3903"
      S3_ENDPOINT_URL: "http://garage:3900"

Минимальный garage.toml:

metadata_dir = "/var/lib/garage/meta"
data_dir = "/var/lib/garage/data"
db_engine = "sqlite"
replication_factor = 1  # для одного узла; для кластера — 3

[rpc]
bind_addr = "[::]:3901"
rpc_secret = "сгенерируй-через-openssl-rand-hex-16"

[s3_api]
s3_region = "garage"
api_bind_addr = "[::]:3900"

[s3_web]
bind_addr = "[::]:3902"
root_domain = ".web.example.com"

[admin]
api_bind_addr = "[::]:3903"
admin_token = "сгенерируй-отдельный-секрет"

После запуска — создание ключа и бакета через CLI (веб-интерфейс появится на порту 3909):

docker compose exec garage garage key create my-key
docker compose exec garage garage bucket create my-first-bucket
docker compose exec garage garage bucket allow my-first-bucket --key my-key

Что выбрать

Оставаться на MinIO стоит, если у вас уже развёрнутый кластер, всё работает, а бюджет позволяет либо жить с CLI-администрированием, либо перейти на AIStor. Также вариант — community-форки (например, форк с восстановленной консолью на базе последней открытой версии), но здесь придётся самому отслеживать патчи безопасности, так как официальной поддержки больше нет.

Переходить на Garage стоит, если: - Разворачиваете хранилище с нуля - Важна ясность лицензии и предсказуемость развития проекта на годы вперёд - Устраивает связка "ядро + отдельный веб-интерфейс от комьюнити" вместо монолитного продукта - Планируется гео-распределённая репликация между несколькими локациями с разным железом

Присмотреться к альтернативам (SeaweedFS, RustFS) стоит, если нужна максимальная производительность на больших объёмах — но это тема отдельной статьи, обе не так широко проверены в проде, как Garage.

Итог

История MinIO — хороший урок: при выборе self-hosted инфраструктуры важна не только текущая функциональность, но и модель развития проекта. Garage, живущий на грантовом финансировании без давления инвесторов, в 2026 году выглядит более предсказуемым долгосрочным выбором для небольших и средних self-hosted инсталляций, даже с учётом того, что веб-интерфейс — это отдельный сторонний проект, а не часть ядра.