Новое приложение на shared-хостинге — цепочка вызовов
Сценарий: развернуть новое серверное приложение (например, серверное приложение Bitrix24) на shared-аккаунте Beget, не заходя в панель руками. Все шаги делаются инструментами этого MCP-сервера; ручной клик в панели не нужен ни на одном из них.
Документ описывает две разные цепочки — их легко перепутать:
- A. Новая платформа — отдельный сайт Beget со своим каталогом и своей платной «папкой сайта». Делается один раз.
- B. Новое приложение на существующей платформе — поддомен, привязанный к уже
существующему сайту. Именно так заводятся приложения на платформе
abp.
Проверено на живом аккаунте 31.08.2026 (сервер chase.beget.ru): читающие шаги
выполнены вызовами API, пишущие сверены с фактическим состоянием платформы abp.
A. Новая платформа (новый сайт)
| # | Инструмент | Параметры | Что происходит |
|---|---|---|---|
| 1 | domain_list |
— | найти id родительского домена (например, itrobot.ru) |
| 2 | domain_add_subdomain |
subdomain, domain_id |
создаётся поддомен в панели и DNS; возвращает id поддомена |
| 3 | site_add |
name |
регистрируется сайт; на диске появляется ~/<name>/public_html |
| 4 | site_list |
— | взять id только что созданного сайта (site_add возвращает статус, идентификатор берётся отсюда) |
| 5 | site_link_domain |
site_id, domain_id |
поддомен начинает отдавать содержимое каталога сайта |
| 6 | domain_change_php |
full_fqdn, php_version |
версия PHP для веб-запросов этого домена |
| 7 | mysql_add |
suffix, password |
база <login>_<suffix>; доступ сразу открыт с localhost |
| 8 | cron_add |
minutes, hours, days, months, weekdays, command |
воркер приложения |
Имя сайта в шаге 3 — это префикс каталога, а не FQDN: site_add(name="abp.itrobot.ru")
даёт каталог ~/abp.itrobot.ru/public_html, но точки в имени — просто соглашение,
связь с доменом устанавливает только шаг 5.
B. Новое приложение на существующей платформе
Это основной путь для платформы abp. Своего сайта Beget приложение не получает:
все поддомены приложений привязаны к одному сайту (одна платная папка), а
разведение по каталогам делает Host-роутинг в .htaccess корня платформы.
| # | Инструмент | Параметры | Что происходит |
|---|---|---|---|
| 1 | domain_list |
— | id родительского домена |
| 2 | domain_add_subdomain |
subdomain, domain_id |
поддомен приложения; возвращает его id |
| 3 | site_list |
— | id сайта платформы (запись с path вида <платформа>/public_html) |
| 4 | site_link_domain |
site_id, domain_id |
поддомен указывает на корень платформы |
| 5 | domain_change_php |
full_fqdn, php_version |
версия PHP для веб-запросов |
| 6 | cron_add |
расписание + command |
воркер приложения |
Шага с site_add здесь нет — сайт уже есть. Шага с mysql_add тоже нет: приложения
платформы делят одну базу, разводясь префиксами таблиц. Отдельная база нужна только
приложению, которому она нужна по существу.
Вне MCP остаются два шага, которые делает деплой самого приложения:
- выложить код в
~/<платформа>/public_html/<приложение>/; - дописать в
~/<платформа>/public_html/.htaccessблок Host-роутинга для нового поддомена (три строки, файл общий для платформы и деплоем не перезаписывается).
Точные имена параметров
Ниже — только то, где имя параметра не очевидно или отличается от имени в API Beget.
domain_add_subdomain(subdomain, domain_id)
subdomain — только метка (dadata), без родителя. Полный FQDN отклоняется
проверкой на стороне сервера, родитель задаётся через domain_id.
site_add(name)
site_delete(site_id)
site_link_domain(site_id, domain_id)
site_unlink_domain(domain_id)
site_add принимает name, а site_delete — site_id; идентификатор нового сайта
берётся из site_list, а не из ответа site_add.
domain_change_php(full_fqdn, php_version)
domain_php_version(full_fqdn)
full_fqdn — полное имя (dadata.itrobot.ru), php_version — строка ("8.5").
mysql_add(suffix, password)
mysql_add_access(suffix, access, password)
Итоговое имя базы — <login>_<suffix>. Доступ с localhost создаётся вместе с базой;
mysql_add_access нужен только для внешних подключений, и пароль в нём указывается
заново — он задаётся для пары (база, хост), а не для базы целиком.
cron_add(minutes, hours, days, months, weekdays, command)
cron_delete(task_id)
cron_toggle(task_id, is_hidden)
Все поля расписания — строки в синтаксисе crontab ("*", "*/2", "06").
Идентификатор задачи в ответе cron_list называется row_number; инструменты
принимают его как task_id.
Грабли, проверенные на живом аккаунте
Поддомен без привязки к сайту — мёртвая запись. domain_add_subdomain создаёт
запись в панели и DNS, но каталога на диске не появляется и в site_list ничего не
меняется. Отдавать с такого поддомена нечего до site_link_domain.
Версию PHP для cron задаёт путь к бинарнику, а не domain_change_php. На хостинге
лежат все версии (/usr/local/bin/php5.2 … /usr/local/bin/php8.5), и команда cron
жёстко называет одну из них. Домен и его воркер поэтому расходятся по версиям молча:
на платформе abp так и было — домен на 8.5, воркер qr запускался через php8.4
(починено 31.08.2026 через cron_edit). Меняя PHP домену, проверяй cron_list.
Cron задаётся абсолютным путём. ~ в команде cron работает, но рядом соседствуют
задачи, записанные полным путём /home/<буква>/<login>/…; для нового воркера надёжнее
абсолютный путь.
nginx отдаёт статику по реальному пути, минуя Apache. Host-роутинг в .htaccess
работает только для запросов, дошедших до Apache. Запрос вида /<приложение>/<файл>
с любого поддомена платформы попадёт в одноимённый каталог напрямую. Следствие для
именования: каталог внутри приложения нельзя называть именем другого приложения
платформы.
Ошибка метода приезжает внутри успешного конверта. HTTP 200 и status: success
не означают, что вызов удался — см. docs/beget-api-gotchas.md. Клиент этого сервера
райзит на answer.status == "error", но при прямых вызовах API об этом надо помнить.