Research

How much of the server does auraPanel itself use?

Summary. 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.

Measured
17 September 2026
Method
systemd cgroup accounting, ps, pidstat, du on one live host
Host
Debian 13 (trixie), kernel 6.12 cloud-arm64, 2 vCPU Arm Neoverse-N2, 7.9 GB RAM, 126 GB disk
Panel
auraPanel 1.21.3, daemon running since 8 September 2026 (9 days at measurement)
Workload
8 sites (5 Node.js, 1 WordPress, 1 static, 1 reverse proxy); nginx, PHP-FPM 8.5, MariaDB, PostgreSQL 18, Redis, Docker, Typesense, fail2ban

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.

UnitMemory nowPeakCPU usedRunning sinceAverage of one core
aurapaneld (the panel)171.7 MB180.9 MB3,198 s8 Sep 14:18 UTC0.41 %
nginx41.3 MB84.6 MB269 s23 Aug0.012 %
php8.5-fpm366.8 MB769.7 MB2,890 s23 Aug0.13 %
mariadb219.6 MB221.0 MB686 s24 Aug0.032 %
postgresql@18-main543.2 MB6,260 s24 Aug0.29 %
redis-server80.8 MB93.5 MB8,071 s23 Aug0.37 %
docker311.3 MB543.2 MB1,450 s23 Aug0.066 %
typesense-server123.7 MB502.9 MB3,407 s23 Aug0.16 %
fail2ban82.6 MB92.7 MB1,126 s23 Aug0.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:

MeasureValueHow
Resident memory of the daemon process38.5 MBps -o rss
CPU time of the daemon process, 9 days223 s → 0.028 % of one coreps -o time, over 785,071 s
CPU in a 60-second sample0.08 % (50 ms per minute)pidstat; includes the once-a-minute resource sampler
Threads11ps -o nlwp
Health endpoint over TLS, local3.0–3.7 ms10 × 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

PathSizeWhat
/opt/aurapanel/bin/aurapaneld34 MBThe panel binary, with the web interface embedded
/opt/aurapanel/bin/apcli6 MBThe CLI
/opt/aurapanel/bin/*.1.21.2.bak40 MBPrevious version, kept for rollback
/opt/aurapanel/installer, share116 KBInstall, update and uninstall scripts; release public key
/var/lib/aurapanel14 MBState, of which the SQLite database is 9.9 MB
/etc/aurapanel188 KBConfiguration, certificates and keys for 11 hostnames
/opt/aurapanel/node264 MBNode.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.

Other studies

All research →  ·  Documentation →

Try the live demo

A real auraPanel on a real server, shared with everyone. Sign in with the demo account and click around.

Email
demo@goaura.one
Password
demo1234
Open the demo panel ↗

Shared public demo, so please don’t put anything personal in it. More about the demo →

Talk to us

Tell us what you need and how to reach you. A person reads this, not a queue.

We use these details only to reply to you. Privacy

Recent updates

What shipped in the last releases. With automatic updates on, each lands on your server the moment it is published.

  1. v1.21.3
    Framework sites were undetectable, and a restore could silently point the copy at the original's live database.

    DetectApp looked for each application's signature relative to the docroot — but every PHP framework in the registry serves from a subdirectory (DocrootSub: public, webroot, web, pub, docroot) and keeps the file that identifies it one level *above* that. So the Laravel signature searched <project>/public/artisan,…

  2. v1.21.2
    Restarting nginx now blocks the panel and reconnects, instead of showing a notice.

    v1.21.1 stopped the false "HTTP 520" but only put up a toast — and a toast is the wrong affordance when the panel itself is about to go away: the page sat there looking broken while every request failed underneath it.

  3. v1.21.1
    Restarting nginx from Services no longer reports a false failure.

    It showed "Restart failed — HTTP 520". The panel is reverse-proxied *by* nginx, so the request deadlocked against itself: the handler blocked waiting for the restart to finish, while nginx's graceful stop waited for that very request to drain. Neither could proceed until nginx's stop-retry timeout force-killed it,…

  4. v1.21.0
    Per-site X-Frame-Options, fixing page builders that couldn't load their preview.

    Elementor's editor failed with *"Multiple 'X-Frame-Options' headers with conflicting values ('DENY, SAMEORIGIN')"*. The cause is that nginx's add_header appends rather than replaces: when the application also sets the header — a WordPress security plugin, or a CDN transform — the browser received two values,…

  5. v1.20.6
    The multi-database restore refusal now says what is in the backup and what still works.

    It read only "Restoring a multi-database site isn't supported yet", which is a dead end: it named neither the databases involved, nor why one of them is the limit, nor any route forward.

  6. v1.20.5
    Services: cards in a row now match heights.

    Like the settings grid before it, the Services grid pinned each card to its own content height, so a row often showed one card noticeably shorter than the card beside it. Each row now takes the taller card's height and both fill it, and it re-balances as content changes — a runtime installed, a longer service list.

  7. v1.20.4
    Settings: paired cards now match heights.

    Organisation / Panel Domain and auraPanel Updates / Session timeout each sat at their own content height, so a row showed one card visibly shorter than its neighbour. Each row now takes the taller card's height and both fill it — driven by content, not a fixed value, so it still adapts as a card grows (a validation…

  8. v1.20.3
    Settings: Organisation and Panel Domain now share a row too.

    They were full-width blocks stacked above the rest of the page; they now sit side by side in the same two-column grid as the Updates / Session timeout pair, so the top of Settings reads as two tidy rows instead of four stacked bands. Both cards shrink cleanly — the logo drop zone is a fixed 44×44 and the name field…

All releases on GitHub ↗