Connecting the CLI
Once scd-server is running, each developer connects their local scd CLI to it.
Configure the CLI
scd configure --central-url http://your-server:3000
scd configure --token <api-token-from-config-yml>
Use the same api_token you set in config.yml on scd-server.
Verify the connection:
scd doctor
scd doctor shows the server status, license tier, expiry, and whether the CLI version meets the minimum required version.
Adjust timeouts if needed
The defaults work for most setups, but you can adjust:
scd configure --server-timeout 30s # regular API calls (default: 30s)
scd configure --deep-timeout 20m # deep analysis (default: 20m)
Deep analysis runs AI on your findings — 10–20 minutes is normal for large codebases. Do not lower the deep timeout.
Push local scan history
If a developer has been scanning locally before connecting to scd-server, push their existing history:
scd sync --history
This is idempotent — safe to run multiple times.
After connecting
From this point on, every scd scan pushes results to scd-server automatically. No extra commands needed.
The team dashboard at http://your-server:3000/dashboard shows aggregated findings across all connected developers.
Distributed teams (Tailscale)
If your developers are not on the same network, Tailscale is the recommended way to make scd-server reachable:
- Install Tailscale on the machine running scd-server and on each developer machine
- Use the Tailscale IP or hostname as
--central-url - No firewall rules or port forwarding needed
Headscale is a self-hosted alternative to the Tailscale coordination server if you prefer to avoid any external dependency.