SectionHow it works
DocumentationInternals
How it works
One binary, monopanel (also mp), runs in several roles:
| Role | Privileges | Purpose |
|---|---|---|
api | unprivileged monopanel user | HTTPS :8443, a unix socket for the CLI, the job queue, schedulers |
agent | root | a closed set of typed operations over a unix socket — never a command string |
helper | setuid, irreversible drop | file operations on behalf of an account |
fsop | the account's own privileges | the file operation itself |
State lives in SQLite. Changing a site is not an edit to a file on disk but a row
in the database, from which configuration is rendered: template → validation
(nginx -t, apachectl -t, php-fpm -t) → every file written atomically → reload.
A failure anywhere on that path rolls the whole set back and returns the error text.
The principles, briefly:
- One Go binary, no runtime on the host.
- Split privileges: an unprivileged API process talks to a root agent with an allow-list of operations and paths.
- One API behind the web UI, the CLI, the menu and any integration.
- Declared state → render → validate → apply atomically → reload, with rollback.
- The panel serves its own port and does not depend on the system nginx.
- One php-fpm master per version, one pool per site; Apache only through
mod_proxy_fcgi, nevermod_php.