Sitery CLI

Beta

Deploy a Next.js site from your terminal or CI with one command.

In beta, and not open to everyone yet

The CLI deploys Next.js sites, which are only turned on for some workspaces during the beta. Anyone can install it, but logging in needs a workspace with Next.js enabled. Get in touch if you'd like access. Commands and options may still change.

Install

You need Node 20 or newer.

npm install -g @sitery/cli

Or run it without installing: npx @sitery/cli deploy, pnpm dlx @sitery/cli deploy or yarn dlx @sitery/cli deploy. To pin a version per project, add it as a dev dependency (npm install -D @sitery/cli).

Log in

Run this once in your project folder:

sitery login

Your browser opens the Sitery dashboard and your terminal shows a short code. Check that the two codes match, pick the workspace and Next.js site, and approve. The terminal finishes on its own. Working over SSH? Open the link it prints on any device.

Approving creates a deploy key for that one site. The key is generated on your machine and never sent to us in readable form, and it's stored in ~/.config/sitery/credentials.json, readable only by you. It appears on the site's API Keys tab marked "CLI", where you can revoke it.

Login also writes .sitery/project.json to link the folder to the site. It contains no secrets, so commit it; teammates then run sitery login themselves and deploy to the same site.

You need to be an owner, admin or Deployer in the workspace. If you leave the workspace or your role drops to member, your CLI keys stop working.

Deploy

sitery deploy --build

This runs your build script with whichever package manager the project uses, copies .next/static and public into the standalone output, uploads it, and waits until the release is live. Your current release keeps serving the whole time. If the new one fails its health check, the command prints why and exits with an error.

Leave off --build if you've already built. Your next.config needs output: 'standalone'; see the Next.js guide for the details.

--env-file <path> includes that file in the release as .env.production.
--dir <path> deploys a project in another folder.
--no-wait returns as soon as the upload is queued.
--timeout <minutes> changes how long it waits (default 20).

Commands

`sitery login`	Approve this machine in the dashboard and link the project to a site
`sitery deploy --build`	Build, upload and deploy, then wait until the release is live
`sitery deployments`	List recent deployments for the site
`sitery status <id>`	Show one deployment, including the error if it failed
`sitery redeploy`	Rebuild the live release, e.g. after changing the Node version
`sitery logs -f`	Show the app’s output and keep following it
`sitery open`	Open the site in the dashboard
`sitery cache purge`	Clear the site’s CDN cache
`sitery whoami`	Show which site and key commands in this folder use
`sitery logout`	Forget the key stored for this project

Run sitery --help for every option.

Deploying from CI

CI can't open a browser, so give it a key instead. On your site's API Keys tab, create a key with "Deploy releases" and store it as a secret named SITERY_API_KEY. When that variable is set, the CLI uses it and skips stored keys. A GitHub Actions job looks like this:

- uses: actions/setup-node@v4
  with:
    node-version: 22
- run: npm ci
- run: npx @sitery/cli@0.2 deploy --build
  env:
    SITERY_API_KEY: ${{ secrets.SITERY_API_KEY }}

Pinning a version (@0.2 above) keeps CI from changing under you. Exit codes: 0 live, 1 failed, 2 still running when the timeout ran out.

Updating

npm install -g @sitery/cli@latest

When you run the CLI in a terminal, it checks for a new version at most once a day and prints a one-line note when there is one. It never checks in CI. Turn it off with SITERY_NO_UPDATE_CHECK=1. If we ever stop supporting an old version, it will tell you to upgrade instead of failing partway through a deploy.

Need help? Contact our support team.