axol.service) that starts at boot, restarts automatically, and keeps itself in sync with the latest release — you don’t run it by hand. Manual invocation is for development installs:
| Flag | Description |
|---|---|
--host HOST | Interface to bind. Default 0.0.0.0 (reachable on the LAN); use 127.0.0.1 for localhost only. |
--port INT | Port to listen on. Default 8001. |
--open | Open a browser window on startup. Off by default. |
--no-tls | Serve plain HTTP instead of HTTPS. TLS is on by default. |
TLS
TLS is on by default so a browser on an HTTPS origin (e.g. the hosted VR app ataxol.almond.bot) can reach this machine without mixed-content blocking. On first run a self-signed certificate is generated in ~/.almond/vr/certs/ — the same certificate the VR teleop WSS server uses, so accepting it once covers both the control panel and VR teleop.
To connect from a browser on another machine, open the printed LAN URL once and accept the certificate warning. Pass --no-tls to disable TLS entirely (plain HTTP).
Building the web UI
The server looks for the built web bundle atweb/app/dist (a repo checkout only — quick installs have no checkout). If it isn’t there, axol serve still runs and the API is available; use the hosted UI at axol.almond.bot, which connects to the server directly. To serve the UI locally instead, build it once with:
What it serves
| Path | Description |
|---|---|
/control | The control panel UI (operations, connections, settings). |
/vr | The VR teleop interface (same build). |
/ | Redirects by device — headset browsers to /vr, everything else to /control. |
/api/* | JSON + WebSocket API used by the UI. |
The operations launched from the panel run in-process inside the
serve process — the same Python entry points as the teleop, gravity-comp, collect-data, and run-policy CLI commands. Anything those commands need on the host (CAN, the lerobot/sim extras, ZED access) is required here too.