> ## Documentation Index > Fetch the complete documentation index at: https://docs.slipway.sh/llms.txt > Use this file to discover all available pages before exploring further. # The slipway CLI > Deploy, inspect and operate slipway from your terminal. `slipway` is the command-line client, and it comes in two shapes from one binary. Run it with no arguments on a terminal and you get the **full-screen client**: a project list, a live services grid, log tailing, and a shell into any container, all with the state pushed to you rather than polled. Run it with a verb and you get the **scriptable** path: flat commands, `--json` everywhere, and no prompt that can hang a pipeline. Both do the same things through the same code, so nothing is available in one and missing from the other. ## Install Download the binary for your platform and put it on your `PATH`. | Platform | Binary | | - | - | | macOS (Apple Silicon) | [`slipway_darwin_arm64`](https://dl.slipway.sh/cli/latest/slipway_darwin_arm64) | | macOS (Intel) | [`slipway_darwin_amd64`](https://dl.slipway.sh/cli/latest/slipway_darwin_amd64) | | Linux | [`slipway_linux_amd64`](https://dl.slipway.sh/cli/latest/slipway_linux_amd64), [`slipway_linux_arm64`](https://dl.slipway.sh/cli/latest/slipway_linux_arm64) | | Windows | [`slipway_windows_amd64.exe`](https://dl.slipway.sh/cli/latest/slipway_windows_amd64.exe), [`slipway_windows_arm64.exe`](https://dl.slipway.sh/cli/latest/slipway_windows_arm64.exe) | ```bash theme={"system"} curl -fsSL https://dl.slipway.sh/cli/latest/slipway_darwin_arm64 -o slipway chmod +x slipway && sudo mv slipway /usr/local/bin/slipway ``` On Windows, download the `.exe`, rename it `slipway.exe` and put it on your `PATH`. Checksums are at [`checksums.txt`](https://dl.slipway.sh/cli/latest/checksums.txt). ## Signing in `slipway login` shows a short code and opens slipway in your browser. Approve the code there and the CLI finishes signing in. ```bash theme={"system"} slipway login # Confirm this code in your browser: WXYZ-1234 ``` The credential is stored under your platform's local application data directory, in `slipway/credentials.json`. `slipway logout` revokes it and removes it; `slipway tokens list` shows every credential on your account and `slipway tokens revoke` cuts one short from anywhere. Credentials expire 90 days after they are issued. ### In a pipeline `slipway login` needs a browser, so CI uses `SLIPWAY_TOKEN` instead: ```bash theme={"system"} SLIPWAY_TOKEN=sw_... slipway deploy --project shopfront --wait ``` ## The full-screen client ```bash theme={"system"} slipway # on a terminal, this opens it slipway ui # or ask for it explicitly ``` It opens on your projects. `enter` goes in, `esc` comes back, and the header shows where you are. | Key | What it does | | - | - | | `enter` | open the selected project, service or run | | `esc` | back | | `d` | deploy | | `L` | logs | | `s` | shell into the container | | `R` | restart | | `w` | wake a sleeping service | | `b` | roll back | | `o` | open in a browser | | `r` | refresh | | `/` | filter the list | | `f` | follow or pause the log tail | | `ctrl+k` | the command palette | | `?` | every key on this screen | | `q` | quit | The palette is worth knowing. It lists everything the current screen can do, including what does not deserve a keystroke, so nothing is unreachable and there is nothing to memorise. The services grid shows two compute figures whenever they differ, with an arrow between them. The left one is running and being billed; the right one is what the next deploy would apply. Some pages belong in a browser, and `o` opens the equivalent console page rather than the client pretending to draw them: card entry, plan changes, the blueprint editor. ## Linking a directory Most commands need to know which project and service you mean. Instead of passing that every time, link the directory once: ```bash theme={"system"} slipway link slipway status ``` `slipway link` reads your git remote and, when exactly one source in the workspace deploys that repository, offers it. Otherwise pass `--project` and `--source`. It writes `.slipway/link.json`, which ignores itself so nothing lands in your commits. A monorepo gets one link per directory. `apps/api` and `apps/web` can point at different projects, and commands run from a subdirectory inherit the nearest link. `slipway status` is the one command worth memorising. It reports who you are, which workspace and project are selected, **where that selection came from**, your git state, and what every service is doing. ## Deploying ```bash theme={"system"} slipway up # push this branch, then deploy it and wait slipway deploy # deploy what is already on the server slipway deploy --all # every source, not just the linked one slipway deploy --wait # stay attached until every service settles slipway redeploy # re-run the same commit slipway redeploy --no-cache # rebuild without the layer cache slipway rollback # back to the previous images, no rebuild ``` slipway builds from your git remote, so `slipway up` makes sure your commit is pushed first and then deploys it. It will not ship uncommitted work: if your tree is dirty it says which files would be missing rather than deploying something you did not mean. Pass `--push` to push unpushed commits, or `--allow-dirty` to deploy `HEAD` as it is. Manual deploys are limited to the branch the source tracks. To try a change on another branch, open a pull request and let a [preview](/previews/pr-previews) build it. ## Watching ```bash theme={"system"} slipway ps # every service, with state and compute slipway logs # stream the linked service's logs slipway logs -f # keep streaming slipway logs --build # build output only slipway logs api --grep timeout # one service, filtered slipway deployments list # recent runs slipway deployments show # one run in detail ``` `slipway ps` prints two compute figures when they differ: what is running now, and what the next deploy would apply. An arrow between them means a deploy would change the shape. ## Operating ```bash theme={"system"} slipway restart # replace the pods in place slipway wake # bring a sleeping or paused service back slipway services pause api # stop a service deliberately slipway resize api --cpu 1 --memory 1Gi slipway open # open the deployed app slipway open --console # open its page in the console ``` `slipway resize` usually takes effect on the running pods without a restart. When it cannot, the output says a redeploy is needed rather than pretending it applied. ## Working locally ```bash theme={"system"} slipway init # write a starting slipway.yaml for this directory slipway validate # check a slipway.yaml without deploying it ``` Both are entirely local and make no network call. `slipway init` detects the language from the files present; `slipway validate` uses the same parser a deploy does, so its verdict is the one that matters. ## Flags and output Every command takes `--org`, `--project` and `--service`, and each falls back to `SLIPWAY_ORG`, `SLIPWAY_PROJECT` and `SLIPWAY_SERVICE`, then to the link file. Only the workspace also falls back to a machine-wide default, set with `slipway workspace use`. A project is never inherited from a previous command. `--json` puts machine output on stdout and nothing else, so `slipway ps --json | jq` works. Results always go to stdout and progress always goes to stderr, which is why `slipway ps > services.txt` produces a clean file while the terminal still narrates. `--yes` pre-answers confirmations, `--quiet` drops narration, and `NO_COLOR` turns off colour everywhere. Nothing prompts when stdin is not a terminal, when `--json` or `--yes` is set, or when `CI` is set. A command that needs an answer it cannot ask for fails and names the flag that would have supplied it. ### Exit codes | Code | Meaning | | - | - | | 0 | Success | | 1 | Unexpected failure | | 2 | Bad usage, or a missing value with no way to ask | | 3 | Not signed in | | 4 | Your role does not allow this | | 5 | Not found | | 6 | No project or service selected | | 7 | A destructive command needs `--yes` | | 8 | Wrong state for that action | | 9 | Your plan does not allow this | | 10 | Rate limited | | 11 | The workspace is suspended or out of credits | | 12 | The deploy finished and the service did not come up | | 13 | A wait timed out. The deploy may still succeed | Codes 12 and 13 are separate on purpose: a timeout is not a failed deploy, and a pipeline should be able to tell them apart. ## Running a command inside a service ```bash theme={"system"} slipway ssh # a shell in the running container slipway exec -- ls -la # one command, and its exit code ``` Both need the Shell capability on your plan and a Developer role or higher. See [Logs and shell](/observability/logs-and-shell). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.