Новий рівень зберігання файлів: Технічні деталі та ціна проєкту IceVault

💡 Усі статті, обговорення, новини про Python — в одному місці. Приєднуйтесь до Python спільноти!

Ця стаття є продовженням історії про пет проєкт з довгостроковим зберіганням файлів, в моєму випадку — сімейних фото. Хто не бачив першу частину можете почитати за посиланням dou.ua/forums/topic/58992. Завдяки зауваженням від коментаторів було виявлено деякі проблеми користувацького інтерфейсу, а також необхідні та неочевидні на перший погляд фічі. То ж я врахував всі недоліки і вивправив у поточній версії.

Фічі додані після попередньої статті

• BYO S3 (Bring Your Own S3), як мені здається найголовніша фіча для користувачів які хочуть контрольювати все і тримати в своєму сховищі. Цей інструмент дозволяє додавати свій бакет до зручного інтерфейсу, не переживаючи за свої файли, і в будь-який момент відмовитись від сервісу без необхідсності скачувати свої файли. При великих обємах це може бути навіть вигідніше.
• Покращений файловий оглядач. Додано вид списком, та деталізація файлів, можна обрати кілька файлів та видалити або перемістити в іншу колекцію всі обрані файли одним кліком.
• Додано API ключі. Для автоматизаторів ця фіча вкрай необхідна, можна робити бекап бази даних чи налаштувати регулярне завантаження файлів з компютеру. Разом з ключами додався Python SDK , зараз тільки базовий необхідний набір функцій для завантаження, скачування та видалення, в майбутньому бібліотека теж буде розвиватись
• Додана документація як випадаюче меню на сторінках сайту так і окрема сторінка з усією базою знань в одному місці.
• Поширення файлів. Це ще одна масивна безкоштовна функція для перекидання файлів по мережі. Використовує функціонал з шифрування файлів та byo s3. Розкажу як це працює нижче.
• SEO оптимізація та інше. Деякі користувачі відзначили схожість кольорової гами нашої темної теми з інтерфейсами «Матриці» та гри *Fallout*. Мені ця ідея сподобалась, тож я додав на сайт кілька тематичних великодок (easter eggs).

Стек та інструменти

Як я казав у минулій статті я інженер прорамміст і мій основний стек це Python, ця мова ідеально підходить для стартапів, швидкого прототипування та сервісів, які не потребують низькорівневих високошвидкісних обчислень. Основний фреймворк для створення сервісу я обрав Django, тому що з коробки має багато функціоналу що пришвидшить розробку бізнес логіки, а саме авторизація, зручна ORM, рендер шаблонів, генерація перекладів, та багато іншого. Хоча цей фреймворк не може похизуватись високою швидкодією та велике комюніті і безліч модулів перекриваюсь усі недоліки.

База даних — PostgreSQL, надійний робочий кінь, який не потребує додаткової реклами. Це перевірена роками система зберігання, яка бездоганно працює як локально, так і в інфраструктурі AWS.

• django — веб фреймворк
• django-ninja для створення api
• boto3 для взаємодії з AWS та інших S3 сховищ
• psycopg2 для роботи з базою данних
• pydantic для валідації запитів та відповідей
• resend для інтеграції з поштовим сервісом
• pyotp для генерації одноразових паролей для двухфакторної автентифікації
• django-allauth для авторизації за допомогою акаунтів соціальних мереж

Для обробки асинхронних фонових задач я наразі використовую звичайні cron-завдання (наприклад, очищення видалених файлів запускається раз на годину). Це просте, надійне рішення, яке дозволяє не перевантажувати сервер додатковими інструментами на кшталт Celery, Prefect чи Django Q. З ростом проєкту я, можливо, перейду на них, але поки черги невеликі — в цьому немає сенсу.

З фронтендом ситуація дещо складніша, оскільки досвіду тут у мене значно менше. Починалося все з простого шаблону для тестування завантаження файлів, і на ейфорії від першого робочого MVP я не приділив UI належної уваги. З часом логіка розросталася на чистому JavaScript. Було бажання переписати все на TypeScript + React, але брак часу та мотивація швидше релізити фічі перемогли.

