Self-host vs cloud в Україні під час війни: мій вибір і технічна логіка

«А що буде з ботом, якщо відключать світло?»

Це питання мені ставлять потенційні клієнти частіше, ніж будь-яке інше технічне питання. І це правильне питання. Не тривожне, не надумане — цілком раціональне для бізнесу, який живе в Україні у 2026 році.

Я хочу відповісти на нього чесно. Не в стилі «ми гарантуємо 99.9% uptime» — а з поясненням реального вибору, який я зробив, і чому.

Контекст: будувати SaaS в Україні у 2024–2026

Коли я починав будувати Leadmlyn, однією з перших технічних задач було вирішити: де живе продукт.

Україна 2024–2026 — це специфічна операційна реальність для технологічного бізнесу. Масові відключення електрики у 2022–2023 залишили слід у тому, як всі тут думають про надійність. Ракетні удари по енергетичній інфраструктурі — не абстрактний ризик, а подія, яку бізнеси планують у своїх операціях.

Дата-центри в Україні мають генератори. Великі — добрі генератори і дублювання каналів. Але «великий UA дата-центр» — це все одно одна точка фізичного зосередження в одній країні, яка перебуває в активному збройному конфлікті.

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

Я думав про це серйозно і прийняв конкретне рішення.

Мій вибір: cloud-first і чому

Leadmlyn живе на AWS. Не в Україні — в регіонах AWS за межами країни.

Це було свідоме рішення, і ось логіка.

Надійність AWS >> локальний сервер під час відключень. Навіть найкращий UA дата-центр з генератором залежить від фізичної безперервності в одній точці. AWS — це глобально розподілена інфраструктура з резервуванням, яке я не можу відтворити самостійно ні за які гроші на своєму масштабі. Availability zones, автоматичний failover, глобальні мережі доставки контенту — все це вже є і коштує адекватно.

Коли відключають світло у клієнта — бот продовжує відповідати в Telegram, бо Telegram на телефоні клієнта на батареї, а сервери Leadmlyn — в Ірландії або Франкфурті. Власник бізнесу може не мати інтернету, але його клієнти, у яких є мобільний інтернет, продовжують отримувати відповіді.

Це саме та ситуація, де cloud-first дає реальну перевагу.

Відсутність потреби у фізичному доступі. Self-host означає, що десь є сервер. Цей сервер треба обслуговувати, оновлювати, перезавантажувати, замінювати диски. Якщо сервер у офісі клієнта — він ділить долю офісу. Якщо в окремому дата-центрі — треба туди їхати або мати агента. У воєнний час, у місті де оголошують тривогу — це не теоретична складність.

Я можу управляти всією інфраструктурою Leadmlyn дистанційно, з будь-якої точки, через браузер. Це і зручність, і безпека — і бізнес-безперервність.

Backup і версіонування без зусиль. AWS S3, RDS automated backups, point-in-time recovery — все це є за замовчуванням або налаштовується за кілька рядків конфігурації. Self-hosted PostgreSQL з ручним бекапом на зовнішній диск — це не те саме.

Де self-host міг би мати сенс — і чому я все одно обрав хмару

Я розумію привабливість self-host. І вона реальна.

Дані на власному залізі — повний контроль. Жоден AWS, Google чи Microsoft не має доступу до ваших даних навіть теоретично — якщо ви все правильно налаштували і шифруєте. Це важливо для певних категорій бізнесів: медицина, юриспруденція, фінанси, де є специфічні вимоги до локалізації даних.

Для leisure — квест-кімнат, фітнес-клубів, SPA — цей аргумент не переважує. Дані клієнтів leisure-бізнесу чутливі, але не настільки, щоб вимагати ізольованого залізного сховища. Ризик витоку через неправильно налаштований self-hosted сервер без регулярних оновлень — реально вищий, ніж ризик витоку через AWS з правильним IAM і шифруванням.

Є ще один аспект self-host, який часто недооцінюють: вартість операційного обслуговування. Self-hosted рішення потребує DevOps або людини, яка розуміється на Linux, nginx, SSL-сертифікатах, оновленнях безпеки. Для leisure-бізнесу, де власник — це одна людина, яка одночасно директор, бухгалтер і маркетолог — self-hosted AI-сервер це додаткова зона відповідальності, яка рано чи пізно стане вразливим місцем.

Мій висновок для Leadmlyn: self-host не дав би безпеки, яку обіцяє, але взяв би в обмін надійність і операційну простоту, які cloud дає.

Що я зробив для надійності в умовах UA-реалій

Хмара — не магія. Неправильно налаштований cloud-продукт може бути ненадійнішим за добре налаштований self-hosted сервер.

Ось що конкретно зроблено.

Multi-region. Основна база Leadmlyn не лежить в одному регіоні AWS. Критичні дані реплікуються. Якщо один регіон деградує — трафік переключається.

Async обробка критичних задач. Нагадування клієнтам, оновлення бронювань — це async черги, а не синхронні запити. Якщо сервер завантажений або тимчасово недоступний — задача не губиться, а стає в чергу і виконується коли ресурс відновлюється.

Graceful degradation. Якщо LLM-провайдер (OpenAI або інший) тимчасово недоступний — бот не падає з помилкою 500. Він відповідає клієнту що тимчасово не може обробити запит і просить написати пізніше. Це не ідеально, але краще ніж тиша.

Моніторинг і алерти без ручного нагляду. Якщо що-небудь деградує — я отримую сповіщення до того, як клієнт це помітить. Не ідеально — але значно краще ніж «клієнт написав що бот не відповідає».

SMS-алерт при низькому wallet. Окрема проблема UA-реалій: власник може не перевіряти дашборд щодня. Якщо wallet наближається до нуля — приходить SMS на телефон. Не листа, який загубиться, — SMS.

Все це не дає 100% uptime. Нічого не дає 100% uptime. Але це зменшує ризики до рівня, де бізнес може функціонувати навіть у нестабільних умовах.

Рекомендація для UA-бізнесів що думають про self-host

Якщо ви бізнес в Україні і думаєте «може, поставити свій сервер» — ось мій чесний погляд.

Якщо у вас немає генератора, стабілізованого живлення, ДБЖ і технічного спеціаліста, який обслуговує цей сервер — self-host у 2026 в Україні це ризик, а не безпека. Ви можете думати, що даєте бізнесу незалежність, але насправді створюєте єдину точку відмови з фізичним доступом в одній локації.

Cloud — не панацея. Але cloud з правильно налаштованим резервуванням, шифруванням і моніторингом — надійніший за більшість self-hosted рішень, які я бачив у малому бізнесі.

Питання не в тому, де фізично знаходиться сервер. Питання в тому, що відбувається коли щось іде не так — і наскільки швидко і автоматично система відновлюється.

Безпека даних клієнтів у Leadmlyn — там детальніше про те, як ми конкретно захищаємо персональні дані, шифрування і доступ.

---

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

Cloud-first — мій відповідь на цей контекст. Не тому що модно і не тому що дешевше. А тому що в умовах нестабільності надійна розподілена інфраструктура — це перевага, яку самостійно не побудуєш.

Якщо ваш клієнт пише в Telegram о 22:30 щоб забронювати SPA-процедуру на суботу — бот має відповісти. Незалежно від того, що відбувається з електромережею в місті де знаходиться офіс власника.

Це і є відповідь на питання «що буде якщо відключать світло».