Запитання, які ставлять до першого розгортання — і після нього.

Власна багатокористувацька платформа як послуга (PaaS), що працює на одному хості з Linux. Ви створюєте проєкти, розгортаєте з git або з архіву статичний застосунок чи застосунок на Node.js, Python або PHP, підключаєте PostgreSQL або MySQL — і отримуєте HTTPS-домени, сховище S3, резервні копії та метрики.

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

Для команд і окремих людей, яким потрібен процес роботи на кшталт Vercel чи Heroku на обладнанні, яке вони контролюють: внутрішні інструменти, клієнтські сайти, API, особисті проєкти, середовища для воркшопів і навчальних класів, розгортання під керуванням ШІ-агентів. Платформа свідомо залишається невеликою — один хост, один застосунок на проєкт.

Усіма трьома способами, як вам зручно. Веб-консоль, REST API і MCP-сервер — це тонкі обгортки над одним і тим самим сервісним шаром, тож авторизація, ліміти та журнал аудиту однакові. Створіть API-токен для скриптів і агентів.

Один. Проєкт — це одиниця розгортання, як у Vercel. Для другого сервісу створіть другий проєкт — він використовуватиме ваш демон і ваш бакет S3.

Чотири середовища виконання: static (nginx), node, python і php (php-fpm + nginx). Dockerfile платформа створює сама із шаблону для вибраного середовища виконання; у platform.yaml немає ключа, щоб передати власний Dockerfile. Для інших мов оператор мав би додати нове середовище виконання. Див. чотири середовища виконання.

Окремого планувальника чи воркерів немає — проєкт запускає один контейнер. Виконуйте фонову роботу всередині застосунку (бібліотека-планувальник або споживач черги в тому самому процесі) або запускайте її ззовні, викликаючи URL вашого застосунку з CI чи з cron на іншій машині.

Англійською та українською. Перемикач мови розташований у верхній навігації та на сторінці входу; вибір запам'ятовується в браузері, а доки ви не вибрали, мову визначає браузер. Текст, що надходить із сервера, — наприклад, подробиці помилок, — показується як є, англійською. Див. Мова консолі.

Обліковий запис (його створює адміністратор), адреса консолі та базовий домен. Далі пройдіть Швидкий старт — вхід, проєкт і архів.

Відкрийте вкладку Розгортання проєкту, виберіть Завантаження архіву або Git-репозиторій і натисніть Розгорнути. Через REST це POST /api/v1/projects/{id}/deployments, через MCP — deploy_app. Збірка виконується у фоновому режимі та транслює свій журнал. Подробиці — у розділі Розгортання.

З platform.yaml, якщо він є; інакше — за першим файлом, що збігається, у корені вихідного коду: package.json → node, requirements.txt/pyproject.toml → python, composer.json/public/index.php → php, index.html → static. Архівуйте вміст папки, а не саму папку — файли мають лежати в корені архіву.

Клонування неінтерактивне (GIT_TERMINAL_PROMPT=0), тому репозиторій, який просить ім'я користувача чи пароль, клонувати не вдасться. Або зробіть його доступним без запиту, або збирайте архів у своєму CI й завантажуйте його — шлях через архів працює для будь-якого джерела.

512 МіБ — і для завантаженого файлу, і для розпакованого дерева. Не додавайте node_modules, кеші збірки та медіафайли. Для всього, що більше за приблизно 3 МіБ, агенти використовують одноразове посилання для завантаження.

Середовище виконання static віддає файли — воно не запускає вашу збірку. Зберіть застосунок локально чи в CI, а потім розгорніть результат:

runtime: static
site_dir: dist
spa: true

spa: true змушує невідомі шляхи повертати index.html, щоб працювала маршрутизація на стороні клієнта.

Старий застосунок замінюється лише після того, як новий образ зібрано, тож збій отримання коду, визначення середовища виконання чи збірки залишає працювати попередню версію. Помилка показується над журналом збірки. Розгортання, перервене перезапуском платформи, позначається як збій — просто розгорніть ще раз. Див. Коли розгортання завершується збоєм.

Короткий: старий контейнер зупиняється й видаляється, а новий запускається, тож очікуйте короткої перерви (секунди). Дані в томах, базах даних і S3 не зачіпаються.

