OpenClaw Dashboard: a self-hosted control panel for OpenClaw agents

The gap it fills for people running OpenClaw on their own box

OpenClaw agents run as background processes. Their output lands in session files and workspace memory files, their API calls hit rate limits, and the machine hosting them has a CPU, a disk and a temperature. Without a UI, checking any of that means reading files over SSH. openclaw-dashboard puts those checks in one page: session list with live activity status, rolling-window usage against Claude and Gemini limits, cost breakdowns by model and session, a live message feed, and a memory browser for MEMORY.md, HEARTBEAT.md and daily notes. The audience is narrow and specific. You need OpenClaw installed and a workspace directory to point at, and the README's optional-dependency table shows how much of the feature set is tied to the host: jq for the Docker page, tmux and python3 for the Claude CLI usage scraper, docker for container management. This is a control panel for a single operator's machine, not a fleet console.

How the dashboard gets its data: files, shell commands and SSE

The repository is primarily HTML, and the README states the server is pure Node.js with no database and no npm packages required. That shapes the architecture. Persistent state is written to disk, and the data shown in the UI is read from the OpenClaw installation and the surrounding system. The documented environment variables describe the mapping: WORKSPACE_DIR points at the agent workspace, OPENCLAW_DIR defaults to $HOME/.openclaw, OPENCLAW_AGENT defaults to main. The live feed is a server-sent events stream, which the topics list confirms with sse. Some panels are not file reads at all. The README lists a Claude Usage Scraper that fetches real usage data from Claude Code CLI, and the optional dependencies show it needs tmux plus python3, so a session is being driven and its output parsed. The Docker page needs jq, which means container data arrives as JSON from the docker CLI and is filtered through it. The system health panel reports CPU, RAM, disk and temperature, and macOS support is called out separately, so the collection path differs by platform. Two panels, the security dashboard and the config editor, require re-authentication before they open. That is a deliberate second gate in front of the parts that can change the machine or expose its attack surface.

Getting it running: three paths, one port

The README gives a manual path, a systemd path and a Docker path. Manual is the shortest: clone the repository, optionally export WORKSPACE_DIR, then run node server.js. The server prints the listening URL and a recovery token, and the README tells you to save that token because it is the way back in if you forget your password. First visit shows a registration screen where you create the username and password. If you want the dashboard to survive a reboot, sudo ./install.sh creates /etc/systemd/system/agent-dashboard.service plus an override file at /etc/systemd/system/agent-dashboard.service.d/override.conf, enables and starts the unit, sets the workspace path and generates the recovery token. Logs come from journalctl -u agent-dashboard -f. The Docker example builds an image tagged openclaw-dashboard and runs it with -p 3001:3001, WORKSPACE_DIR=/app/workspace, DASHBOARD_ALLOW_HTTP=true, and two read-only or bind mounts for ~/.openclaw and the workspace. Note the port mismatch: the manual and systemd paths use 7000 via DASHBOARD_PORT, while the Docker example publishes 3001. The README does not explain the difference in the material available here, so treat the container's internal port as something to confirm against the Dockerfile before you rely on it.

Security model: PBKDF2, TOTP, and the parts that still depend on you

Authentication is username and password with PBKDF2 hashing, and TOTP two-factor is optional and Google Authenticator compatible. Sessions can be session-only or persistent for three hours under the Remember Me option. The README lists HSTS, CSP, rate limiting, timing-safe comparisons and audit logging as hardening measures, and the notification center surfaces that audit log as a feed with an unread badge for logins, config changes and security events. Two design choices deserve scrutiny. First, the security dashboard and config editor require re-authentication before use, which limits the damage from a stolen session cookie. Second, the Docker example passes DASHBOARD_ALLOW_HTTP=true, which the README presents as part of the run command without qualification. If you follow that example on a host reachable from a network you do not control, credentials travel in the clear. The README does not describe a built-in TLS terminator, so a reverse proxy is the implied answer. The licence is a separate question: the README carries an MIT badge, but the repository metadata supplied here lists the licence as unknown. Verify the LICENSE file before you redistribute anything.

Where it breaks down, and who should not use it

The dependency on the host is the main failure mode. The Docker page needs jq and the docker binary; the Claude usage scraper needs tmux and python3. If any of those are missing, the README does not say whether the panel degrades gracefully or errors, and there is no fallback path documented. The scraper is the weakest link: parsing the output of a CLI through tmux is fragile in a way that reading a JSON file is not, and a CLI output change can silently break the numbers you are using to decide whether to keep spending. Cost tracking has the same character. The README mentions cost estimation and Gemini usage tracking arriving in v2.4.0 and v2.3.0 respectively, which suggests the cost model is assembled from usage data rather than read from an authoritative billing source. Treat the figures as an estimate, not an invoice. The system control features are the other boundary: restart buttons, cron triggers, Docker prune and a config editor with auto-backup and gateway restart all act on the machine, so a compromised dashboard is a compromised host. And if you are not running OpenClaw, none of this applies. There is no generic agent support here.

How it compares with a general metrics stack

The obvious alternative is Prometheus with node_exporter and Grafana. That stack is better at the thing this dashboard does not attempt: long retention, alerting rules, and correlating many hosts. It is also indifferent to what is running on them. You would get CPU, RAM and disk from node_exporter, but not a session list, not a memory file browser, not a live agent message feed, and not a config editor with JSON validation. The difference in approach is that Prometheus pulls numeric samples into a time-series database and expects you to write the queries, while openclaw-dashboard reads OpenClaw's own files and shells out to its CLI, then renders the result. The trade is depth of integration against breadth of coverage. A second alternative is doing nothing and using journalctl plus the OpenClaw CLI directly. That costs no additional attack surface and no extra service, and for a single agent on a laptop it is a reasonable answer. The dashboard earns its place when you want the data visible without SSH, and when you accept that the visibility comes with a web process holding restart and prune permissions.

Maintenance cost and what to check before you deploy

There is little to maintain in the usual sense. No database means no migrations, and no npm packages means no dependency upgrade treadmill. The release cadence visible here is roughly one version every one to three weeks across v2.3.0, v2.4.0 and v3.0.0, with v3.0.0 adding dark and light themes, a security dashboard, a config editor, Docker management and notifications. Upgrades are a git pull plus a service restart, or an image rebuild for Docker. The recurring cost is environmental: keep jq, tmux, python3 and docker present if you want the panels that use them, and re-check the Claude scraper whenever the CLI changes, since that is the component most likely to break without a version bump here. For licence, the README badge says MIT while the repository metadata says unknown, so read the LICENSE file rather than the badge. This is not legal advice. The concrete checks before deployment: confirm the port you intend to publish matches the server's actual listening port, confirm the account is registered and TOTP enabled, and confirm whether DASHBOARD_ALLOW_HTTP is set in your unit file or container environment.

Editorial conclusion

Adopt it if you already run OpenClaw on a machine you control and you want session, cost and system data in one browser tab without adding a database or npm dependencies. Do not adopt it if you are not running OpenClaw, or if you need a hosted multi-tenant service: the README describes a single self-hosted instance whose registration screen is open on first visit. Before exposing it beyond localhost, confirm the account is registered, TOTP is enabled, and the reverse proxy terminates TLS, because the documented Docker example sets DASHBOARD_ALLOW_HTTP=true.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. tugcantopaloglu/openclaw-dashboard on GitHub