Manage your Linux server without living in the terminal.

What auraPanel automates

The repetitive parts of running a web server, done the same way every time:

• A Linux user, home directory and log rotation for every site, so sites cannot read each other's files.
• nginx server blocks rendered from templates, tested with nginx -t and enabled with a single reload; security headers and a deny rule for log files on every one.
• PHP-FPM pools per site, on the PHP version the site chooses, with OPcache on and settings written as admin values.
• systemd units for Node.js, Python and Docker Compose sites, with restart back-off and a crash-loop guard.
• Let's Encrypt issuance the moment DNS resolves, renewal every 12 hours for anything within 30 days of expiry, DNS-01 through Cloudflare for wildcards.
• Backups on a schedule with retention, off-site copies through rclone, restore into the same or a new site.
• Updates that are Ed25519-signed, checked every 12 hours, and rolled back automatically if the new daemon does not report healthy.
• At install: nginx from nginx.org, PHP from deb.sury.org, MariaDB and PostgreSQL from their own repositories, UFW allowing 22, 80, 443 and the panel port, fail2ban, and a swap file when RAM is 2 GB or less.

What stays under your control

• Root. The panel is a root daemon on the host, not a replacement for it; SSH in whenever you like.
• Operating-system updates with apt. The panel updates itself and the packages it installed from vendor repositories; the rest of the system is yours.
• Firewall rules beyond the installer's defaults, SSH hardening, and the provider's firewall in front of the server.
• Application code, dependencies and their updates. The panel runs and supervises; it does not manage your framework.
• DNS. The panel needs records to point at it and can complete DNS-01 challenges through Cloudflare, but it is not a DNS host.
• Anything the panel does not own. Managed files are rendered from the panel's database, so hand edits to a site's server block are overwritten on the next render; edit it through the panel's vhost editor instead, and the change persists.

A standard server underneath

auraPanel keeps to the filesystem hierarchy standard and to the services' own conventions. Program files live in /opt/aurapanel, configuration in /etc/aurapanel, state in /var/lib/aurapanel (an SQLite database), site files in /home/<user>/htdocs/<domain> with logs beside them. nginx, PHP, MariaDB and PostgreSQL are distribution-style packages in their standard locations; server blocks are in /etc/nginx/sites-available; site services are ordinary units in /etc/systemd/system.

That is deliberate. A site created by the panel is a Linux user, a directory, an nginx server block and perhaps a unit — things any administrator can read, back up or move. apcli paths prints the whole map.

• /opt/aurapanel
• /etc/aurapanel
• /var/lib/aurapanel/aurapanel.db
• /home/<user>/htdocs/<domain>
• /etc/nginx/sites-available
• aurapanel-site-<domain>.service

The terminal is still there

apcli ships with the panel and talks to the daemon over a root-only socket, so a box with no browser access is still fully operable. Create and delete sites, create, import and export databases, run backups, renew certificates, reset a panel user's password, restart managed services, follow the daemon log, and run apcli doctor to audit every site's server block, pool, document root and certificate for drift. Per-site SSH accounts give developers a shell as the site user, chrooted or not, with keys or passwords.

• apcli site · db · backup · ssl · user · server · license
• apcli doctor --json
• Per-site SSH and SFTP users
• Unattended install flags and env vars for cloud-init

Seeing what the server is doing

Per-site access and error logs with filters and live tail; journal output for runtime services; six months of one-minute CPU, memory, disk and network samples with per-site attribution; site health states from the real unit and service signals; a runaway-service watchdog that throttles crash loops and reports CPU hogs; and an audit log of every action taken through the panel. Logs and monitoring →

Debian and Ubuntu, x86-64 and ARM64

Supported releases are Debian 12 and 13 and Ubuntu 22.04, 24.04 and 26.04 LTS, on amd64 and arm64; the installer warns and continues on other Debian or Ubuntu releases rather than pretending they were tested. ARM is not an afterthought: this website is served by auraPanel on a Debian 13 ARM64 host.

Frequently asked

Does it replace Ansible or Terraform?

No. Use them to create the server and run the installer unattended — every option has a flag and an environment variable for cloud-init — and let the panel handle the day-to-day of sites, certificates and backups afterwards.

Can I still edit nginx configuration?

Yes, through the panel's vhost editor, which survives re-renders. Edits made directly to a managed file are overwritten the next time the site is rendered.

Does it work on a server that already runs sites?

It is built for a fresh server: the installer stops if ports 80, 443 or 8443 are held by something else and does not adopt an existing stack. Move sites in as files plus a database dump.

Which port does the panel use, and can I hide it?

8443, behind nginx, with a Let's Encrypt certificate once you give it a domain. Restrict it with a UFW or provider-firewall rule to your own addresses, or put basic authentication in front of a site.

What does the panel send anywhere?

A daily licence check (machine fingerprint and licence state) to the licensing service, release checks to GitHub, a public-IP lookup on first run, and certificate requests to Let's Encrypt. Nothing about your sites or their visitors.