Skip to main content

Useful Commands

A collection of commands for everyday XLADA operations. Unless stated otherwise, the examples are run on the panel server from the /opt/xlada directory, where docker-compose.yml lives.

The services are described in a single compose file: xpanel (the panel), xpanel-db (PostgreSQL), xpanel-redis (Valkey), and the optional xpanel-subpage (the subscription page). The panel and subscription page ports are bound to 127.0.0.1 — nginx exposes them to the outside.

Panel​

cd /opt/xlada

docker compose ps # status of the xpanel, xpanel-db, xpanel-redis services
docker compose logs -f xpanel # panel logs in real time
docker compose logs --tail=100 xpanel-db
docker compose restart xpanel # restart the panel only
docker compose up -d # apply changes in .env

The same logs are convenient to view directly, without compose:

docker logs -f xpanel
docker logs --since 30m xpanel

A full stack restart without data loss:

docker compose down && docker compose up -d
danger

Never add the -v flag to docker compose down: it deletes the volumes along with the database and all users. The safe upgrade procedure is in Upgrading.

Emergency operations (for example, resetting the superadmin password) are performed by the panel CLI:

docker exec -it xpanel cli

The full list is in Rescue CLI.

note

After editing .env, run docker compose up -d: compose recreates the changed containers and re-reads the variables. The docker compose restart command does not re-read the environment — it is not enough if you changed METRICS_USER or domains.

Internal services​

The panel stores data in PostgreSQL and cache in Valkey. Check both:

docker exec -it xpanel-db pg_isready -U xpanel -d xpanel
docker exec -it xpanel-redis valkey-cli ping

The expected responses are accepting connections and PONG.

Database​

A dump before an upgrade or manual edit is the only reliable way to roll back. It is taken inside the container, so you do not need to install pg_dump and psql on the host, and the backup-...sql file appears in the current directory.

docker exec xpanel-db pg_dump -U xpanel xpanel > backup-$(date +%F).sql

Restore:

docker exec -i xpanel-db psql -U xpanel -d xpanel < backup-2026-01-01.sql

Interactive console:

docker exec -it xpanel-db psql -U xpanel -d xpanel
TaskQuery
How many usersSELECT count(*) FROM users;
Database sizeSELECT pg_size_pretty(pg_database_size('xpanel'));
Latest audit recordsSELECT * FROM admin_audit_log LIMIT 10;
note

Filters by administrator and result for the action log are more convenient to view in the interface — the Audit Log page, not in psql.

Node​

A node is a separate container on a proxy server, so the commands are run where it is deployed:

docker logs -f xpanel-node # node log and SECRET_KEY check
docker exec -it xpanel-node xlogs # Xray-core logs
docker exec -it xpanel-node cli --clear-logs

Xray log cleanup can also be started from the panel: the Logs page, section "Node system logs". The node rotates the file without restarting Xray — active connections are not dropped. See Node Installation for details.

Ports​

ss -tlnp | grep -E ':(3000|3001|3010|2222)\b' # who is listening on XLADA ports
nc -vz 203.0.113.10 2222 # NODE_PORT from the panel server

Checking the panel locally and from outside:

curl -sI http://127.0.0.1:3000
curl -s -o /dev/null -w '%{http_code}\n' https://panel.example.com/api/auth/status

Port 2222 does not need to be open to the whole internet: a firewall rule for the panel IP is enough. Proxy ports, on the contrary, are set by the Xray configuration and must be open to clients.

tip

Check NODE_PORT from the panel server, not from a browser: the panel contacts the node itself, and port availability from the internet proves nothing.

Certificates​

certbot certificates # what is issued and until what date
certbot renew --dry-run # test auto-renewal
certbot --nginx -d panel.example.com # issue a certificate
systemctl list-timers | grep certbot # is the renewal timer active

After editing the nginx configuration, always check the syntax:

nginx -t && systemctl reload nginx

Metrics​

Prometheus metrics are exposed on 127.0.0.1:3001 under basic auth. The login and password are taken from the same METRICS_USER and METRICS_PASS variables as when starting the panel:

source /opt/xlada/.env
curl -s http://127.0.0.1:3001/metrics -u "$METRICS_USER:$METRICS_PASS" | head
warning

Port 3001 must not be open to the outside. If an external Prometheus scrapes the metrics, point it at 127.0.0.1:3001 through an SSH tunnel or a separate proxy rather than opening the port in the firewall.

What's next​

  • Upgrading — the upgrade procedure and rollback from a dump.
  • Rescue CLI — emergency panel commands.
  • Common Errors — what to do if a command does not work.