Deploy from GitHub

From + Service → Git repository, connect GitHub and pick a repo. Pushes to the connected branch auto-deploy. Pull requests can get their own environment.

GitHub OAuth flow

The first time you add a Git service, StackBlaze sends you to GitHub to authorize access. You can grant all repositories or only the ones you select.

StackBlaze requests the minimum required scope:

Scope	Why it is needed
`repo`	Read repository contents to clone and build your code
`admin:repo_hook`	Install the webhook that triggers auto-deploys on push

StackBlaze never stores your repository code. It clones each commit into an ephemeral build container, builds the image, and then discards the source. Only the built Docker image is retained.

Repository permissions

You can limit which repositories StackBlaze can access. During the OAuth flow, choose “Only select repositories” to grant access to specific repos. You can add more repositories later in:

GitHub → Settings → Applications → StackBlaze → Repository access → Add repository

Branch selection

When you add the service, pick the branch. StackBlaze deploys the latest commit on that branch. Production usually tracks main.

Change it later in the service sheet → Settings → Deploy → Branch. Changing the branch deploys HEAD of the new branch.

Auto-deploy on push

When you push a commit to the configured branch, GitHub fires a webhook to StackBlaze. StackBlaze picks up the webhook payload, checks the commit message for skip markers, and queues a build if the push should trigger a deploy.

Skipping a deploy

Add any of the following to your commit message to skip the auto-deploy:

Marker	Example commit message
`[skip ci]`	Update README [skip ci]
`[no deploy]`	Fix typo in docs [no deploy]
`[skip deploy]`	Minor cleanup [skip deploy]

Build filters for monorepos

In a monorepo, you usually only want to redeploy a service when files in its subdirectory change. Configure build filters in Service Settings → Deploy → Build Filters.

Specify glob patterns (one per line). A deploy is triggered only if at least one changed file matches at least one pattern. If no changed file matches, the deploy is skipped.

# Only trigger when files in the api package change
packages/api/**

# Also trigger when shared packages change
packages/shared/**
packages/types/**

Pull-request environments

When review apps are on, opening a pull request against the deploy branch provisions a preview environment — a copy of the canvas with its own URL. It updates on every push to the PR branch.

Preview URLs follow the pattern:

https://pr-123-my-service.stackblaze.app

StackBlaze posts a comment on the PR with the preview URL. Preview environments are automatically deleted when the PR is merged or closed.

Draft PRs

By default, StackBlaze does not create preview environments for draft PRs. Enable draft PR previews in Project Settings → GitHub → Deploy draft PRs.

Deploy notifications

StackBlaze posts deployment status updates to GitHub. You’ll see a check on each commit showing whether the deploy succeeded, failed, or is in progress. This integrates with GitHub required status checks — you can block merges until the deploy check passes.

GitHub commit status

Status	Meaning
pending	Build is queued or in progress
success	Deploy completed, health check passed
failure	Build or deploy failed
error	Internal error (rare, contact support)

Adding more repositories

Navigate to Project Settings → Integrations → GitHub → Manage repositories.

Revoking access

To revoke StackBlaze’s access to a repository, go to:

GitHub → Settings → Applications → StackBlaze → Repository access → Remove repository

This does not delete the service from StackBlaze — it will just stop receiving auto-deploys. You can still trigger manual deploys from the dashboard or the API.

See Auto Deploy on Push for the full CI/CD pipeline documentation, including build caching, skip markers, and parallel builds. For triggering deploys from outside GitHub (e.g., from CI systems like Jenkins or CircleCI), see Deploy Hooks.