ci.md

CI / non-interactive deploys

smb is interactive by default — it prompts for confirmations, project setup, credentials, and so on. In CI that's a problem: there's no TTY to answer a prompt, so the command would hang or fail with a cryptic terminal error.

Pass the global --ci flag (or set SMB_CI=1, or run under any provider that sets the conventional CI env var) to put smb in non-interactive mode:

• Confirmations resolve to their default instead of asking (e.g. smb --ci logout proceeds without a y/n prompt).
• Any command that genuinely needs interactive input — login, init, signup, account forgot-password, project new/update/delete, and picking a monorepo target — fails fast with a clear, actionable message instead of blocking.

smb --ci deploy            # flag
SMB_CI=1 smb deploy        # env var
CI=true smb deploy         # most CI providers set this automatically

Authenticate ahead of time

Logging in is interactive, so it can't run under --ci. Provision the token once and make it available to the CI job at ~/.smb/token (production) or ~/.smb-dev/token (dev). Typically you store the token contents in a CI secret and write the file at the start of the job:

- run: |
    mkdir -p ~/.smb
    printf '%s' "${{ secrets.SMB_TOKEN }}" > ~/.smb/token
    chmod 600 ~/.smb/token

Static sites: HTTPS, no SSH key

Apps the server publishes as artifacts (publish_target = artifact; plain static, vite-spa and sveltekit) deploy over HTTPS with an app-scoped deploy token and nothing else. Mint the token once with a user session, store it as a CI secret, and export it as SMB_TOKEN:

- run: smb deploy --prebuilt --ci
  env:
    SMB_TOKEN: ${{ secrets.SMB_DEPLOY_TOKEN }}

There is no smb login, no ~/.ssh key and no known_hosts. The CLI hashes the output directory, uploads only the files the server does not already have, and waits until the deployment is live. A deploy token can deploy its own app and cannot read other apps, change app settings or create tokens. Revoke it to cut off access.

• --prebuilt skips the build and ships the existing output (output for vite-spa and sveltekit, the current directory for plain static).
• --dry-run prints the app, the file list and the total size, then stops before uploading.
• --dry-run and --prebuilt apply only to apps published over HTTPS. On an app that deploys over SSH they exit 1 before any build, rsync or ssh. If the deploy config cannot be read, the command fails; it never falls back to SSH.
• SMB_TOKEN set to an empty string is an error under --ci; unset it to use the login token.
• .gitignore and .smbignore inside the shipped directory are honoured. .git and .smb are never uploaded, and symlinks are refused.

Limits per deployment: 20,000 files, 50 MB per file, 500 MB in total, and 10 deployments per hour per app.

Every other kind still rsyncs over SSH using ~/.ssh/id_<user-id>@smbcloud; install that key the same way if your project deploys to a server tier. That path prints a deprecation note.

Deploying from GitHub Actions

The smbcloudXYZ/smbcloud-deploy-action composite action wraps the steps above: it installs the CLI, writes the token to the right state dir, optionally installs the SSH key, then runs smb --ci deploy.

- uses: smbcloudXYZ/smbcloud-deploy-action@v1
  with:
    token: ${{ secrets.SMB_TOKEN }}

For a monorepo, name the sub-project and pass the SSH inputs that rsync deploys need:

- uses: smbcloudXYZ/smbcloud-deploy-action@v1
  with:
    token: ${{ secrets.SMB_TOKEN }}
    project: docs
    ssh-private-key: ${{ secrets.SMB_SSH_PRIVATE_KEY }}
    ssh-key-name: ${{ secrets.SMB_SSH_KEY_NAME }}
    ssh-known-hosts: ${{ secrets.SMB_SSH_KNOWN_HOSTS }}

The action installs the latest published CLI release, so --ci must exist in that release. Pin the version input if you need a specific CLI version. See the action's README for the full input reference.

Example: the AircraftsHub monorepo

AircraftsHub is a Tauri app whose Next.js web app lives in the same repo (web/) as a pnpm workspace. Only the web app deploys to smbCloud; the desktop/mobile app ships to the app stores. Its .smb/config.toml:

name = "aircraftshubweb"

[project]
id = 61
kind = "nextjs-ssr"
source = "web"                    # local Next.js app directory (workspace member)
path = "apps/web/aircraftshubweb" # remote runtime directory on the server
package_manager = "pnpm"
pm2_app = "aircraftshub-web"
port = 3022

Because the config pins the project, the source, and the runtime, deploying needs no interaction at all:

smb --ci deploy
# ✔ Build complete.
# App is running ✔
# ✔ Deployment complete.

For a monorepo config with several [[projects]] entries, name the target — --ci mode won't prompt you to choose:

smb --ci deploy --project aircraftshubweb

Behind a proxy

smb honours HTTPS_PROXY and NO_PROXY (and the lowercase forms). A deploy over HTTPS contacts api.smbcloud.xyz on port 443 and nothing else, so an egress allowlist with that one host is enough. That holds for the HTTPS path only; the SSH paths connect to the server tier directly. The host needs ca-certificates to verify the TLS connection, and the Linux release binary needs glibc 2.35 or newer and zlib1g. If the host cannot be reached, the command exits with a network error; run with RUST_LOG=debug to see whether the connection, a timeout, or the proxy failed.

Behavior reference

Command	--ci behavior
deploy (config pins project)	Runs fully non-interactively
deploy (monorepo, no --project)	Fails: pass --project <name>
deploy (not authenticated)	Fails: provision the token first
logout	Proceeds (confirmation defaults to yes)
login, init, signup, account forgot-password	Fails fast — interactive only
project new, project update, project delete	Fails fast — interactive only
me, migrate, project list/show, mail	Unaffected (no prompts)