Site Settings

Open a site and go to Settings. Sections: General, PHP (PHP sites), Domain & SSL, Security, Environment (Node.js and Python sites), Vhost and SSH/SFTP. On phones the sections are a drop-down.

Setting	Site types	What it does
PHP version (PHP section)	PHP	Moves the site's FPM pool to another PHP version. Takes effect immediately. Admins install more versions and extensions under Instance (Runtimes, PHP extensions).
PHP limits (PHP section)	PHP	Memory limit, max upload size (also nginx client_max_body_size), max execution time, max input vars, display errors and OPcache — per site.
Document root	PHP, Static	Folder inside htdocs/<domain> that nginx serves, e.g. public.
Start command	Node.js, Python	Command run by the xaxa-<user>@<port> systemd services. Saving restarts the running instances; stopped instances stay stopped.
First port, instances	Node.js, Python	Instance n listens on first port + n ($PORT); nginx balances between them. Port ranges of different sites may not overlap.
Node.js / Python version	All except proxy	Runtime used by the app, SSH, terminal, cron and deploys. PHP and static sites use Node.js for npm builds.
Upstream URL	Reverse proxy	Where requests are forwarded.
Verify upstream certificate	Reverse proxy	HTTPS upstreams are checked against the system CA store; disable only for a self-signed internal upstream.
Automatic backups, frequency	All	Back up the site every hour, every 6 hours, daily or weekly (time set under Admin → Backups).
Disk alert	All	Alert the admins when the home folder grows past this many GB.
Page cache (PHP section)	PHP	nginx keeps pages for 1 minute, 10 minutes or 1 hour (fastcgi_cache). Only GET/HEAD requests without cookies or a query string are cached; every cookie, forms, /wp-admin, /wp-login.php, xmlrpc.php and /wp-json always reach PHP, and responses that set a cookie are never stored. Laravel sends its session and XSRF-TOKEN cookies on every page of the web middleware group, so Laravel pages are only cached on routes that skip sessions. Purge cache empties it; a successful deploy purges it too. Responses carry X-Cache: HIT/MISS/BYPASS.

If you changed the vhost by hand, XAXA will not overwrite it when these settings change — update the vhost yourself or reset it to the default.

Start, stop and restart

Node.js and Python sites show the state of every instance on the Overview with Start and Stop buttons; Restart app is in the Actions menu at the top of the site page.

Saving application settings preserves each instance's running or stopped state, also when the port range moves. Additional instances follow the app's previous running state (they start if any instance was running). Explicit Start or Restart app starts all configured instances.

Environment variables

Settings → Environment edits .env, .env.build and .env.runtime in the application directory. Build loads .env then .env.build; the app loads .env then .env.runtime. Service overrides are encrypted in the panel and take precedence at runtime, but are not passed to builds. PORT, HOST, PATH, HOME, USER, LOGNAME and SHELL are reserved. Restarting running instances after a save is optional; stopped instances stay stopped. Changes to .env.build require a new deployment.

At runtime ${NAME} expands in unquoted and double-quoted values from earlier keys or the existing environment; use single quotes or escape $ in double quotes to keep it literal. Shell commands are never evaluated.

Maintenance mode

Actions → Maintenance mode shows visitors a short "back soon" page (HTTP 503 with Retry-After, so search engines come back later) until you choose End maintenance. The site page shows a preview link: opening it sets a cookie that lets that browser see the real site for a day, so you can check your work before turning maintenance off. Anyone with the link can do the same; the link stays the same until maintenance ends.

Let's Encrypt challenges still pass, so certificate renewals keep working. Uptime checks pause (the dot on the Sites list turns amber) and no "site is down" alert is sent; certificate expiry is still tracked. The rule lives in the site's security include, so it also works on a vhost edited by hand as long as it keeps the include …/security.conf; line.

Clone a site (staging)

Actions → Clone site creates a new site with the same type, PHP version, PHP limits and document root, then copies the files and every database in the background. For WordPress the database credentials and URLs are rewritten (wp search-replace); for Laravel the .env database and APP_URL are updated. New database passwords are shown on the clone's Overview.

When a queued clone starts, it rechecks that the requesting account can access both sites. A clone queued before this check was introduced must be started again.

Cron jobs and security rules are not copied, so a staging copy never runs your production jobs twice.

Delete a site

Settings → General → Delete site removes the Linux user and home directory, the site's databases, cron jobs, vhost and certificates. This cannot be undone. The site's backups are moved to /var/backups/xaxa/_deleted/<date>-<user>/ and deleted after 30 days, so a site deleted by mistake can still be brought back (see Backups).

The delete button is shown only to the account that created the site, and it asks for your password before anything is removed. Other administrators and users the site is assigned to cannot delete it; the deletion is recorded in Events (site.deleted with the account and IP). Sites created before this rule — or whose creator was deleted — have no owner and can be deleted by an administrator.