2f. Operations tooling (installer · CLI · SSH gateway)#

The out-of-panel surface — everything documented in docs/install.md and docs/cli.md:

• Installer (install/) — guided setup with a wizard (--express / --dev / --unattended / --dry-run), a single cluster.conf as the source of truth, and verification after every stage. Environment capability is checked honestly per node: container nodes are refused (kernel-layer ip routing isn't usable in an LXC — at least a VM, ideally dedicated), nftables/ip_forward tested, a public ip with an open routing table recommended for the full ingress use case. Day-two: doctor (fix hints, tells a dead service from a dead path), validate, update (build → store snapshot → ship → restart → per-replica verify; refuses a wiped store), backup/restore, repair, guarded uninstall. The proven scripts/ stay underneath and take env overrides.
• CLI (cli/conduit) — zero-dependency Node client over the panel API. Kubectl-style contexts, auth login (mints a personal token), fleet commands (groups/tasks/instances/players with scale, rolling updates, punishments), a real console <vmid> over the per-replica console proxy, logs --follow (SSE), top (live alt-screen fleet view), doctor, an interactive shell with history + completion, bash/zsh completion, and --json/--yes/--quiet everywhere.
• SSH gateway — the console resident on the panel CTs (§2b SSH access): a dedicated sshd on :2202 where ssh -p 2202 conduit@<vip> opens the CloudNet-style console as your panel user — key login, or username sign-in confirmed in the browser / by authenticator code. Banner, sticky prompt with live alert lines above it, screen <vmid> server attach, and an admin-only system shell as the single, confirmed road to the machine.

---