РазделКак устроено
ДокументацияУстройство

Как устроено

Один бинарник monopanel (он же mp) работает в нескольких ролях:

РольПраваЗачем
apiобычный пользователь monopanelHTTPS :8443, unix-сокет для CLI, очередь задач, планировщики
agentrootзакрытый набор типизированных операций по unix-сокету (никаких строк с командами)
helpersetuid, необратимый сброс правфайловые операции от имени клиента
fsopправа клиентасама файловая операция

Состояние живёт в SQLite. Изменение сайта — это не правка файла на диске, а запись в базу, из которой рендерятся конфиги: шаблон → валидация (nginx -t, apachectl -t, php-fpm -t) → атомарная запись всех файлов сразу → reload. Любая неудача на этом пути откатывает весь набор файлов и возвращает текст ошибки.

Принципы, коротко:

  1. Один бинарник Go, без рантайма на хосте.
  2. Разделение привилегий: непривилегированный API-процесс ↔ root-агент с allow-list операций и путей.
  3. Один API для Web, CLI, TUI и интеграций.
  4. Декларативное состояние → рендер → валидация → атомарное применение → reload, с откатом.
  5. Панель слушает свой порт и не зависит от системного nginx.
  6. Один php-fpm master на версию, пул на сайт; Apache только через mod_proxy_fcgi.
Исходник страницы на GitHub