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 yourPATH.
.exe, rename it slipway.exe and put it on your PATH.
Checksums are at 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.
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:
The full-screen client
enter goes in, esc comes back, and the header
shows where you are.
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: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
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 build it.
Watching
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
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
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
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.