Linux Deployment
Use this runbook on a Linux host with systemd. The commands use a Debian or Ubuntu
service-account layout. Run the user steps as the intended user and the sudo
steps as an administrator. For a server used by other computers, continue with
Remote Linux: Deploy the Daemon.
Prepare the Host
Install a verified binary using Installation. Put it at the stable path used by the managed bundle:
Complete Configuration and Managed Clients on this
computer. In these examples the bundle uses /opt/nvidia/bin/nemo-relay directly
as its dispatcher and http://127.0.0.1:47632 as its daemon address.
Administrator-owned binaries and configuration must not be writable by users.
Choose one of the following services. A user service stays tied to its user manager; a system service serves all local users independently of their logins.
User Service
Create the unit directory and private identity-state directory:
Save this complete unit as ~/.config/systemd/user/nemo-relay-daemon.service:
Start it now and at future user-manager starts:
To keep this user manager running after logout and start it at boot, an administrator can enable lingering:
Without lingering, do not promise availability before login or after logout. Multiple users running separate daemons must use different ports and matching bundles. For a shared endpoint, use the system service below.
System Service
Create a dedicated account with a persistent home. The daemon stores its signing identity here; replacing the home can cause clients to reject its new identity.
If the account already exists, verify its home and ownership instead of creating
it again. Save /etc/systemd/system/nemo-relay-daemon.service:
Enable the service:
The service needs no NEMO_RELAY_CLIENT_TOKEN. Each user’s harness supplies its
own token to MCP and hook processes. The worker runs as that user, not as the
nemo-relay service account.
Verify and Operate
Check the listener, then launch a configured harness and complete the worker-backed verification:
The expected listener is 127.0.0.1:47632. A listening socket proves only that a
process has opened the port. Use the service journal to confirm that it is Relay.
Worker messages appear in the harness’s MCP stderr log, not the daemon journal.
Use the matching restart command after a unit or binary update:
Run daemon-reload first if you edited the unit. Follow the shared
upgrade procedure to drain sessions,
keep identity state, and validate the unchanged bundle. Test logout/login for a
user service and a planned reboot for a system service before rollout.
Remove the Service
Close harness sessions first. For a user service:
If you enabled lingering only for Relay, disable it with
sudo loginctl disable-linger "$USER". Other user services may still need it.
For a system service:
Retain identity state for rollback. Remove the service account, binary, and managed artifacts only after confirming that no other deployment uses them. See systemd service documentation for unit behavior.