Deploy and builds

stackblaze up

Deploys a folder (default: the current directory) to the linked project and environment. If the app does not exist yet, up creates it; if it does, up updates it with the flags you pass and deploys again.

stackblaze up [path] [options]

Git checkout: when the folder has a git remote, the app is built from that remote and the current branch. Unpushed local changes are not deployed, so push first.

Local folder: with no git remote, or with --local, up packs the folder, uploads it and builds it. .gitignore and .stackblazeignore are honoured; .git, node_modules and .env* files are always left out, and a warning names every .env file it skipped. The limit is 200 MB compressed. An unchanged folder is not uploaded twice, and variable changes and redeploys rebuild the last upload for 7 days.

Image: --image runs a container image; git and local files are not used. It takes a full reference, [registry[:port]/]name[:tag][@sha256:…], such as nginx:1.27 or ghcr.io/acme/web@sha256:…. --tag is only needed when --image has no tag; when both give a tag they must match, or up stops with an error. With neither, the tag is latest. Without --port, up reads the image's EXPOSE port; when the image declares none, it deploys a web service on port 3000 and prints a warning. --worker deploys a background process with no port and no public URL.

Re-running up is safe, so CI can run it on every push: git and local-folder apps build again, image apps re-pull (or switch to the new --tag). Settings detected on the first run, such as the Dockerfile port or build strategy, are not rewritten later. An existing app keeps its kind: up --image only updates image apps.

After the deploy starts, up streams the build log live and exits when the build finishes: 0 on success, 1 when the build fails or times out. --detach skips the stream. In a terminal without credentials, up starts stackblaze login first.

