У нас есть несколько сервисов, где пользователи загружают файлы, отправляют файлы, обмениваются файлами. И делать в каждом сервисе свой сервер, где можно было бы получить ссылку на файл, передать через очередь, отправить, обработать - может быть не надо? В одном сервисе - это загрузка аватарок, в другом - это различные пользовательские файлы, по сути в транзите, в третьем - это файлы, загружаемые для конфигурирования сервиса, используются время от времени.  В каждом сервисе надо было делать директорию для файлов, следить чтобы там было достаточно места, выставить права на запись, монтировать или синхронизировать с хранилищем по необходимости. Поэтому появился filebump - простой http сервер, где мы можем загружать, хранить и скачивать файлы. В принципе, это простая файлопомойка. Куда можно скинуть файл и позже забрать его. Возможно, неоднократно. Сервис выполняет одну функцию - хостинга файлов по API. Схема работы:  у вас в сервисе появился файл (или от пользователя, или прилетел с другого сервиса),  вы сохраняете файл в filebump,  в сервисе сохраняете полученныую ссылку от filebump, по потребности загружаете файл с filebump, или отправляете ссылку на файл в filebump. Чем‑то напоминает пользовательские файлопомойки в расшаренных директориях в локальной сети. Но здесь нет API, которое показывает все файлы на filebump. Только что загрузил — на то и получил свою уникальную ссылку. Сохранил? Да, тогда можешь использовать. А если нет, то все файл где‑то там канул в filebump'е. Есть два метода — загрузка файла (upload) и загрузка файла по url (download).  Upload file — загрузкой файлов вы пользуетесь, когда у вас уже есть файл.  Download file — а загрузкой файла по url вы пользуетесь, например, когда вам прилетела ссылка с файлом, и вместо того чтобы скачать и зааплоадить на filebump, вы поручаете эту загрузку самому filebump.  Загружать можно любые файлы. Да, вполне, работает схема полтора года. Сейчас немного причесал и добавил в npm клиента. Удобно. Каждый день прилетают сотни файлов, сотни и тысячи файлов скачиваются. В разрабатываемых проектах просто подключаете клиент filebump'а, и просто работаете по сути только со ссылками на файлы. В некоторых случаях все файлы как бы вообще мимо разрабатываемого сервиса проходят. Использую во внутреннем периметре. Также есть ключи, т. е. http‑запросы для upload'а и download'а обязательно содержат API‑key. Чтобы никто посторонний не начал лить свои файлы. У каждого сервиса, работающего с filebump, свой ключ. Список ключей задается в конфиге. Улучшать можно много чего. Во‑первых, схему хранения файлов. Если их много, то надо как‑то оптимизировать структуру директорий. Сейчас обхожусь тем, что просто удаляю все файлы старше 3-х месяцев скриптом по крону. Во‑вторых, хочу разделить на зоны хранения файлов. т. е. часть файлов хочется хранить долго (вечно), а часть как транзитные файлы, которые нужны только чтоб скачать и отправить дальше, то их можно удалять. Тут или метод добавить, или также по крону в этой зоне хранения просто чистить файлы. Либо пока просто раздельные filebump'ы поставить и сделать свои условные политики хранения файлов. В‑третьих, добавить таки UI и аналитику. Для управления, подсчетов, какой‑то визуализации. В репозитории проекта — docker‑compose.yml, в котором есть пример настройки filebump. Образ filebump есть на docker hub. Подробнее по методам, установке и коду — в гитхабе проекта filebump, написан на javascript под node.js. Была мысль переписать на Go, чтоб докер образ был не такой жирный. Но, вероятно, если сильно заморочиться да еще и на хотелки и улучшения, то получится какой‑нибудь аналог s3 хранилища. Идеи, мнения приветствуются. Может и не воспользуетесь, но наведет на какую‑то дельную мысль — тоже буду рад ))