Ось ключові фронтенд-бібліотеки, які використовуються в проєкті:

• tailwind — для гнучкої стилізації та підтримки тем
• axios — А для асинхронних запитів до бекенду
• alpine для легкого керування реактивністю та контекстними меню
• shepherd.js — для створення інтерактивних турів-підказок для нових користувачів
• claudflare проксі-рівень для захисту від DDoS та базової фільтрації
• ffmpeg для клієнтської генерації прев’ю відео (перші 10 секунд у якості 360p)
• browser-image-compression для стиснення та генерації прев’ю фото безпосередньо в браузері користувача
• zip.min.js для клієнтського пакування файлів в архів та встановлення пароля
• ag-psd для парсингу та зчитування прев’ю з важких файлів Photoshop (.psd).

Функціонал для створення превью та архіву і відпраки в S3 є вікритим кодом і можна ознайомитись в GitHub

Захист від ботів

Одразу після розгортання сервісу в публічному доступі на сервер полетіли автоматизовані сканери вразливостей. Цікаво, що більшість із них б’ють навпомацки — сканують внутрішні IP-адреси AWS, які я ніде публічно не світив. Це грає нам на руку: таких роботів можна сміливо банити з першого ж запиту, не боячись зачепити реальних користувачів.

Ось реальний приклад з логів нашого вебсервера:

216.73.216.15 - - [12/Jul/2026:13:21:34 +0000] "GET /robots.txt HTTP/1.1" 200 392 "-" "Mozilla/5.0... ClaudeBot/1.0"
216.73.216.15 - - [12/Jul/2026:13:21:35 +0000] "GET /sitemap.xml HTTP/1.1" 200 2831 "-" "Mozilla/5.0... ClaudeBot/1.0"
54.89.47.17 - - [12/Jul/2026:13:22:41 +0000] "GET / HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)..."
104.23.223.79 - - [12/Jul/2026:13:30:35 +0000] "GET /wp-admin/install.php?step=1 HTTP/1.1" 301 178 "-"
185.242.226.112 - - [12/Jul/2026:13:43:37 +0000] "\x16\x03\x01\x00\x8A\x01\x00\x00\x86\x03\x03..." 400 166 "-" "-"

Аналіз шкідливої активності:

1. Перші два запити — це «хороший» робот ClaudeBot від Anthropic. Він чемно сканує robots.txt та sitemap.xml. До нього питань немає, це потрібно для майбутнього індексування штучним інтелектом.
2. Третій запит прийшов на сервер за стороннім хостом (не через наш домен), тому вебсервер одразу розгортає його зі статус-кодом 444 (Connection Closed Without Response), і айпішник летить у бан.
3. Четвертий запит шукає стандартні скрипти WordPress (/wp-admin/...). Класичний сліпий брутфорс відомих CMS.
4. П’ятий запит — це взагалі бінарне сміття. Бот відправив шістнадцятковий (hex) код клієнтського привітання TLS Client Hello прямо на HTTP-порт. Він шукає застарілі вебсервери, які погодяться на таке рукостискання, щоб промапити потенційні вразливості. Сервер віддав 400 Bad Request.

Для боротьби з цим фоновим шумом інтернету я розгорнув Fail2ban з агресивними налаштуваннями. У нас діє правило «нульової толерантності»:

[Definition]
# Банимо миттєво, якщо:
# 1. Це методи HEAD, OPTIONS, PUT, DELETE, TRACE, CONNECT, DEBUG
# 2. Або це Gh0st RAT чи бінарне сміття (\x...)
# 3. І при цьому сервер повернув помилку (400, 401, 403, 404, 444)
failregex = ^<HOST> -.* "(HEAD|OPTIONS|PUT|DELETE|TRACE|CONNECT|DEBUG|Gh0st|\\x.*).*" (400|401|403|404|444)
            ^<HOST> -.* "(GET|POST) .*" (400|444)

за один такий запит бот отримає бан на добу:

[nginx-aggressive]
enabled  = true
port     = http,https
filter   = nginx-aggressive
logpath  = /var/log/nginx/access.log
backend  = polling
maxretry = 1
findtime = 3600
bantime  = 86400

