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
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.
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
| Task | Query |
|---|---|
| How many users | SELECT count(*) FROM users; |
| Database size | SELECT pg_size_pretty(pg_database_size('xpanel')); |
| Latest audit records | SELECT * FROM admin_audit_log LIMIT 10; |
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.
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
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.