Commit pinning: rebuilding an existing git app builds the exact commit being deployed. In CI that is GITHUB_SHA (the pull request's head commit on pull_request events), CI_COMMIT_SHA on GitLab or BUILDKITE_COMMIT; locally it is HEAD when that commit is pushed. On a detached HEAD the branch is read from GITHUB_HEAD_REF, GITHUB_REF_NAME, CI_COMMIT_REF_NAME or BUILDKITE_BRANCH. A brand-new app's first build uses the head of the branch.

With --wait, up then waits up to 10 minutes for the new version to be running and prints progress lines on stderr, so stdout stays clean for --json and --ci.

--ci writes one JSON record per line to stdout (deploy, build, log, status, error); notices and upload progress go to stderr. An image deploy without --wait ends with a status record whose state is submitted. --json without --ci prints one JSON document when up finishes.

Also accepts the scope flags (-p, --project, -e, --env, -a, --app) and the output flags (-o, --output, --json), plus --token, --api-url and --org. Common flags

Examples

stackblaze up                                   # git checkout: build; otherwise upload this folder
stackblaze up ./api --local                     # upload ./api even though it is in git
stackblaze up -y                                # unlinked: create a project named after the directory
stackblaze up -p shop --phase staging --name api --env NODE_ENV=production --wait
stackblaze up --image nginx:1.27                # same as --image nginx --tag 1.27; port from EXPOSE
stackblaze up --image registry.example.com/acme/jobs --worker
stackblaze up --path services/api --name api    # monorepo subdirectory
stackblaze up --ci --wait                       # CI: NDJSON, exit 1 on failure

stackblaze deploy

Without --apply-pending, the same as stackblaze redeploy, and it warns about staged changes it is not shipping. With --apply-pending, applies every change staged with --skip-deploy (on variables and scale) as one release.

stackblaze deploy [--tag <tag>] [-m <text>]
stackblaze deploy --apply-pending [-m <text>]

A --tag deploy is recorded in the deployment history as a deploy of that tag, with your -m message.

Also accepts the scope flags (-p, --project, -e, --env, -a, --app) and the output flags (-o, --output, --json), plus --token, --api-url and --org. Common flags

Examples

stackblaze variables set FOO=1 --skip-deploy
stackblaze scale web=3 --skip-deploy
stackblaze deploy --apply-pending -m "Bump FOO and scale up"
stackblaze deploy --tag 1.4.3 -m "Release 1.4.3"

stackblaze redeploy

Starts a new deployment of the linked app. A git or local-folder app builds again from its configured source; an image app re-pulls its image and tag (useful for moving tags such as latest). Same as stackblaze apps redeploy.

stackblaze redeploy [--tag <tag>] [-m <text>]
stackblaze apps redeploy [name] [--tag <tag>] [-m <text>]

With --tag, the app switches to that image tag, and the deployment history records it as a deploy of that tag with your -m message. Without -m, an image redeploy is listed as "Redeploy".

Also accepts the scope flags (-p, --project, -e, --env, -a, --app) and the output flags (-o, --output, --json), plus --token, --api-url and --org. Common flags

Examples

stackblaze redeploy
stackblaze redeploy && stackblaze builds logs -f
stackblaze redeploy --tag 1.4.3 -m "Release 1.4.3" -a api

stackblaze restart

Restarts the linked app with the same image. Nothing is built or pulled. Same as stackblaze apps restart.

stackblaze restart
stackblaze apps restart [name]

Also accepts the scope flags (-p, --project, -e, --env, -a, --app) and the output flags (-o, --output, --json), plus --token, --api-url and --org. Common flags

Examples

stackblaze restart -a api

stackblaze wait

Polls every 5 seconds until the app and all its add-ons are running, the deploy fails, or the timeout passes (default 10 minutes). Exits 0 when ready and 1 otherwise.

stackblaze wait [--timeout <seconds>]

wait follows builds and rollouts: a build that is queued or running keeps it waiting, and so does a change made in the last 45 seconds until a new instance exists. The app counts as ready only when every instance is updated and ready, no old instance is left and none still runs the previous image. So wait works right after variables set, volume add or redeploy.

Progress lines go to stderr; with --json, stdout carries only the final JSON document. --wait on up, apps create, addons add, templates deploy and deployments rollback waits the same way.

Runs of the app's scheduled tasks are not part of the rollout: finished or running task pods never hold wait up.

Also accepts the scope flags (-p, --project, -e, --env, -a, --app) and the output flags (-o, --output, --json), plus --token, --api-url and --org. Common flags

Examples

stackblaze wait --timeout 300 && curl -fsS "$(stackblaze apps get -o json | jq -r .url)"

stackblaze builds

Alias: build

Build jobs of an app built from source.

stackblaze builds list
stackblaze builds trigger [options]
stackblaze builds logs [build] [-f] [--ci]

list shows the app's builds, newest first. trigger starts a build with the app's settings, optionally overridden. logs follows a build until it finishes (default: the newest build) and exits 1 when the build fails.

With -f, each line is printed as the build writes it, in order: fetch, build, push, deploy. Joining a running or finished build replays the earlier lines first, and a dropped connection reconnects on its own. Set STACKBLAZE_BUILD_STREAM=poll to always poll instead.

Also accepts the scope flags (-p, --project, -e, --env, -a, --app) and the output flags (-o, --output, --json), plus --token, --api-url and --org. Common flags

Examples

stackblaze builds logs -f              # follow the latest build
stackblaze builds logs web-x7k2 -f     # follow a named build
stackblaze builds logs -f --ci         # NDJSON for CI
stackblaze builds trigger --commit-sha "$GITHUB_SHA"
stackblaze builds list -o json

stackblaze deployments

Alias: deployment

list shows the app's deploy history: git builds, image deploys and configuration releases, with status, trigger and ref. rollback returns to an earlier deploy.

stackblaze deployments list [-n <limit>]
stackblaze deployments rollback [deploy-id] [--image-only] [--wait] [--timeout <seconds>] [-y]

<deploy-id> is an ID from deployments list (a history entry or a build name). A past deploy comes back in full: its image and the configuration it ran with, in one release, and auto-deploy turns off so the next push does not bring the change back (turn it on again in the app's settings once the fix is pushed). Add-ons, volumes, domains and the plan stay as they are now. --image-only redeploys just the image tag and keeps today's configuration and auto-deploy. Configuration releases (variable and scale changes) roll back the configuration. Without an ID, rollback picks the newest successful deploy that is not the one running now.

With --wait --json, stdout carries one JSON document: the rollback with the readiness check under wait. The exit code is 1 when the app does not come up.

Also accepts the scope flags (-p, --project, -e, --env, -a, --app) and the output flags (-o, --output, --json), plus --token, --api-url and --org. Common flags

Examples

stackblaze deployments list -n 20
stackblaze deployments rollback -y --wait
stackblaze deployments rollback web-1a2b3c -y

stackblaze inspect

Reports what stackblaze up would detect in the current directory, a local path, or a public git URL: repository type, deployable apps, build context, Dockerfile and port. Runs locally and needs no sign-in; git URLs are shallow-cloned, so git must be installed.

stackblaze inspect [path-or-git-url] [--branch <name>]

Also accepts the output flags (-o, --output, --json), plus --token, --api-url and --org. Common flags

Examples

stackblaze inspect
stackblaze inspect ./services/api
stackblaze inspect https://github.com/acme/shop --branch develop -o json