Server / deploy
How the daemon side gets onto your remote host and stays running. Most users don’t need any of this — the plugin auto-deploys the daemon on connect. Reach for these pages when you want to manage the daemon yourself (systemd, containers, multiple users on one host, restricted networks).
Start with the Server overview — it covers what the daemon is, what it needs from the host, and what it does NOT do. The other pages are the deployment options.
Pages
| Page | What it covers |
|---|---|
| Overview | What the daemon is, what it needs, what it does not do |
| Plugin auto-deploy | The default — what happens when you click Connect |
| Docker | Run the daemon inside an sshd container; turn-key compose file |
| systemd | Per-user systemd unit; production-grade lifecycle management |
| Raspberry Pi | Pi-specific notes — SD card vs USB SSD, ARM binary, expectations |
| Multi-user hosting | One host, many SSH users; the per-user-state model + the anti-pattern of sharing one OS user |
| Firewall, ports & NAT | Why the daemon needs no public ports + how Tailscale/wireguard fit in |
| Signing | Operator-side: what the cosign signatures cover, when to verify, who signs |
Reading order
For “I just want it to work”:
- Read Overview to understand what gets deployed.
- That’s it. The plugin handles everything else.
For “I want to run my own daemon under systemd”:
- Overview for context.
- systemd for the unit file.
- Daemon CLI reference for the flag set the unit invokes.
For “I’m setting up a multi-user host”:
- Overview.
- Multi-user hosting — read carefully; the wrong setup leaks state between users.
- Firewall, ports & NAT if the host is internet-facing.
See also
- Daemon CLI reference — every flag the binary accepts
- Cosign verify — verify the binary you downloaded before deploying it manually
- Release pipeline — how the binary is built + signed
- Cookbook: systemd-managed daemon — full walkthrough recipe