Before enabling access
- Treat the daemon API as a control plane, not a public web API.
- Prefer a private network such as an operator-owned tailnet over direct internet exposure.
- Protect the remote bearer token as a credential.
- Review the tools, sandboxes, channels, and agent runtimes the daemon can reach.
- Keep developer mode off; local Scalar includes internal routes and must not be publicly proxied.
Enable it
Enabling remote access is the one setup flow that runs in the browser: Settings → Connection. Turning it on makes the daemon generate the bearer token itself, enable TLS in the same write, and show the token once so you can copy it. Plain-HTTP remote access requires an explicit confirmation. There is deliberately nomonad config set network.remoteAccess.token …: a secret passed
as an argument is readable by every local user through ps and lands in shell history.
Flipping network.remoteAccess.enabled by hand in config.json would also leave the
token empty, so use the Connection screen.
The CLI owns everything around it:
Runtime protections
When remote access is enabled, non-loopback TCP requests require the configured bearer token. The daemon applies per-IP rate limiting before token comparison and keeps browser-origin checks separate from bearer authentication. Local Unix-socket and loopback clients retain their local trust behavior. TLS configuration and certificate status belong to the daemon’s network settings. Confirm the listener, scheme, certificate fingerprint, and expiry from a trusted local client before connecting another device.Validation checklist
- Run
monad statuslocally and confirm the intended listener. - Confirm remote access is disabled on interfaces you did not intend to expose.
- Connect from the second device over the private network using the bearer token.
- Verify an unauthenticated remote request is rejected.
- Verify the required client can read health and perform only its intended workflow.
- Review logs without copying credentials into a bug report.