Technical studies of server control panels and the stacks they manage, published with the method, the environment, the commands and the limitations, so that anyone can repeat them. Results are published whether or not they favour auraPanel.
On a production 2-vCPU ARM64 host running eight sites, the panel daemon holds about 38 MB resident and used 0.03% of one CPU core on average over nine days; its systemd cgroup, which also counts the backup and maintenance jobs it runs, averaged 0.4%. The data-plane engines it manages dwarf it. Single host, no competitor measured.
Both panels ship a hardened WordPress server block with TLS 1.2+, HTTP/2, hidden version, blocked dotfiles and long-lived static caching. They differ on HTTP/3, PageSpeed and Varnish (CloudPanel), and on per-site logs, an ACME location, bot blocking, xmlrpc and uploads-PHP denial, a bad-bot map and an optional Cloudflare origin lock (auraPanel). Read from primary sources with dates.
Exactly what was measured or read, with the commands or the source documents, so the number can be reproduced.
Hardware, operating system, software versions, and what else was running. A figure without its environment is not a result.
When the measurement was taken or the source read. Software changes; a dated result stays honest.
What the study does not show: sample size, single host, missing competitors, things not controlled for.
Tests are not arranged so that auraPanel comes out ahead, and results are published when it does not.
If you can show a measurement is wrong, tell us; the study is corrected with a note, not quietly replaced.