Кнопки відкату немає. Розгорніть старіший вихідний код ще раз — старіший git-тег або старіший архів. Позначайте тегами те, що випускаєте, і фіксуйте version повним значенням x.y.z, якщо потрібні ідентичні перезбірки.

Так — це три REST-виклики з API-токеном: завантажити архів (або вказати git URL), запустити розгортання, опитувати його статус.

curl -fsS -X POST "$BASE/api/v1/projects/$PID/deployments"   -H "Authorization: Bearer $DIND_TOKEN" -H 'Content-Type: application/json'   -d '{"source":{"type":"git","url":"https://git.example.com/me/app.git","ref":"v1.4.0"}}'

Опитуйте GET /api/v1/projects/$PID/deployments, доки найновіший запис не матиме статус running або failed.

Згенерований Dockerfile задає NODE_ENV=production до npm ci, тому npm пропускає devDependencies. Або перенесіть інструменти збірки до dependencies, або накажіть платформі встановлювати їх:

install_cmd: npm ci --include=dev

Додайте version до platform.yaml: "22", "22.12" або "22.12.1". Якщо цього не зробити, платформа шукає точну або мажорну підказку (.nvmrc, .node-version, engines.node, .python-version, require.php), а зрештою бере типову версію платформи. Маніфест завжди має пріоритет. Див. Версії середовища виконання.

YAML читає 3.10 без лапок як число 3.1 і мовчки відкидає нуль. Тому платформа відхиляє дробове число з повідомленням, яке просить написати version: "3.10". Ціле число, як-от version: 22, приймається.

Лише якщо він слідує за рухомою версією. Коротка версія ("22", "22.12") завжди збирається на найновішому відповідному релізі й завантажується повторно при кожному розгортанні, тож перезбірка підхоплює виправлення. Повна версія x.y.z зафіксована й завантажується лише тоді, коли її ще немає в демоні. Застосунок без version слідує за типовою версією платформи — і переходить на нову типову версію під час наступної перезбірки (уже зібрані образи працюють без змін, доки це не станеться).

Node 24 (найновіша LTS на момент задання типового значення), Python 3.12, PHP 8.5 і nginx 1.27. Адміністратори можуть змінити їх для всієї платформи через PLATFORM_DEFAULT_{NODE,PYTHON,PHP,STATIC}_VERSION.

На початку журналу збірки є рядки # runtime=node version=24 (platform default) і # base image: node:24-alpine (sha256:…), а на вкладці Застосунок показано використовуваний базовий образ.

Типово використовуються npm (npm ci, а якщо не вийде — npm install) і pip. Перевизначте install_cmd, build_cmd та start_cmd у platform.yaml, щоб запускати щось інше, — інструмент лише має бути в базовому образі середовища виконання або встановлюватися вашою командою.

У змінних проєкту (вкладка Середовище, PUT /projects/{id}/env/{key} або set_env). Для облікових даних поставте позначку секретна: вони зберігаються зашифрованими й ніколи не читаються назад. Використовуйте env: у platform.yaml лише для несекретних констант, що подорожують разом із вихідним кодом. Див. Змінні середовища та секрети.

Змінні застосовуються після перестворення або розгортання. Натисніть Перестворити застосунок зараз на вкладці «Середовище» (або Перестворити на вкладці «Застосунок»): це за кілька секунд замінює контейнер із того самого образу, але з новими змінними, зберігаючи томи.

Ні. Змінні проєкту діють лише під час роботи. Значення для часу збірки задавайте в platform.yaml (build_cmd/install_cmd) або зчитуйте змінну під час запуску застосунку.

Ні — так задумано. Консоль показує ••••, REST і MCP повертають null, а записи аудиту й журнали його ніколи не містять. Щоб змінити секрет, задайте його знову.

PORT і все, що починається з PLATFORM_, S3_ або DB_, належить платформі й відхиляється як змінні проєкту, тож змінна ніколи не затінить значення платформи.

Слухайте на 0.0.0.0:$PORT. Платформа вибирає вільний порт у вашому демоні й передає його як PORT. Якщо прив'язатися до 127.0.0.1 чи до жорстко заданого номера, сайт стане недосяжним.

