Proceedings of the International scientific and practical conference ―Synergy of Modern Science and Education‖ (June 12-14, 2026) / Publisher website: www.naukainfo.com. – New York, USA, 2026. - 145 p.

57 фреймворків (React, Vue) піднімають Vite dev server із гарячою заміною модулів, забезпечуючи попередній перегляд компонентів безпосередньо у вікні платформи. Саме цей механізм формує чотири практичні обмеження до інфраструктури розгортання. По- перше, серверний застосунок повинен мати прямий доступ до Docker daemon для динамічного створення контейнерів. По-друге, playground-контейнери є довгоживучими – вони тривають усю студентську сесію та обмінюються даними з браузером через WebSocket, – тож модель «функція без стану» для них непридатна. По-третє, інфраструктура має одночасно координувати кілька служб: статичний фронтенд-бандл, серверний застосунок, СУБД і динамічно створювані контейнери. В четвертих, вартість супроводу має лишатися мінімальною для одного розробника, а сама інфраструктура – бути декларативно описаною в коді й відтворюваною з нуля. Огляд та порівняльний аналіз моделей розгортання. У процесі дослідження розглянуто чотири поширені моделі розгортання веб-платформ і оцінено їхню придатність до зазначених обмежень. Kubernetes – індустріальний стандарт оркестрації контейнерів – формально привабливий, але має високу ціну [4]: запуск judge- і playground-контейнерів усередині Pod-ів вимагає привілейованого доступу до контейнерного рантайму (docker-in-docker або спеціалізованого sysbox-runtime), що ускладнюється політиками безпеки кластера й нівелює саму абстракцію, заради якої він вводиться; операційна вартість обов'язкових компонентів (etcd, ingress, CNI, моніторинг) непропорційно висока для команди з одного розробника. Керовані PaaS- та serverless-платформи (Vercel, Render, Fly.io тощо) дозволяють розгортати застосунки з мінімальною конфігурацією, проте серверна частина CodeToLearn принципово не може бути розгорнута в serverless-моделі [5]: доступ до Docker daemon у ній відсутній з очевидних міркувань безпеки, довгоживучі WebSocket-сесії playground-контейнерів суперечать моделі короткоживучих функцій, а рознесення фронтенду й сервера між різними провайдерами ускладнює керування доменом, CORS і прозоре проксіювання попереднього перегляду. Docker Compose на одному вузлі описує всі прикладні сервіси в єдиному декларативному файлі [6], однак не охоплює саму інфраструктуру: створення віртуальної машини, мережевий фаєрвол і DNS лишаються поза його зоною, а головний застосунок мусить отримувати доступ до Docker daemon хоста через монтований сокет – патерн, що фактично нівелює ізоляцію самого серверного контейнера від решти системи. Четвертою моделлю є декларативна VPS-інфраструктура, в якій хмарні ресурси описуються в Terraform, а застосунки запускаються безпосередньо на віртуальному сервері під керуванням systemd. Зведене порівняння наведено далі (табл. 1). Таблиця 1 Порівняння моделей розгортання за ключовими критеріями Критерій Kubernetes PaaS / serverless Docker Compose Terraform + systemd Інфраструктура як код + +/− +/− + Доступ сервера до Docker daemon +/− − + + Довгоживучі playground- контейнери + +/− + + Контроль лімітів виконання коду + − + + Атомарні релізи з автовідкочуванням + + +/− + Вартість супроводу для одного розробника − + + + Прозорий HTTP-шар із SSE та WebSocket +/− + +/− + Аналіз наведеної таблиці показує, що повне покриття вимог досягається лише в моделі Terraform + systemd, яку й було обрано для платформи. Сутність запропонованого рішення. В обраній моделі ролі компонентів чітко розділені: Terraform відповідає за хмарні ресурси, systemd – за життєвий цикл серверних процесів, nginx – за публічний HTTP-шар, а Docker використовується точково – лише для контейнерів, у яких виконується