Reset only the named module (removes it from completed_modules, clears its tx records and workspace report). Wallet, other modules, and audit packs are preserved
--confirm
Skip the confirmation prompt (granular --module mode only)
xrpl-lab serve starts the FastAPI backend that drives the bundled web dashboard. Facilitators use it during workshops for at-a-glance cohort monitoring, kill-switch control of in-flight runs, and a click-through artifact viewer; integration users hit the same surface programmatically via REST + WebSocket.
Terminal window
# Start the API on the default port
xrpl-labserve
# Custom port + offline sandbox for a demo cohort
xrpl-labserve--port9000--dry-run
API docs are auto-published at http://<host>:<port>/docs once the server is running.
API server port. The dashboard’s frontend hardcodes http://localhost:8321 for fetch calls, so non-default ports require you to drive the API directly (curl, custom client) rather than the bundled UI
--host <H>
127.0.0.1
Bind address. Stays on loopback by default — workshop threat-model line. Override only when you understand the exposure (e.g., a trusted LAN-only facilitator station)
--dry-run
off
Run the entire dashboard surface in offline-sandbox mode. Useful for projector demos with no internet, or for facilitators rehearsing the workshop flow without funding wallets
In development, the Astro site runs separately on port 4321:
Terminal window
# Terminal 1 — API
xrpl-labserve
# Terminal 2 — Astro dev server (hot reload)
cdsite && npmrundev
Open http://localhost:4321/xrpl-lab/app/ to use the dashboard.
In production (after cd site && npm run build), the FastAPI app serves both the API surface and the built dashboard from one process — xrpl-lab serve is the only command you need.
The dashboard is the surface most workshop facilitators run on a second monitor while the cohort works in their own terminals. It is the live cohort view: per-run module ID, status, queue depth, kill button on stuck runs, capacity badge. See the facilitator dashboard page for what each piece of that surface tells you and how the kill-switch semantics work.
All commands support --dry-run for offline mode where applicable. Dry-run mode simulates transactions without touching the network — useful for learning the workflow or working without an internet connection.