CI/CD

Automatic deploy on push

6 min readUpdated April 2026

Every StackBlaze web service and worker connected to GitHub deploys automatically on every push to the configured branch. The pipeline, from git push to live traffic, typically completes in 60 to 180 seconds depending on your build time.

You can skip a deploy by adding [skip ci] to your commit message. You can also restrict which file paths trigger a deploy, useful for monorepos where docs changes shouldn't rebuild your API server.

Deploy pipeline

git pushcommit
GitHubwebhook fired
WebhookPOST /deploy
BuildDocker image
Registryimage pushed
Rollingdeploy
Live✓ healthy

Build log

Build #47, my-api, commit a3f9c12

00:00 Cloning github.com/acmecorp/my-api (branch: main)

00:01 Checked out commit a3f9c12, "feat: add rate limiting middleware"

00:02 Detected Node.js 22 (package.json engines)

00:02 Installing dependencies with npm ci...

00:18 Dependencies installed (638 packages in 16.4s)

00:18 Building production image...

00:39 Layer cache hit: base image (saved 14s)

00:41 Image built: sha256:d4e8f1a2b3c9... (182 MB)

00:42 Pushing to internal registry...

00:48 Image pushed successfully

00:49 Rolling update starting (3 replicas)...

01:02 replica-1: updated, readiness probe passed

01:09 replica-2: updated, readiness probe passed

01:16 replica-3: updated, readiness probe passed

01:17 Health check passed, GET / 200 (12ms)

01:17 Deploy complete. Live: https://my-api.stackblaze.app

Deploy settings

Auto-deploy

Trigger a deploy on every push to the branch below

Trigger branch

Deploy when commits are pushed to this branch

main

Ignored paths

Pushes that only change these paths will not trigger a deploy

docs/**×README.md×*.test.ts×.github/**×

Under the hood

  • GitHub webhook: StackBlaze registers a push event webhook on your repository using a per-project HMAC-SHA256 secret. Incoming payloads are verified against this secret before any build is triggered, preventing spoofed deploys.
  • Kubernetes Job for the build: each build runs as an isolated Kubernetes Job in a dedicated build namespace. The Job clones your repo, runs your build command in a rootless Kaniko container, and pushes the image to the internal OCI registry. Build logs are streamed via the StackBlaze API.
  • Rolling update strategy: deployment uses Kubernetes' default rolling update: maxSurge: 1, maxUnavailable: 0. This means a new pod is started and passes its readiness probe before an old pod is removed, keeping capacity at 100% throughout.
  • Layer caching: Docker layer cache is persisted between builds on a per-service volume. If your base image and dependencies haven't changed, those layers are reused, shaving 30“60s off typical build times.

Step by step

01

Connect GitHub (auto-enabled)

When you create a web service or worker from a GitHub repository, StackBlaze automatically installs a webhook on the repo. No manual setup is required. You can verify this under GitHub → Settings → Webhooks, you'll see a stackblaze.com entry.

02

Configure the trigger branch

Go to Service → Settings → Deploy. The default trigger branch is "main" (falling back to "master"). You can change this to any branch name, or enter a glob pattern like "release/*" to trigger on all release branches.

03

Push a commit

Push any commit to the configured branch. To skip a deploy, include [skip ci] or [no deploy] anywhere in your commit message. StackBlaze sees the webhook payload, checks the commit message, and skips the build if either marker is present.

04

Watch the build logs

Open Service → Deployments to see the in-progress build. Logs stream in real-time, you'll see clone, install, build, and push phases followed by the rolling update. Click any line to copy it to your clipboard.

05

Service goes live

Once the rolling update completes and health checks pass, the new version receives 100% of traffic. The previous deployment is kept for 24 hours in case you need to roll back.