[nickolasdeluca]

Connecting a machine meant issuing a credential in one tab, reserving a name in another, then writing the drip command line by hand on the host and getting the flags right. This adds a Patch in tab that builds that line.

Deployment stays two steps. Installing the binary is still whatever that fleet already does — nothing here renders an installer, and nothing depends on how drip arrived on the host.

What it does

The tab asks what the machine serves, then renders the command it runs once the binary is installed, in three platform variants with copy and download:

drip config set --server tunnel.example.com:443 --token PASTE_TOKEN_HERE \
  && drip config tunnel add --name billing --type http --port 8080 --subdomain billing --replace

Decisions worth reviewing

• The command is rendered in Go, not in the panel. Shell and PowerShell quoting is what keeps a value the operator typed from becoming syntax, so it belongs where it can be tested directly.
• An existing credential renders PASTE_TOKEN_HERE. Only sha256(secret) is stored, so a token issued earlier cannot be read back. Issuing one from the builder embeds the real token, returned exactly once the way POST /api/clients returns it.
• Allocations are adopted, not fought over. A name the account already holds is reused and bound to the machine, so rebuilding the command for a deployed machine is safe. One owned by another account, or bound to another machine, is refused.
• Windows autostart passes --reseed — the step before it rewrote the user config, and service install would otherwise keep a stale %ProgramData% copy — and follows with service start, which install does not do. The Windows script is one command per line, since && needs PowerShell 7.
• A tcp tunnel gets no --subdomain. The reservation pins the port and the client binds it by asking for nothing.

Testing

12 new tests in api_provision_test.go cover the rendering, the quoting, allocation reuse, cross-account refusal and the credential paths. go vet and go test -race ./... are clean.

Also driven end to end against a local deployment: the generated command configured a machine with an isolated HOME, the tunnel bound its reserved port, and traffic through the public port returned 200.

Not in this PR

Reserving a TCP port still does not check the server's configured port range — the panel has never done this and admin.Deployment does not carry tcp_port_min/max, so a port outside it is accepted and refused later at registration. Recorded in AGENTS.md; fixing it belongs in both reservation paths or neither.