Getting started

Command line

Deploy, follow builds and logs, and manage environment variables and domains from your terminal with `si`.

si creates projects, 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

Terminal

curl -fsSL https://cloud.dev.gov.vin/install.sh | sh

Installs ~/.local/bin/si after checking its SHA-256, and adds that directory to PATH in your shell's profile if it isn't on it yet. SI_INSTALL_DIR picks another directory; SI_NO_MODIFY_PATH=1 leaves profiles alone. Apple silicon, Intel, Linux x64 and arm64 are supported.

PowerShell

irm https://cloud.dev.gov.vin/install.ps1 | iex

Installs %LOCALAPPDATA%\si\bin\si.exe and adds that directory to your user PATH. Windows on x64 is supported.

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.

si login

The browser opens https://id.dev.gov.vin/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.

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.

Command
`si whoami`	Who you're signed in as, and the current organization.
`si orgs`	Your organizations and roles.
`si switch <org>`	The organization commands use when the folder isn't linked. `--org <slug>` overrides it for one command.
`si logout`	Revokes this machine's git keys and removes the session.

Signed-in machines are listed on your account page at https://id.dev.gov.vin under Command line. Sign out ends that machine's session (its current access token stops within 15 minutes) and revokes its git keys.

Git credentials

si git setup

Makes si git's credential helper for https://git.dev.gov.vin only:

~/.gitconfig

[credential "https://git.dev.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 project

cd my-app
si init

Creates a repository and a project 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.

Command
`si link [project]`	Links the folder to an existing project (asks which one when omitted) and adds a remote for its repository.
`si clone <project> [dir]`	Clones the project's repository and links it.
`si unlink`	Removes the link.
`si open`	Opens the production URL (`--cloud`: the project in Cloud).

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

Deploy

si deploy

In a clean checkout of the project'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 project 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.

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.

Command
`si deployments`	The project's deployments (`--target`, `--branch`, `--limit`). `*` marks production.
`si promote <deployment>`	Makes a ready deployment production without rebuilding.
`si rollback [deployment]`	Points production back at an earlier deployment; without one, the production deployment before the current one.
`si redeploy <deployment>`	Builds the deployment's commit (or upload) 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.

Environment variables

Command
`si env ls [-e <environment>]`	Variables, their environments and readable values.
`si env add <KEY> [value] [-e production -e preview] [--plain]`	Adds or replaces a variable for the environments given (default all three). Without a value it's read from stdin. Variables are sensitive unless `--plain`.
`si env rm <KEY>`	Removes a variable.
`si env pull [file] [-e development]`	Writes the environment's variables to `.env.local` (mode 600).
`si env push [file] [-e …] [--plain]`	Adds every variable in a `.env` file.

Sensitive values can't be read back by anyone, so pull and dev leave them out and name them. 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 project's production variables in its environment (-e picks another environment). Nothing is written to disk. Variables already set in your shell win.

Domains

Command
`si domains ls`	The project's domains, their status and the DNS records still needed.
`si domains add <hostname>`	Adds a domain and prints the records to create.
`si domains verify <hostname>`	Checks DNS and the certificate.
`si domains cloudflare <hostname>`	Creates the records with the organization's Cloudflare connection.
`si domains rm <hostname>`	Removes a domain.

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.dev.gov.vin/install.sh | SI_NO_MODIFY_PATH=1 sh
SI_TOKEN="$DEPLOY_KEY" ~/.local/bin/si deploy --prod --yes --project my-app

Shell completion

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

Command line

On this page