Skip to main content
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 your PATH:
PlatformBinary
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
curl -fsSL https://dl.slipway.sh/cli/latest/sw_darwin_arm64 -o sw
chmod +x sw && sudo mv sw /usr/local/bin/sw
On Windows, download the .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.
sw login
# Confirm this code in your browser: WXYZ-1234
The token is stored 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

sw whoami                                # who am I?

sw orgs list                             # orgs you belong to
sw orgs use acme                         # set the default org

sw repos list                            # repos in the default org
sw deployments list                      # recent deployments (alias: sw deps)
sw deployments list --status failed      # filter by status
sw deployments view <id>                 # detail for one deployment
sw deployments logs <id> --follow        # stream logs, stay attached
sw deployments events <id>               # lifecycle events

sw dev up                                # ephemeral dev instance of an environment
sw dev ls                                # live dev instances
sw dev down <instance>                   # tear one down

sw port-forward <inst> api/postgres 5432 # forward a service port to localhost (alias: pf)
sw exec <inst> api/api -- printenv       # run a command in a container
sw exec <inst> api/api                   # …or an interactive shell
Override the default org for one command with -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.
# Forward a service port to localhost
sw port-forward 3f9a1c20 api/postgres 5432:5432   # a bare port maps 1:1

# Run a command, or open a shell
sw exec 3f9a1c20 api/api -- ./bin/rails db:migrate
sw exec 3f9a1c20 api/api                           # interactive shell
Leave 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.