Announcing PR preview environments

Starting today, every pull request on a StackBlaze project automatically gets its own live preview environment. Open a PR, push a commit, within about ninety seconds you'll have a unique URL you can share with your team, your designer, or your customer.

We've been running this in private beta with about forty teams for the past six weeks. The feedback was unambiguous: it changes how code review works. Instead of pulling someone else's branch locally and running it yourself, you click a link.

What are PR previews

A PR preview environment is an ephemeral copy of your application, deployed from the head commit of a pull request branch. It is fully isolated: its own namespace, its own database (seeded from a snapshot of your staging data), its own environment variables scoped to the preview tier. It lives for as long as the PR is open, and it is destroyed automatically when the PR is merged or closed.

PR previews are not a new idea, Vercel has had them for frontend deployments for years. What's new is that we do it for your entire stack. Your API server, your background workers, your database, your Redis instance, all of it spins up together in the preview environment, connected to each other over a private network exactly the way they are in production.

How it works

When you open a pull request, our GitHub App receives a pull_request event. We clone your blueprint.yaml, substitute the branch name and PR number as environment variables, and provision a new environment in an isolated Kubernetes namespace. The namespace name is deterministic from the PR number, so the URL is stable across commits to the same PR.

Database state is seeded from a point-in-time snapshot of your staging environment's database, taken at the moment the preview is created. This means your preview has realistic data without you having to write fixture scripts. The snapshot is read-only-cloned using copy-on-write at the storage layer, so the first preview environment spins up in under 30 seconds even with a large database.

How to enable it

PR previews are opt-in per project. Add a previews block to your blueprint.yaml:

name: my-app
services:
  web:
    build: .
    port: 3000
  db:
    type: postgres
    version: "16"

previews:
  enabled: true
  seed_from: staging       # snapshot source environment
  auto_destroy: true       # destroy when PR closes (default)
  ttl_hours: 72            # max lifetime even if PR stays open

That's it. Push the change to your main branch and every future PR will get a preview. The GitHub status check will include a direct link to the preview URL.

Limitations and roadmap

A few things we know are missing and are actively working on:

• Custom domains for preview URLs, right now they use a generated subdomain under .preview.stackblaze.app
• GitLab and Bitbucket support, today it is GitHub only
• Selective service previewing, some teams only want to preview the frontend, not reprovision the full stack
• Persistent preview overrides, the ability to run migrations on a preview without re-seeding from staging

If any of those are blocking you, open a ticket in your project's support channel and we'll prioritize accordingly. We ship based on what teams are actually blocked on.