Command line

si creates Serverless App Services, pushes and deploys, follows builds and runtime logs, and manages environment variables and domains. It acts as you, with your role in each organization. It's a single binary for macOS, Linux and Windows. It isn't the self-hosted agent, which runs jobs.

Install

curl -fsSL https://cloud.cactive.com.au/install.sh | sh

irm https://cloud.cactive.com.au/install.ps1 | iex

si upgrade replaces the binary with the latest release (verified the same way); si upgrade --check only checks. Once a day, commands mention a newer release on stderr.

Sign in

si login

The browser opens https://id.cactive.com.au/device with a code. Check that it matches the one in your terminal, and approve. The approval page lists what the command line can do: everything your role allows in each of your organizations, plus creating git keys for this machine. Unless you signed in to ID in the last five minutes, approving asks for one of your passkeys or your password.

The session is stored in the operating system's credential store, never in a plain file: the macOS Keychain, the Secret Service (secret-tool) on Linux, or Windows Credential Manager. Linux machines without a Secret Service (servers, containers) use ~/.config/si/credentials.json, readable only by you. Access tokens last 15 minutes and refresh on their own; a sign-in lasts 30 days from its last use.

Signed-in machines are listed on your account page at https://id.cactive.com.au under Command Line. Sign Out ends that machine's session at once (its current access token stops working too) and revokes its git keys; so does si logout on the machine itself.

Git credentials

si git setup

Makes si git's credential helper for https://git.cactive.com.au and its former name https://git.gov.vin (remotes added before the move use it) only:

[credential "https://git.cactive.com.au"]
	helper =
	helper = !si git-credential
	useHttpPath = true
[credential "https://git.gov.vin"]
	helper =
	helper = !si git-credential
	useHttpPath = true

The empty helper line stops helpers configured for every host (such as osxkeychain) from answering for this one, so an old stored password can't shadow the key. Other hosts keep their helpers. si git setup --remove undoes it.

When git needs credentials for a repository, the helper creates an API key for this machine in that repository's organization, with the git scopes your role has (git:read, and git:write for developers and up). It's named after the machine, e.g. lukes-macbook (CLI), expires after 90 days and is replaced a week before that. It's stored in the credential store, never in git's config. Keys are listed in the organization's Keys in ID and on your account page, where you can revoke them.

Commands that clone or push (init, clone, deploy) use the helper for that command even without git setup.

Create or link a Serverless App Service

cd my-app
si init

Creates a repository and a Serverless App Service named after the folder (or si init <name>) in the current organization, commits the folder if it has no commits yet, adds the remote (origin, or si when origin is taken), pushes and follows the first deployment. The framework is detected from package.json (--framework overrides it); --root <dir> sets the app's directory in a monorepo. --template nextjs or --template static starts an empty folder from a template.

The link is .si/project.json (organization and Serverless App Service ids, nothing secret), excluded in .git/info/exclude so it doesn't change the repository.

Deploy

si deploy

• In a clean checkout of the Serverless App Service's repository, it pushes the current branch and follows the build that push starts. Pushing the production branch deploys production; other branches get previews, as with git push. --prod builds the pushed commit as production from any branch.
• Otherwise (not a git repository, uncommitted changes, a detached HEAD, a Serverless App Service without a repository, or --upload), it uploads the working tree and builds that. Uploads are previews unless --prod. In a repository the upload is what git add -A would commit, as it is on disk; elsewhere it's the folder without node_modules, .git, .next, .env, .env*.local and patterns in .gitignore or .siignore. Archives are limited to 250 MB compressed and kept 30 days, so the deployment can be redeployed meanwhile.

Uploads are incremental. Before sending anything, si deploy describes the working tree (each file's path, mode and content hash, as git computes it). If a ready deployment for the same target already has exactly these files, built with the same environment variables and settings (for production: the one production serves), nothing is uploaded or built: the deployment is recorded as skipped and the existing one keeps serving; --force builds anyway. Otherwise only the files that differ from the Serverless App Service's last full upload of the past 25 days are sent, when that's clearly smaller than everything; the build starts from that upload, removes the files you deleted and adds the changed ones.

The build output streams to your terminal, then the deployment's URL (and the production URL) is printed. The command exits with 1 when the build fails. --no-wait returns once the deployment has started. A commit that already has a building or ready deployment for the target isn't built twice; --force builds it again.

A deployment can be named by its id, its last 8 characters (as shown in lists and hostnames) or its URL. See Preview and production.

Logs

si logs --follow

Runtime logs of the production deployment (or the deployment given): the last hour, oldest first. --follow keeps printing new lines, --since 10m starts further back (at most an hour), --query <text> keeps lines containing the text (case-insensitive) and --level warn keeps warnings and errors. --build prints the build output instead. With --json, each line is a JSON object. See Logs.

--follow streams: every line is pushed as soon as the platform receives it, including lines that arrive a few seconds after they were written, and none is printed twice. The stream renews itself every 13 minutes, re-reading the last minute so nothing late slips between two streams. When more than 500 lines a second match, the stream samples them and says so. If streaming isn't available (very busy accounts), it polls every 2 seconds instead.

Environment variables

pull and dev take the environment's variables as a deployment would (the organization's shared ones, replaced by the Serverless App Service's own) and leave out sensitive values, naming them, except development secrets marked readable by developers, which they include when you have env:write. Changes apply to the next deployment. See Environment variables.

Local development

si dev

Runs the dev script from package.json with the package manager its lockfile names (or the command after --, e.g. si dev -- next dev --turbo), with the Serverless App Service's production variables in its environment (-e picks another environment). Nothing is written to disk. Variables already set in your shell win.

Domains

See Custom domains.

AI clients

si mcp prints the MCP server's address and the configuration for Claude Code and mcpServers files. The MCP key itself is created in ID.

Scripts and CI

• --json prints results as JSON on stdout; progress and messages go to stderr.
• SI_TOKEN makes the command line use an API key (si_api_…, created in ID → organization → Keys, type API) instead of a sign-in. Its scopes decide what works: e.g. projects:read, deployments:write and logs:read to deploy and follow the build, plus git:write to push. Git commands use it as the password too. --org isn't needed: the key belongs to one organization.
• --yes confirms prompts (init, promote, rollback, domains rm); without a terminal they fail unless it's given.
• Exit codes: 0 success, 1 failure (including a failed build), 2 usage errors.

curl -fsSL https://cloud.cactive.com.au/install.sh | SI_NO_MODIFY_PATH=1 sh
SI_TOKEN="$DEPLOY_KEY" ~/.local/bin/si deploy --prod --yes --project my-app

Command reference

Every command, argument and flag is listed in the command reference, generated from the command line's own definitions (the same ones si help and shell completion use). These options work with every command:

Shell completion

si completion bash >> ~/.bashrc
si completion zsh > "${fpath[1]}/_si"
si completion fish > ~/.config/fish/completions/si.fish
si completion powershell >> $PROFILE