The question
A control panel is a permanent extra process on a server that exists to run other things. How much memory, CPU and disk does auraPanel's daemon take for itself, and how does that compare with the services it manages on the same machine? This study measures one production host — the one serving this website — with the operating system's own accounting. It does not measure any other panel, and it says so again in the limitations.
Results
Memory and CPU by systemd unit
Memory is cgroup memory.current and memory.peak as reported by systemd; CPU is the unit's cumulative CPUUsageNSec divided by the seconds since it started, expressed as a share of one core.
| Unit | Memory now | Peak | CPU used | Running since | Average of one core |
|---|---|---|---|---|---|
| aurapaneld (the panel) | 171.7 MB | 180.9 MB | 3,198 s | 8 Sep 14:18 UTC | 0.41 % |
| nginx | 41.3 MB | 84.6 MB | 269 s | 23 Aug | 0.012 % |
| php8.5-fpm | 366.8 MB | 769.7 MB | 2,890 s | 23 Aug | 0.13 % |
| mariadb | 219.6 MB | 221.0 MB | 686 s | 24 Aug | 0.032 % |
| postgresql@18-main | 543.2 MB | — | 6,260 s | 24 Aug | 0.29 % |
| redis-server | 80.8 MB | 93.5 MB | 8,071 s | 23 Aug | 0.37 % |
| docker | 311.3 MB | 543.2 MB | 1,450 s | 23 Aug | 0.066 % |
| typesense-server | 123.7 MB | 502.9 MB | 3,407 s | 23 Aug | 0.16 % |
| fail2ban | 82.6 MB | 92.7 MB | 1,126 s | 23 Aug | 0.051 % |
The five Node.js site services held 61, 98, 124, 173 and 389 MB respectively; they are the applications, not the panel, and are listed only to show the scale of the things the panel runs.
The daemon on its own
The cgroup figures above include everything the unit has ever spawned. The panel spawns work on your behalf — nginx -t before every reload, tar and gzip for backups, mariadb-dump and pg_dump, package installs — and systemd charges that CPU to the unit even after the child exits. The daemon process itself is smaller:
| Measure | Value | How |
|---|---|---|
| Resident memory of the daemon process | 38.5 MB | ps -o rss |
| CPU time of the daemon process, 9 days | 223 s → 0.028 % of one core | ps -o time, over 785,071 s |
| CPU in a 60-second sample | 0.08 % (50 ms per minute) | pidstat; includes the once-a-minute resource sampler |
| Threads | 11 | ps -o nlwp |
| Health endpoint over TLS, local | 3.0–3.7 ms | 10 × curl https://127.0.0.1:8443/api/health |
The gap between 171.7 MB (cgroup) and 38.5 MB (process) is mostly page cache: files the daemon or its children read — the SQLite database, site files during a backup — are charged to the cgroup while cached, and the kernel reclaims them under pressure. It is not memory the panel is holding.
Disk
| Path | Size | What |
|---|---|---|
/opt/aurapanel/bin/aurapaneld | 34 MB | The panel binary, with the web interface embedded |
/opt/aurapanel/bin/apcli | 6 MB | The CLI |
/opt/aurapanel/bin/*.1.21.2.bak | 40 MB | Previous version, kept for rollback |
/opt/aurapanel/installer, share | 116 KB | Install, update and uninstall scripts; release public key |
/var/lib/aurapanel | 14 MB | State, of which the SQLite database is 9.9 MB |
/etc/aurapanel | 188 KB | Configuration, certificates and keys for 11 hostnames |
/opt/aurapanel/node | 264 MB | Node.js runtimes for the sites — not the panel |
The 9.9 MB database holds 63,738 one-minute server samples (44 days), 72,005 five-minute per-site samples, 11,982 audit entries and the 8 site records. At that rate six months of server history is on the order of 30 MB.
Reading the numbers
- On this host the panel's own process is the smallest long-running service in memory after nothing — 38.5 MB resident against 41 MB for nginx, 81 MB for Redis and 220 MB for MariaDB — and its average CPU share is below every engine it manages except nginx.
- Counting the jobs it runs for you (backups, dumps, installs, config tests), the panel's unit averaged 0.41 % of one core over nine days, comparable to Redis on this host and less than half of one percent of a two-core machine.
- The resource sampler that gives the panel its six-month history costs about 50 ms of CPU a minute and roughly 220 KB of database per day.
- The panel keeps the previous release on disk for rollback, which doubles its binary footprint to about 80 MB. That is a deliberate trade.
Limitations
- One host. A different workload — many PHP sites, heavy backup schedules, frequent installs — would move the unit's CPU figure, mostly through the child jobs. The daemon's own figures should be similar anywhere.
- ARM64. The host is an Arm Neoverse-N2 virtual machine; x86-64 figures will differ somewhat, though not in kind.
- No competitor was measured. This is a measurement of auraPanel, not a comparison. The same commands work on any systemd host running CloudPanel, cPanel, Plesk or another panel; when we can run them on fresh servers side by side, we will publish that too, whatever it shows.
- cgroup memory includes page cache. The "memory now" column overstates what each service is holding; the process RSS row is the fairer figure for the panel, and the same caveat applies to every other unit in the table.
- PostgreSQL's peak was not reported by systemd on this host (the unit is a template instance) and is left blank rather than estimated.
- Uptime differs by unit. The panel restarted on 8 September for the 1.21.3 upgrade; the other units have run since 23–24 August. Averages are over each unit's own running time.
Reproduce it
All read-only. Run them on any auraPanel host; substitute the unit names for another panel.
# memory and cumulative CPU per unit
for u in aurapaneld nginx php8.5-fpm mariadb postgresql@18-main redis-server docker; do
printf '%-20s' "$u"; systemctl show "$u" -p MemoryCurrent -p MemoryPeak -p CPUUsageNSec -p ActiveEnterTimestamp | tr '\n' ' '; echo
done
# the daemon process alone
P=$(pidof aurapaneld)
ps -o pid,rss,nlwp,etimes,time,cmd -p "$P"
# a 60-second CPU sample (sysstat)
pidstat -u -h -p "$P" 60 1
# disk
sudo du -sh /opt/aurapanel/* /var/lib/aurapanel /etc/aurapanel
# rows in the panel database (read-only)
sudo python3 -c "import sqlite3;c=sqlite3.connect('file:/var/lib/aurapanel/aurapanel.db?mode=ro',uri=True);print([(t,c.execute(f'select count(*) from {t}').fetchone()[0]) for t in ('metrics_history','metrics_site_history','audit_log','sites')])"
# health endpoint latency
for i in $(seq 10); do curl -sk -o /dev/null -w '%{time_total} ' https://127.0.0.1:8443/api/health; done; echo Average share of one core = CPUUsageNSec ÷ 1e9 ÷ (now − ActiveEnterTimestamp) × 100.