Чому бан лише на 24 години, а не назавжди? Хакери та ботнети використовують VPN або орендовані та скомпрометовані лізингові сервери. Завдяки протоколу DHCP ці IP-адреси постійно ротуються і завтра можуть дістатися звичайному користувачу інтернету (адже ресурсів IPv4 на всіх не вистачає). Бан назавжди призвів би до хибних блокувань реальних людей у майбутньому.

Ось так виглядає наша «в’язниця» на практиці:

$ sudo fail2ban-client status nginx-aggressive
Status for the jail: nginx-aggressive
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     805
|  `- File list:        /var/log/nginx/access.log
`- Actions
   |- Currently banned: 110
   |- Total banned: 763

Є і інші вязниці але нехай вони залишаться без огляду.

Розумні боти та пастка «Honeypot»

Якщо зі сліпими сканерами все просто, то один випадок мене здивував. Бот повівся як реальна людина: зайшов на сторінку реєстрації, зчитав форму, почекав і відправив POST-запит. Навіть пройшов підтвердження через Django CSRF-токен!

Більшість запитів — це пошук замка до якого в ботів є ключі, але наступний запит мені меньш зрозумілий, бот веде себе майже як людина, заходить на сторінку реєстрації, заповнює форму та відправляє.

198.12.69.94 - - [12/Jul/2026:13:49:06 +0000] "GET /auth/register HTTP/1.1" 301 178 "-" "Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10240"
198.12.69.94 - - [12/Jul/2026:13:49:07 +0000] "GET /auth/register HTTP/1.1" 200 45057 "-" "Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10240"
198.12.69.94 - - [12/Jul/2026:13:49:27 +0000] "POST /auth/register HTTP/1.1" 301 178 "https://www.icevault.space/auth/register" "Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10240"

перший запит на http отримує redirect на сторінку з шифрованим протоколом https

другий запит отримує форму з кодом безпеки у джанго csrf

третій запит відправляє заповнену форму за допомогою POST запиту.

Одразу після цього почалася масова автоматична реєстрація фейкових акаунтів з реальними поштами відомих світових брендів. Ба більше — скрипти ботів автоматично зчитували листи активації на своїх інбоксах і переходили за лінками для підтвердження тріалу.

Щоб вирішити цю проблему без ускладнення UX для людей, я використав комбінацію Cloudflare Turnstile капчі та методу Honeypot (приховане поле). На сторінку реєстрації додається input-поле, яке за допомогою CSS повністю приховане від очей людини, але боти-парсери його бачать і автоматично заповнюють разом із логіном та паролем. Якщо на бекенд приходить форма із заповненим honeypot-полем — запит маркується як спам, а IP-адреса миттєво вирушає за ґрати.

Превью холодних файлів, суть проєкту

Головною фішкою це зберігарння файлів які не треба переглядати часто, можливо раз на рік або рідше. Для цього ідеально підходить холодне сховище що дає найвигіднішу ціну зберігання. Але нюанс в тому що скачати швидко не вийде, і ціна скачування вища за ціну зберігання. Для вирішення цієї проблеми я додав генерацію превью фото та відео на клієнті яке буде зберігатись у швидкому доступі. Оригінали завантажуються в Glacier Deep Archive, а превью на швидкому доступі з обмеженою якістю. На вибів припало до ока 2 варіанти AWS S3 Standard та AWS S3 Glacier Instant Retrieval (IR)

Враховуючи що превью не будуть видалятися та змінюватися і треба оптимізувати витрати я обрав AWS S3 Glacier Instant Retrieval (IR). А щоб зберегти кількість запитів до сервера на скачування та завантаження пакую все в архів без стиснення що дає додаткову можливість встановлення паролю на клієнті і навіть при потенційному витоці данних ніхто не зможе прочитати такий архів. Функція створення превью настільки гарно відпрацьовує що фото без втрати візуальної якості можна стиснути в 10-100 разів, особливо якщо ми говоримо про сирі фото з дзеркальних фотокамер.

Приклад коду стиснення фото у відкритому доступі за посиланням

    const compressor = window.imageCompression;
    const compressionOptions = {
      maxWidthOrHeight: config.maxWidthOrHeight,
      initialQuality: config.quality,
      fileType: config.outputFormat,
      useWebWorker: true,
      preserveExif: !config.exifOrientation, // If true, native browsers handle orientation realignment
    };
    return await compressor(imageSource, compressionOptions);

