CLI Overview
Command model, host targeting, and argument routing.
Yeet is the client. Catch runs on remote hosts. Most yeet commands are forwarded to catch over RPC on your tailnet. See Tailscale for how RPC and service networking work.
Common patterns:
yeet <command> <svc> [flags] [-- <args...>]
Use --help for standard help and --help-llm for structured help:
yeet --help
yeet run --help
yeet run --help-llm
- Most commands target a service. If you pass a service name, yeet routes the command to that service.
--service=<svc>overrides the service for any command.- If no service is provided, commands run against the system service (
sys). - Some commands are host-level and ignore service selection (e.g.,
mount,umount,list-hosts,prefs).
Service name placement:
- The service name should come after known flags/args.
- Unknown flags before the service name can confuse detection. Use
--to stop flag parsing.
Examples:
yeet status # system-wide view
yeet status <svc> # single service
yeet info <svc> # detailed service info
yeet status <svc>@<host> # specific host
yeet --service=<svc> logs -f # service override
yeet run <svc> ./bin/<svc> -- --app-flag value
--host=<host>: override the target catch host (also set byCATCH_HOST).--service=<svc>: force a service name for the command.
yeet prefs shows the resolved default host. Use yeet prefs --save to persist.
Host scoping shortcuts (catch host):
yeet <command>@<host>for host-only commands (e.g.,events@host).yeet <command> <svc>@<host>to target a service on a specific host.
If a yeet.toml exists with a host list, yeet status (no args) queries each
host.
For commands that accept arbitrary arguments (run, stage, cron), use -- to
separate service args from yeet flags and avoid mis-detection:
yeet run <svc> ./bin/<svc> -- --flag value
yeet cron <svc> ./job "0 9 * * *" -- --job-arg foo
yeet edit and interactive commands require a TTY. Run them from an
interactive shell.