<slug>.<alias>.<base_domain>, наприклад blog.alex.example.com; вона резервується під час створення проєкту. Чи резолвиться вона з Інтернету, залежить від того, як адміністратор публікує DNS для базового домену.

Створіть запис A для імені, що вказує на публічну адресу вхідного шлюзу (ingress) платформи, а потім додайте його на вкладці Домени. Коли перевірка покаже пройдено, з'являться маршрут і сертифікат. Після виправлення DNS натисніть Повторити перевірку. Див. Домени та TLS.

Вона доводить, що ім'я веде назад до цієї платформи — запис DNS резолвиться (на налаштовану адресу, якщо її задано), а URL-маркер відповідає власним ідентифікатором платформи, — до того, як запитується сертифікат. Тож хибний запис ніколи не витрачає ліміт ACME.

Типові причини: порт 80 не доходить до платформи (для HTTP-01 він потрібен), ліміт запитів CA або фіктивна контактна пошта (admin@platform.example відхиляє кожен CA). Фонова перевірка доменів (watchdog) повторює спробу кожні п'ять хвилин. Попросіть адміністратора спершу відпрацювати це на staging-середовищі Let's Encrypt. Див. Усунення несправностей.

Ні. Сертифікати видаються для кожного домену окремо через виклик HTTP-01. Кожен доданий вами домен отримує власний.

Так, щойно домен отримає сертифікат. Ваш застосунок завжди отримує від платформи лише звичайний HTTP, тому не додавайте власне перенаправлення на порту застосунку.

Імовірно, платформа працює в режимі TLS dev, де сертифікати підписує локальний центр сертифікації. Імпортуйте його сертифікат (data/platform/traefik/certs/dev/ca.crt) або попросіть адміністратора перемкнутися на prod.

PostgreSQL (нові бази працюють на postgres:17-alpine) і MySQL (mysql:8.4). Кожна база назавжди зберігає образ, з якого її створено; консоль показує його поруч зі СУБД. Див. Бази даних.

Вкажіть базу даних у platform.yaml (databases: [main]), і платформа додасть DB_MAIN_HOST, _PORT, _USER, _PASSWORD і _NAME. Створіть базу даних спершу — змінні додаються лише для баз, які існують на момент розгортання чи перестворення застосунку.

Бази даних доступні лише у внутрішній мережі платформи — публічного порту бази даних немає. Для запитів використовуйте SQL-консоль (один запит, тайм-аут 30 секунд, 1 000 рядків / 1 МіБ), робіть дампи для масового експорту або запускайте інструменти зсередини застосунку.

Його показано один раз — під час створення бази, а зберігається він зашифрованим. Ваш застосунок і далі отримує його через змінні DB_*. Щоб отримати нові облікові дані, створіть нову базу даних і перенесіть дані (дамп і відновлення).

Не у файлову систему контейнера — її замінюють при кожному розгортанні. Використовуйте свій бакет S3 (s3: true додає S3_*), том, оголошений у platform.yaml, або базу даних. Див. Файлове сховище.

Вбудованого розкладу немає. Створити резервну копію проєкту (або create_backup, POST /projects/{id}/backups) на вимогу робить знімок усіх дампів баз даних, томів застосунку й останнього архіву вихідного коду; викликайте її з власного cron чи CI, щоб мати регулярні копії. Засіб очищення типово зберігає 14 днів / 5 копій на кожну область (змінюється адміністратором).

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

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

Ви — і адміністратори. Перевірка власника виконується в сервісному шарі однаково для консолі, REST і MCP, а на все, що вам не належить, відповідь — не знайдено, а не заборонено.

Кожен користувач має власний демон Docker для застосунків (projects-<alias>). Вихідний код передається в нього потоком під час кожного розгортання й ніколи не монтується. Бази даних — окремі контейнери з власними обліковими даними: типово в спільному демоні баз даних або в окремому демоні db-<alias>, коли його вмикає адміністратор. Див. Модель безпеки.