Відео як я вже казав ствоюється 10 секунд, що на мою думку достатньо для того щоб згадати що на ньому і вирішити чи треба скачати оригінали. Інші файли в превью створюються порожніми як маркер того що є в архіві з оригіналами, таким чином сервер нічого не знає про файли які ви зберігаєте — True zero knowlage

Я також планую додати інструмент для генерації превью у вільний доступ щоб згенерувати та скачати без зберігання, скажіть чи було б вам цікаво таким інструментом скористатись?

Як працює BYO S3 (Bring Your Own S3)

Ця функція дозволяє підключити сховище з будь-якого провайдеру який підтримує протокол S3. Тобто якщо ви хочете свій сервер зі збереження файлів з функціоналом IceVault то без питань можете підняти свій MinIO або придбати інший подібний бакет. Ось порівняльна таблиця з найбільш популярними сервісами, вони також дають безкоштовний ліміт з яким ви можете потестувати. В документації є інструкція з налаштуванням AWS та Cloudflare. Думаю з іншими провайдерами проблем теж не виникне.

Так як інші провайдери не підтримують холодне зберігання то оригінали ідуть в гарячий доступ і будуть доступні миттєво, і цьому режимі сенсу генерації превью немає, хіба що ви хочете зєкономити на трафіку. Тому на панелі завантаження зявився вибір КЛАСС_СХОВИЩА. Якщо ваш бакет підтримує холодне зберігання то буде доступний варіант DEEP_ARCHIVE . Якщо підключений зовнішній бакет то при завантаженні буде відображатись куди саме завантажуються файли — // ЦІЛЬОВЕ СХОВИЩЕ

Архітектура File Sharing

Завдяки впровадженню абстракції BYO S3, реалізувати логіку швидкого та безпечного шарингу файлів між користувачами було відносно просто. Ми виділили окремий системний бакет та прописали правила генерації тимчасових посилань.

Ініціалізація запиту. Клієнт повідомляє Django-бекенд про намір завантажити файл. Сервер перевіряє ліміти акаунту, ініціює сесію Multipart Upload на стороні S3-провайдера й повертає унікальний UploadId.

client = get_s3_client(bucket_id=bucket_id)
return client.create_multipart_upload(
    Bucket=bucket_name,
    Key=object_key,
    ContentType=content_type,
    StorageClass=sc,
    Metadata=metadata_fields,
)

Генерація підписаних лінків (Presigned URLs). Для кожного окремого чанка (шматочка) файлу бекенд генерує пряме підписане посилання з обмеженим часом дії.

url = client.generate_presigned_url(
    "upload_part",
    Params={
        "Bucket": bucket_name,
        "Key": object_key,
        "UploadId": upload_id,
        "PartNumber": part_number,
    },
    ExpiresIn=expires_in,
    HttpMethod="PUT",
)

Пряме завантаження. Браузер клієнта бере масив цих адрес і через асинхронні PUT-запити відправляє гігабайти даних напряму в хмару в обхід нашого Django-сервера. Це повністю знімає навантаження на мережевий інтерфейс та CPU нашого хостингу. Після успішного завершення Django надсилає фінальну команду на склеювання (complete_multipart_upload), і файл з’являється в системі.

result = client.complete_multipart_upload(
    Bucket=bucket_name,
    Key=object_key,
    UploadId=upload_id,
    MultipartUpload={"Parts": normalized},
)

СЕО оптимізація та просування

Досвіду в професійному маркетингу я не маю, тому більшість рішень приймав на основі документації та порад ШІ. Результати нашої Google Search Console за перші місяці роботи виглядають скромно

Відразу я додав сайт у Google Search Console, він ніяк не просуває але показує чи зявлявся сайт у пошуку, по яким ключовим словам були покази та які сторінки відвідали користувачі.

Мета теги. Це невидима додаткова інформація для соціальних мереж щоб підказати як краще показувати посилання на цей сайт

