Nerve: a self-hosted cockpit for OpenClaw agent fleets

The gap Nerve is aimed at: chat threads are not a control plane

OpenClaw agents work, but the README makes a specific argument about where they stop working: chat. The project's own framing is that chat is fine for talking to an agent and not enough for operating one. The moment you want visibility into a workspace, coordination across sessions, or a taskboard, the thread becomes the wrong container. Nerve is the answer the repository proposes: a browser-based cockpit that puts workspace, sessions, taskboard, editor, usage and agent context in one place. The audience is narrow and specific. It is for people who already run OpenClaw, who run more than one agent or plan to, and who are comfortable self-hosting a Node application. It is not a hosted SaaS, not a chat client for a single agent, and not a general-purpose LLM front end. The README states the goal directly: run multiple agents from one place, each with its own workspace, subagents, memory, identity, soul and skills, with a single control plane to switch context and inspect state.

Architecture as the repository presents it: a web cockpit over an OpenClaw Gateway

The material describes a split between Nerve and Gateway and offers three deployment shapes. Deployment A runs both on one machine and is labelled the recommended default for reliability and simplicity. Deployment B keeps Nerve local and runs the Gateway in the cloud. Deployment C runs both in the cloud. That split is the main architectural fact available: Nerve is the interface layer, and the Gateway is the thing doing agent work. The front end is a Vite application, and the development instructions expose the split ports directly. npm run dev serves the frontend on :3080 by default, and PORT=3081 npm run dev:server starts the backend on an explicit split-port setup. The capability table lists the surfaces Nerve exposes: a per-agent file browser with a tabbed editor, memory and config editing, a skills browser, a session tree, subagents, cron scheduling, a kanban task board, a review flow, a proposal inbox and model overrides. Observability is a separate column: token usage, cost tracking, a context meter, agent logs and event logs. Voice is listed as a first-class surface rather than a plugin: push-to-talk, wake word flows, explicit language selection, local Whisper transcription, multilingual stop and cancel phrases, and multiple TTS providers. The README does not document the wire protocol between Nerve and the Gateway, the storage model, or the authentication scheme. Those are gaps you would need to read the source or the deployment docs to close.

Getting it running: one curl, or a manual clone with npm scripts

The README gives a single install command: curl -fsSL https://raw.githubusercontent.com/daggerhashimoto/openclaw-nerve/master/install.sh | bash. The accompanying note says the installer handles dependencies, clone and build, and then usually hands off into a setup wizard. Guided access modes listed are localhost, LAN, Tailscale tailnet IP and Tailscale Serve. If you prefer to see what runs, the manual path is git clone, cd into the directory, then npm install, npm run setup and npm run prod. The installer's default clone location is ~/nerve, while a manual clone lands in openclaw-nerve; the update commands in the README account for both. Updating is npm run update -- --yes, which the documentation says fetches the latest release, rebuilds, restarts, verifies health and rolls back automatically on failure. There is also a next branch for pre-release work. A fresh install from it appends --branch next to the installer, and switching an existing install means git fetch origin, git switch next, npm install, npm run build, npm run prod. The README warns that next can change quickly. Note the shape of the primary install path: piping a remote shell script into bash. That is a trust decision, not a technical one, and the repository's own update command is the safer pattern because it verifies health and can roll back.

Where Nerve is the wrong tool

Nerve has no standalone mode. It is a cockpit for an OpenClaw Gateway, so if you do not already run OpenClaw, the install lands you in a setup wizard for something that has nothing to point at. That is the first hard boundary. The second is the deployment split. The README presents three topologies but does not, in the supplied material, document latency, auth or failure behaviour for the hybrid and cloud variants. Deployment A is the only one the repository explicitly recommends, and the reason given is reliability and simplicity, which reads as an admission that the split topologies add moving parts. The third boundary is operational: the update mechanism is a shell script that rebuilds and restarts the application. If your environment cannot tolerate a restart triggered by npm run update, or if you need a versioned artifact rather than a git pull and build, Nerve is a poor fit. The fourth is scope. The capability table is wide, covering voice, editing, kanban, cron and usage, and the README does not describe a plugin boundary or an extension API. If you need one surface to do exactly one thing, this is more application than you asked for.

The closest alternative is the OpenClaw interface you already have

The honest comparison is not another dashboard. It is the default OpenClaw chat interface plus the shell and editor you already use. That combination is free, requires no new service, and has no install script to trust. The difference is what the README calls the operating layer. In the default setup, cron runs, subagent activity, token usage and workspace state live in different places, or in the chat history itself. Nerve's claim is consolidation: cron runs appear as separate sessions, subagents are inspectable without leaving the main thread, usage and context pressure are visible while long tasks run, and the workspace is editable live without switching tools. Whether that consolidation is worth a self-hosted web application depends on how many agents you run. For one agent and occasional use, the default interface is likely enough. For a fleet with per-agent workspaces, memory, identity and skills, the switching cost between tools starts to dominate, and that is the case Nerve is built for. A second alternative is writing your own thin UI against the Gateway, which the deployment docs imply is possible but which the README does not document as a supported path.

Maintenance, versioning and the MIT licence

The release history in the repository metadata shows v1.5.1, v1.5.2 and v1.5.3 between March and April 2026, with the last push to master in June 2026. That cadence suggests active maintenance, though the supplied material does not describe a support policy, a deprecation process or a compatibility matrix for OpenClaw versions. The upgrade path is npm run update -- --yes, which the README says verifies health and rolls back on failure, so the practical cost of staying current is a rebuild and restart per release. Running the next branch raises that cost: you track unreleased work and accept that it can change quickly. The project is MIT licensed, which permits commercial use, modification and redistribution provided the licence and copyright notice are preserved. That is a permissive licence, and it places no copyleft obligation on your own code. It also means no warranty and no support commitment from the authors. This is a general description of MIT terms, not legal advice for your situation; if you plan to redistribute Nerve or bundle it into a product, have counsel review the LICENSE file in the repository.

What to verify before you commit

Three things are worth checking before you run the installer. First, confirm your OpenClaw Gateway is reachable from the machine that will host Nerve, and decide which of the three deployment documents matches your network. The README's guided access modes (localhost, LAN, Tailscale tailnet IP, Tailscale Serve) are the vocabulary the setup wizard uses, so knowing which one applies saves a round trip. Second, read install.sh before piping it into bash, or use the manual clone path with npm run setup and npm run prod so you can see each step. Third, test the rollback path deliberately: run npm run update -- --yes once on a throwaway install and confirm the health check and rollback behave as documented. If you run multiple agents with distinct workspaces and identities, and you already self-host OpenClaw, Nerve is the consolidation layer the README claims to be. If you run a single agent, or you need a managed service with a support contract, the default OpenClaw interface is the cheaper answer.

Editorial conclusion

Adopt Nerve if you already operate one or more OpenClaw agents on hardware you control and you want a single browser surface for voice, workspace editing, session trees and usage. Do not adopt it if you have no OpenClaw Gateway, or if you need a hosted product with an SLA. Before installing, verify that the Gateway is reachable from the machine you plan to run Nerve on, that the install script at raw.githubusercontent.com is the one you intend to trust, and that the npm run update rollback path is acceptable for your environment.

Official sources

1. daggerhashimoto/openclaw-nerve on GitHub
2. License: MIT
3. Project website
4. README
5. Releases