sw is the slipway command-line client. It does most of the read operations you’d otherwise do in the dashboard — list orgs, browse repos, watch deployments, tail logs — and spins up dev instances you can port-forward and exec into. Secret editing and settings stay in the web UI.
Install
Grab the binary for your platform and put it on yourPATH:
| Platform | Binary |
|---|---|
| macOS (Apple Silicon) | sw_darwin_arm64 |
| macOS (Intel) | sw_darwin_amd64 |
| Linux (x86_64 / arm64) | sw_linux_amd64 · sw_linux_arm64 |
| Windows (x86_64 / arm64) | sw_windows_amd64.exe · sw_windows_arm64.exe |
.exe, rename it sw.exe, and put it on your PATH. Checksums are at checksums.txt.
Log in
sw login shows a short code and opens slipway in your browser; approve the code there (signing in with GitHub or GitLab if needed) and the CLI finishes logging in.
0600 under your platform’s config dir (~/.config/slipway/credentials.json on Linux, ~/Library/Application Support/slipway/ on macOS, %APPDATA%\slipway\ on Windows). sw logout removes it.
Common commands
-o <slug>.
Port-forward & exec
Once a dev instance is up,sw port-forward and sw exec work against its services from your machine — tunnelled through slipway over a single authenticated connection, no cluster credentials. Services are addressed as <component>/<service>; drop the <component>/ prefix when the instance has only one component.
port-forward running and press Ctrl-C to stop; each local connection gets its own tunnel. Both commands need the developer role.
Port-forward keeps the tunnel open but doesn’t heartbeat the instance — keep
sw dev up running (or rely on its TTL) so the instance stays alive while you work.Tokens
sw tokens are opaque bearer strings starting with sw_, stored hashed on the server and returned only once at login. Lost the credentials file? Run sw login again to mint a fresh token. Tokens expire 90 days after issue.