<meta property="og:title" content="...
<meta property="og:description" content="...
<meta property="og:site_name" content="...
<meta property="og:url" content="...
<meta property="og:type" content="...
<metaproperty="og:image"content="..

Файли для допомоги сканування сайту:

sitemap.xml — файл з усіма сторінками сайту, допомагає пошуковикам просканувати та проіндексувати веб ресурс

robots.txt — працює як набір правил для всіх автоматизованих сканерів, які відвідують сайт

Google Tag Manager (GTM) — допомагає автоматизувати збір аналітики по перегляду сайту, я ще розбираюсь як цим користуватись.

Існують інші сервіси та плагіни для аналізу сайту, наприклад я користуюсь плагіном Plerdy та намагався як умога більше балів набрати але деякі метрики плагін уперто не хоче бачити навіть якщо вони є, наприклад Terms page або Contact page

Мікророзмітка Schema.org (JSON-LD) — допомагає пошуковикам зрозуміти контент сторінки, наприклад це інформаційна сторінка, чи продаж товару або послуг.

Якщо у вас є практичний досвід виведення подібних Cloud/SaaS інструментів із «пісочниці» Google у топ пошуку — буду дуже вдячний за ваші поради та технічні рекомендації в коментарях!

Ціна та цінність проекту

Варто розрізняти поняття ціни та цінності, якщо в когось є сумніви то ось вам простий приклад.

Пляшка води наприклад коштує 50грн, коли навколо є у великому доступі і з високою конкурентністю то ціна може знижуватись, а якщо ви в пустелі де немає нічого і від води залежить виживання то цінність пляшки зростає до небес.

Часто розробники запитують про фінансовий бік таких розробок. Давайте відкрито підрахуємо реальні витрати та економічну маржинальність проєкту на поточному етапі.

• Розробка: Проєкт створюється самотужки у вільний від основної роботи час (ночами та на вихідних). Наразі активна фаза розробки триває близько 4 місяців. Тобто собівартість старту — це сотні годин роботи однієї людини в ролі архітектора, бекендера, фронтендера, дизайнера та системного адміністратора.
• Домен: Для старту я обрав зрозумілу назву — icevault.space. Вартість доменної зони .space символічна — лише кілька доларів на рік. Варіанти в зоні .com коштують від кількох тисяч доларів (через перекупників), що на етапі перевірки гіпотез є нерентабельним.
• Хостинг та сервери: Тут дуже допомагає Free Tier від AWS та спеціальні гранти для стартапів (кредити на інфраструктуру). Проте за моїми розрахунками, базове утримання мінімального робочого оточення сервісу (процесорний час сервера, база даних PostgreSQL, мережеві запити без урахування дисків зберігання) коштує близько 10—15$ на місяць.

Схема розрахунку тарифних планів формувалася з урахуванням офіційної сітки тарифів AWS:

• Зберігання Glacier Deep Archive (GB/міс): $0.00099
• Зберігання Glacier Instant Retrieval (GB/міс): $0.004
• Зберігання S3 Standard (GB/міс): $0.023
• Запити PUT (за 1000 шт): $0.05
• Відновлення даних з GDA (за ГБ): $0.02
• Відновлення даних з GIR (за ГБ): $0.03
• Вихідний трафік (Data Transfer Out / за ГБ): $0.09

Оскільки прев’ю займають не більше 10% обсягу оригіналів, а найдорожчою статтею витрат в AWS є вихідний трафік (Data Transfer Out), ліміти на скачування в сервісі є доволі суворими. Проте ми зробили їх чесними: невикористаний ліміт скачування не згорає наприкінці місяця, а накопичується і переноситься на наступний період.

Що далі?

У нашому беклозі ще багато амбітних планів:

1. Розробка легкого мобільного додатка для автоматичної синхронізації фотогалереї смартфона.
2. Створення реферальної програми та системи вебхуків (Webhooks) для інтеграції з домашніми скриптами користувачів.
3. Функція планового автоматичного видалення тимчасових архівів (зручно для ротації бекапів серверів).
4. Організація спільного сімейного або корпоративного сховища з гнучким розподілом прав доступу.

Буду радий почути ваші відгуки, критику архітектурних рішень та ідеї щодо розвитку проєкту. До зустрічі в коментарях!