XAXA Server control panel

XAXA

Technology Stack

XAXA installs and manages standard distribution packages wherever possible, so security updates arrive through apt and unattended-upgrades.

Component Version Source
NGINX distribution version Ubuntu/Debian
PHP-FPM 8.2, 8.3, 8.4, 8.5 ppa:ondrej/php (Ubuntu), packages.sury.org (Debian)
MariaDB 10.6 – 11.8 (per release) Ubuntu/Debian
MySQL 8.0 / 8.4 Ubuntu only
Node.js 20, 22, 24, 26 (per site) nodejs.org, checksum verified
Python 3.10 – 3.14 (per site) uv (python-build-standalone)
Redis distribution version Ubuntu/Debian
Certbot distribution version Ubuntu/Debian
UFW, fail2ban distribution version Ubuntu/Debian
rclone distribution version Ubuntu/Debian
Composer, WP-CLI latest getcomposer.org, wp-cli.org

The panel itself

  • Laravel 13, HTMX 2, Alpine.js 3 and Tailwind CSS 4.
  • SQLite for panel data, stored in /var/lib/xaxa/panel/database.sqlite.
  • Runs on PHP 8.4 in its own PHP-FPM pool as the xaxa user, behind nginx on port 8443.
  • Two queue workers run background jobs: xaxa-queue for quick jobs and xaxa-queue-long for backups, restores, clones, installs, certificates and runtime installs; a systemd timer (xaxa-scheduler.timer) runs scheduled tasks every minute.

Server tuning

The installer sizes these settings to the server's memory on every install and xaxa update. It writes its own files and never edits the packages' configuration files, so security updates keep installing.

  • Swap — below 4 GB of RAM and with no swap, a 2 GB (under 2 GB RAM) or 1 GB /swapfile is created; vm.swappiness = 10 (/etc/sysctl.d/60-xaxa.conf). An existing or disabled swap file is left alone, and in containers that do not allow swap the step is skipped.
  • PHP-FPM — each site's pool keeps 1 warm worker ready and scales up to (RAM / 2) / 80 MB, between 2 and 10 (6 on 1 GB, 10 on 2 GB or more), so the first visit never waits for a cold worker fork.
  • OPcache — per PHP version (conf.d/99-xaxa.ini): 256 MB (128 MB under 2 GB RAM), 50 000 files, 32 MB interned strings, validate_permission on so sites cannot use each other's cached files, and a 4 MB realpath_cache (600 s TTL). Timestamps are still checked, so a deploy takes effect at once.
  • MariaDB / MySQL — innodb_buffer_pool_size is 25% of RAM (at least 128 MB), written to 60-xaxa.cnf and applied at once where the database allows it. MariaDB 11.8 can only grow it after a restart: a new install restarts it, and xaxa update shows the command (systemctl restart mariadb) instead of interrupting your sites. MySQL 8 under 2 GB RAM turns performance_schema off at the next restart.
  • Redis — maxmemory is 10% of RAM (at least 64 MB) with volatile-lru: only keys with an expiry (cache entries) are evicted; queues and sessions are never dropped, and writes fail instead once the limit is full.
  • nginx — TLS 1.2 and 1.3 only, a shared TLS session cache, kept-alive connections to Node.js and Python apps, and buffered access logs that record how long each request took. PHP and app responses up to 288 KB stay in memory instead of a temporary file on disk, open files and their symlink checks are cached for 10 s, and text is compressed with Brotli where the distribution packages the module (Ubuntu 24.04, Debian 12 and 13), gzip otherwise.
  • Network — TCP BBR with the fq queue (/etc/sysctl.d/60-xaxa.conf) when the kernel offers it, so downloads stay fast on long and lossy connections. fq applies from the next boot.
  • Certificates — Let's Encrypt certificates use ECDSA P-256: smaller, and a cheaper TLS handshake than RSA.
  • Backups — archives are compressed with zstd, several times faster than gzip at about the same size, and run with low CPU and disk priority (nice, ionice), so sites stay responsive during the nightly backup.

Found a mistake or need help? support@xaxa.com.tr