CI/CD

PR preview environments

7 min readUpdated April 2026

Every pull request gets its own fully isolated preview environment: a complete copy of your project running in a dedicated Kubernetes namespace with its own databases, seeded from fixture data, and accessible via a unique URL posted directly to the PR.

Preview environments use fixture data, never production data. Reviewers can click through the full application, test new features, and catch bugs before they reach main, with no risk of touching real user data.

Preview lifecycle

PR OpenedGitHub event
Namespaceisolated env
Deployall services
Post URLPR comment
PR ClosedGC namespace

Preview URL format

Format

pr-{number}--{service-name}.preview.stackblaze.cloud

Example (PR #247, service “my-app”)

pr-247--my-app.preview.stackblaze.cloud

GitHub PR comment

SB
stackblaze-botcommented just now

Preview environment deployed for PR #247, feat/rate-limiting

ServiceURLStatus
my-apppr-247--my-app.preview.stackblaze.cloud● Ready
my-apipr-247--my-api.preview.stackblaze.cloud● Ready
my-workerpr-247--my-worker.preview.stackblaze.cloud● Ready

Preview will be deleted automatically when this PR is closed or merged.

Under the hood

  • Isolated Kubernetes Namespace: each PR gets a namespace named preview-pr-{number}-{project-id}. Every service, ConfigMap, Secret, and PVC in your project is replicated into this namespace at the PR's latest commit. Services communicate with each other using in-namespace DNS, completely isolated from your production and staging environments.
  • Database seeding: a Kubernetes Job runs your fixture script (configured under Project → Settings → Preview fixtures) before the services start. This gives reviewers realistic data without any risk of touching production databases. Fixture scripts can be any executable, Node.js, Python, shell, etc.
  • Ingress per PR: StackBlaze creates an Ingress resource for each service in the preview namespace, mapping the pr-N--service.preview.stackblaze.cloud hostname to that service's ClusterIP. TLS certificates are issued automatically via cert-manager and Let's Encrypt using a wildcard DNS record.
  • Garbage collection: on PR close, the entire namespace is deleted with kubectl delete namespace. Kubernetes cascades this deletion to all resources in the namespace including PVCs and PVs, so no storage is left orphaned. DNS records are removed within 60 seconds.

Step by step

01

Auto-enabled when GitHub connected

PR previews are on by default for all web services connected to GitHub. You can disable them per-service under Service → Settings → Preview. There's nothing to install or configure separately.

02

Open a pull request

Push a branch and open a PR against your configured base branch (usually main). StackBlaze receives a pull_request webhook event from GitHub and immediately begins provisioning a preview environment.

03

Wait ~90 seconds for the preview

StackBlaze creates an isolated Kubernetes namespace, deploys all the services in your project into it, seeds any databases from your fixture files, and runs health checks. The whole process takes 60“120 seconds on a warm cluster.

04

Click the URL in the PR comment

StackBlaze posts a comment on your PR with the preview URL and a status badge. The URL format is pr-{number}--{service-name}.preview.stackblaze.cloud. All services in the project get their own URL under the same subdomain pattern.

05

Preview auto-deleted on PR close

When you merge or close the PR, GitHub sends a pull_request closed event. StackBlaze garbage-collects the preview namespace within 60 seconds, deleting all pods, databases, and volumes. Nothing is left running.