Skip to main content
If you use the desktop app, you usually do nothing here: the app starts a daemon on your computer, signs it in with your account, and it appears under Settings → Machines as connected. This page is for everything else: a workstation you only reach over SSH, a home server, a Raspberry Pi, or a second laptop. For those you run the daemon yourself with the reliant CLI (installing it). The daemon dials out to Reliant over a persistent gRPC stream, so the computer needs no open inbound port. Your repository stays on it. Whatever an agent reads or a command prints is sent to Reliant’s servers, stored with the chat and sent to your model provider; see Privacy & security.

​
Register and start

Register once. It signs you in through your browser if you are not already, creates a long-lived access token for this computer, and stores it in ~/.reliant/daemon.json:
Then start the daemon:
In practice you can skip register: if you run start without credentials it signs you in and registers on the spot. By default it runs in the foreground; add --background to detach it. When it connects, the computer shows up as a machine in the app, named <instance-id>@<hostname> unless you pass --name.
If the daemon loses its connection or is told its credential is no longer valid, it re-registers and reconnects by itself. You do not need to restart it for a network blip.

​
Headless and CI machines

Where no browser is available, pipe an access token with the daemon:connect scope into --token. Create one under Settings → Access Tokens:
Use --non-interactive when something else owns sign-in (this is how the desktop app launches it). The daemon then never opens a browser; it stays idle, reports that it is awaiting credentials, and picks them up as soon as a credentials file appears on disk.

​
Flags

The global --server and --gateway flags choose which Reliant server the daemon talks to. Release builds already point at Reliant’s hosted service, so you normally leave them alone.

​
One daemon per workspace

A daemon is identified by three things: the server it talks to, the account it runs as, and the workspace it serves. Each combination has its own folder under ~/.reliant/instances/, holding its runtime record and logs. Because the workspace defaults to the git worktree root of the directory you run the command in, every subdirectory of one checkout is the same daemon, while a second worktree is a separate one. This is why stop, status and logs find the right daemon no matter which subdirectory you run them from.

​
Check on it

status exits non-zero unless the stream to Reliant is actually established, so it is safe to use in a script: “running” means connected, not merely “a process exists”.

​
Troubleshooting

The daemon will not connect. Run reliant daemon status. If credentials are stale, delete ~/.reliant/daemon.json and run reliant daemon register again. Two daemons seem to fight. Run reliant daemon ls to see every instance. A stop that did not finish can leave a daemon holding its registration; reliant daemon stop waits for the process to exit and escalates to a kill if it does not, and exits non-zero if it could not. TLS errors against a development server. Use --tls-mode insecure_tls_skip_verify for self-signed certificates in development only.