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, .stackblazeignore and .railwayignore 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. 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.

--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, --pipeline, --phase, -a, --app) and the output flags (-o, --output, --json), plus --token and --api-url. 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 --tag 1.27          # port read from the image's 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 flags, 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 as one release.

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

Also accepts the scope flags (-p, --pipeline, --phase, -a, --app) and the output flags (-o, --output, --json), plus --token and --api-url. 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

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>]

Also accepts the scope flags (-p, --pipeline, --phase, -a, --app) and the output flags (-o, --output, --json), plus --token and --api-url. Common flags

Examples

stackblaze redeploy
stackblaze redeploy && stackblaze builds logs -f
stackblaze redeploy --tag 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

Also accepts the scope flags (-p, --pipeline, --phase, -a, --app) and the output flags (-o, --output, --json), plus --token and --api-url. 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. Exits 0 when ready and 1 otherwise.

stackblaze wait [--timeout <seconds>]

Also accepts the scope flags (-p, --pipeline, --phase, -a, --app) and the output flags (-o, --output, --json), plus --token and --api-url. 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, --pipeline, --phase, -a, --app) and the output flags (-o, --output, --json), plus --token and --api-url. 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] [--wait] [-y]

<deploy-id> is an ID from deployments list (a history entry or a build name). Image deploys and builds roll back to their image tag, which works for image apps too; 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, --pipeline, --phase, -a, --app) and the output flags (-o, --output, --json), plus --token and --api-url. 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 and --api-url. Common flags

Examples

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