Architecture
Definition first, running system second.
The panel never edits a live configuration by hand. It renders what the system should look like and then makes the system match.
The loop
Everything the panel manages follows the same shape. A change is written to a definition, the target configuration is rendered from it, the running system is compared, and the difference is applied as one step — with a timestamped copy of whatever was replaced.
change → definition → render → compare → apply + backup → reload
↑
on boot, on change, on demandThat is why a reboot never leaves a server half configured, and why the answer to “what is actually loaded?” is the same as the answer to “what does the panel say?”.
Web
A domain gets a document root seeded from a master template, then an HTTP-only vhost that answers only the ACME challenge path — and only for genuine token names. Once the certificate exists, the full vhost is written: TLS 1.3, HSTS, HTTP/3, the security blocks for dotfiles and backup files, and per-site cache rules for versioned assets.
PHP
Each site can have its own FPM pool with its own user, socket and limits, so one application cannot starve another. The socket group is set so nginx can reach it and nothing else can.
Accounts live in one store. From it the panel writes the Postfix virtual-domain and mailbox maps and the Dovecot password file, runs postmap, and reloads both daemons. There is no second place where an account could exist — or fail to.
Defence
CDPGuard is a module of the panel, not a separate product with its own console. Rules are compiled into nftables sets and reconciled on every start; blocks, rate limits and events are visible where the domain is managed.
What it publishes into
The panel creates document roots; it does not write content into them. That is CDPCMS’s job, and the separation is deliberate: publishing a page must never be able to break the way a domain is served.