Preview Deployments

An isolated Rivet namespace for every pull request.

A preview deployment gives each pull request its own Rivet namespace, so branch work never touches production state. The namespace is created when the PR opens and destroyed when it closes.

Which setup you use depends on where your workers run.

With Rivet Compute

setup-ci writes a workflow that already does this:

npx @rivetkit/cli setup-ci
gh secret set RIVET_CLOUD_TOKEN

The generated .github/workflows/rivet-deploy.yml deploys production on push to your default branch, creates a namespace per pull request, posts the preview link as a comment, and cleans the namespace up on close. See Rivet Compute.

With Vercel

Use the preview-namespace-action. It creates the namespace and writes RIVET_ENDPOINT and RIVET_PUBLIC_ENDPOINT into the Vercel preview environment, so the deployment picks them up with no manual configuration.

name: Rivet Preview

on:
  pull_request:
    types: [opened, synchronize, reopened]
  push:
    branches: [main]

concurrency:
  group: rivet-preview-${{ github.event.pull_request.number || github.ref }}
  cancel-in-progress: true

jobs:
  rivet-preview:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
    steps:
      - uses: rivet-dev/preview-namespace-action@v1
        with:
          platform: vercel
          rivet-token: ${{ secrets.RIVET_CLOUD_TOKEN }}
          vercel-token: ${{ secrets.VERCEL_TOKEN }}

The action also configures the Vercel Deployment Protection bypass header, which is otherwise a common source of 401s from Rivet into preview deployments. See Vercel.

On other platforms

Any platform works, as long as the pull-request build gets endpoint values for a fresh namespace instead of production’s. Create the namespace with the Cloud API using a cloud_api_* token, inject the resulting endpoints as build-time environment variables, and delete the namespace when the pull request closes.

Next steps

• Rivet Compute
• Tokens