Секрети платформи генеруються під час першого запуску в data/platform/secrets (режим 0600). Збережені облікові дані — паролі баз даних, секретні змінні — шифруються ключем Fernet із цього каталогу. Паролі облікових записів хешуються за допомогою argon2id, а API-токени зберігаються лише як хеші.

JWT для входу діє 8 годин. API-токен (dt_…) діє, доки ви його не відкличете, а його значення показується лише один раз — під час створення.

Ні. Головний демон узагалі не має TCP-слухача — лише unix-сокети, — а платформа не публікує жодних портів хоста. Єдина поверхня, звернена до хоста, — одна адреса в мережі-мості (bridge), і що саме туди перенаправляти, вирішує оператор.

Кожна дія, що змінює стан, створює запис аудиту (хто, що, над якою ціллю), а кожен запит SQL-консолі — запис у журналі запитів. Значення секретів не потрапляють ні в те, ні в інше. Див. Журнал аудиту.

Model Context Protocol дає змогу ШІ-агенту викликати інструменти. Платформа відкриває кожну можливість — створення проєктів, розгортання, читання журналів, виконання SQL, керування доменами та резервними копіями — як 33 інструменти, з тими самими правами й журналом аудиту, що й консоль. Можна сказати «розгорни цю папку» — і спостерігати, як це відбувається.

Створіть токен на сторінці Токени, а потім виконайте команду, яку покаже діалог:

claude mcp add --transport http dind-platform https://<your-platform-host>/mcp/   --header "Authorization: Bearer <dt_… token>"

Збережіть кінцеву косу риску в /mcp/. Див. Підключення Claude Code.

Так, через create_upload_url: одноразове, 15-хвилинне PUT-посилання для файлів до 512 МіБ, прив'язане до одного проєкту й типу файлу. Агент надсилає файл на нього командою curl з оболонки й розгортає отриманий upload_id. upload_archive призначено лише для архівів до приблизно 3 МіБ.

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

Усе, що робить консоль: проєкти, завантаження, розгортання, життєвий цикл застосунку, змінні, бази даних і SQL, домени, резервні копії, метрики та адміністративні маршрути під /api/v1. Див. таблицю маршрутів.

Хост із Linux, Docker і Compose v2, щонайменше близько 2 CPU і 4 ГБ RAM та вихідний доступ до Інтернету для завантаження образів. Далі — make build і make up. Див. Експлуатація.

Docker перезапускає dind-hosting; кожен внутрішній контейнер має restart: unless-stopped; а під час запуску узгоджувач (reconciler) сервісу management заново встановлює мережу, контейнери платформи та демон кожного користувача — створює відсутнє й ніколи не знищує дані. Єдина дія оператора після будь-якого збою — make up.

git pull
make build
scripts/upgrade.sh

Дані не зачіпаються, а міграції виконуються під час запуску. Щоб відкотитися, перезберіть попередній коміт і знову запустіть scripts/upgrade.sh.

Усе, що має зберігатися, лежить у data/. Для узгодженої копії зупиніть платформу (make down), скопіюйте або заархівуйте data/ — разом із data/platform/secrets — і запустіть її знову (make up). Вбудовані резервні копії захищають дані користувачів, а не стан платформи.

Порти 80 і 443 (а якщо ви хочете, щоб консоль і MCP були під вашим іменем, — ще й порт консолі 8900 або проксійований шлях) на 10.10.10.10. Для великих завантажень дозвольте тіло запиту 512 МіБ і вимкніть буферизацію; щоб бачити справжні адреси клієнтів, увімкніть протокол PROXY. Див. Домени та TLS у режимі prod.

Лише найновіші рядки: журнал кожного контейнера типово ротується на рівні 2 файли × 25 МБ (не більше 50 МБ), тож балакучий застосунок не заповнить диск. Усе, що потрібно зберегти, надсилайте у власну службу журналювання або в S3. Оператори можуть змінити ліміти через PLATFORM_LOG_MAX_SIZE і PLATFORM_LOG_MAX_FILE; див. Обмеження журналів контейнерів.

Ні — ця версія свідомо розрахована на один хост. Розгортання на кількох хостах і в Kubernetes, горизонтальне масштабування сервісу management та реєстр, спільний для демонів, виходять за межі цієї версії.