Self-hosted S3 после первого релиза: чему учат быстрые patch-версии

Первый публичный релиз инфраструктурного продукта почти никогда не бывает финальным. Особенно если это self-hosted S3-хранилище: пользователи запускают его в Docker, подключают клиенты, создают buckets, проверяют роли, загружают файлы и быстро находят сценарии, которые разработчики не учли.

Patch-версии после v1.0 — нормальная часть взросления проекта. Важно не скрывать проблемы, а быстро чинить, документировать и не ломать upgrade path.

Что критично для S3-like сервиса

У хранилища файлов есть несколько чувствительных зон:

• совместимость S3 API;
• авторизация и роли;
• журнал действий;
• стабильность загрузки больших файлов;
• корректная работа multipart upload;
• backup metadata;
• миграции схемы;
• понятный Docker deployment.

Если ломается UI — неприятно. Если ломается доступ к данным или права — это уже инцидент.

Роли и аудит

Self-hosted не значит «безопасность не нужна». Даже в маленькой команде важно видеть:

• кто создал bucket;
• кто скачал файл;
• кто поменял роль;
• кто удалил объект;
• какие ключи использовались;
• были ли ошибки доступа.

Audit log помогает расследовать ошибки и повышает доверие к проекту.

Совместимость API

S3 API стал фактическим стандартом. Пользователи ожидают, что будут работать SDK, CLI и интеграции. Но «почти S3» может сломаться на деталях: headers, signatures, edge cases, pagination, metadata.

Нужно иметь набор compatibility tests: AWS CLI, boto3, MinIO client, популярные SDK. Чем раньше такие тесты появятся в CI, тем меньше regressions после патчей.

Upgrade path

Patch-релиз должен быть безопасным. Пользователь должен понимать:

• можно ли обновиться без downtime;
• нужны ли миграции;
• как откатиться;
• какие настройки изменились;
• что делать с существующими данными.

Для инфраструктурного софта хороший release note иногда важнее новой фичи.

Docker и Linux

Если проект позиционируется как доступный self-hosted, запуск должен быть простым:

• docker compose;
• явные volumes;
• healthcheck;
• переменные окружения;
• пример reverse proxy;
• инструкция backup;
• минимальные требования к Linux.

Пользователь не должен угадывать, где лежат данные и что потеряется при пересоздании контейнера.

Итог

Быстрые v1.0.1 и v1.0.2 после первого релиза — не признак провала, а признак контакта с реальными пользователями. Главное — чинить прозрачно, укреплять тесты и не ломать данные.

Для self-hosted S3-проекта доверие строится на совместимости API, понятном upgrade path, ролях, аудите и честной документации.