Два self-hosted S3, которые доверяют друг другу: DataSafeS3 v1.1.0

v1.1.0: убрали HTTP-костыль для sink’ов, закрыли /metrics, Teams в UI, trusted clusters. Про v1.0.3 и типичный «pairing failed» на Docker — внутри. Продолжение серии.

v1.1.0: убрали HTTP-костыль для sink’ов, закрыли /metrics, Teams в UI, trusted clusters. Про v1.0.3 и типичный «pairing failed» на Docker — внутри. Продолжение серии.

Первый публичный релиз DataSafeS3 (v1.0.0) вышел 24 июня 2026. За несколько дней после него — v1.0.1 и v1.0.2. Оба патча про исправления: для тех, кто уже крутит своё S3-хранилище не только на ноутбуке, но и в тестовом или боевом контуре.
DataSafeS3 — молодой open-source проект небольшой команды: своё хранилище файлов с S3 API, веб-консолью, пользователями, ролями и журналом действий — всё на вашем железе. Мы не MinIO и не конкуренты им — стремимся к доступному open source, который может поднять любой, кто умеет Docker и Linux. Зато честно пишем, что сломалось, что закрыли и что пока не успели.
Ниже — не CHANGELOG. Для каждого изменения: что болело, как это выглядело у вас, что мы поменяли.

За последние годы я несколько раз видел одну и ту же картину в небольших и средних компаниях. Для приложений поднимают S3-совместимое хранилище. Для людей — отдельный файловый сервис или сетевые шары. LDAP/OIDC живёт отдельно. Бэкапы — третий контур. Мониторинг — четвёртый. Всё работает, пока не приходит внутренний аудит или новый филиал с формулировкой: «нам нужен корпоративный диск с SSO, журналом и данными только у нас».

Всем читателям, привет! Хочется поделиться своим опытом по созданию Nginx reverse proxy для интересного кейса.
• Есть 1 ip и на него нацелено n доменов
• Есть n серверов (за NAT)
• Когда пользователь заходит на домен_1 попадает на сервер_1
• Когда пользователь заходит на домен_2 попадает на сервер_2
• Когда пользователь заходит на домен_n попадает на сервер_n