Prompt of the Day: Configure Preview Deployments on Vercel
Part 23 of 30 -- Prompt of the Day
Every time a developer opens a pull request, something predictable should happen: a live, isolated copy of the application spins up at a unique URL, wired to non-production services, and a bot drops the link directly into the PR thread. That is what Vercel preview deployments give you. According to the Vercel documentation, preview deployments sit in their own environment with their own scoped environment variables, completely separated from production traffic. Teams that adopt this workflow -- and discussions across the Vercel community confirm this -- catch layout regressions, auth redirect failures, and integration bugs before they ever touch main.
The Prompt
Copy this into Cursor, Claude, Copilot, or whichever AI coding tool you use:
I have a Next.js project connected to a Vercel project via the GitHub integration.
Configure preview deployments end-to-end with the following requirements:
1. ENVIRONMENT VARIABLES FOR PREVIEW
- Add a .env.preview.example file documenting all preview-specific variables.
- Use Stripe TEST keys (STRIPE_SECRET_KEY, NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY)
for the Preview environment, never the live keys.
- Point NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_ANON_KEY at my
staging Supabase project (not production).
- Show me the exact steps to set these in the Vercel dashboard under
Settings > Environment Variables, scoped to "Preview" only.
2. BRANCH-BASED PREVIEW RULES
- Every pull request branch should automatically generate a unique preview URL.
- Confirm the vercel.json or project settings needed so that all non-main
branches trigger a preview deployment (not a production deployment).
- Provide a vercel.json snippet if any explicit branch ignore rules are needed.
3. GITHUB PR COMMENT BOT
- Set up a GitHub Actions workflow (.github/workflows/vercel-preview.yml) that:
a. Triggers on pull_request events (opened, synchronize, reopened).
b. Runs `vercel pull --environment=preview` and `vercel build --token`.
c. Captures the deployed preview URL from `vercel deploy --prebuilt`.
d. Posts or updates a single PR comment with the preview URL using
actions/github-script, so the comment is updated (not duplicated) on
each push.
- Required secrets: VERCEL_TOKEN, VERCEL_ORG_ID, VERCEL_PROJECT_ID.
4. CORS AND AUTH REDIRECT CONFIGURATION
- My app uses Supabase Auth. The OAuth redirect URLs must include the dynamic
Vercel preview URL pattern: https://*-<my-team>.vercel.app/**
- Show where to add this wildcard redirect URL in Supabase Auth settings.
- If my app also sets allowed CORS origins server-side (Next.js API routes or
middleware), add logic to allow any *.vercel.app origin when
VERCEL_ENV === 'preview'.
Provide all file contents in full, not as diffs. Flag any step that requires a
dashboard action I must do manually versus code I can commit.
Why It Works
This prompt succeeds because it does three things that vague prompts never do: it scopes, it specifies, and it separates concerns.
Scoping means telling the model exactly which Vercel environment matters. "Preview only" is doing real work here -- it prevents the model from accidentally suggesting you set Stripe live keys in a preview scope or merge preview and production Supabase configs.
Specificity means naming the actual secrets, the actual Vercel CLI commands (vercel pull, vercel build, vercel deploy --prebuilt), and the actual GitHub Actions events. The model cannot guess the correct command sequence if you just ask it to "set up CI." The prompt pins the exact CLI surface so there is no ambiguity.
Separating concerns means each numbered section has one job. CORS and auth redirects are a distinct problem from GitHub bot comments. Keeping them in separate numbered sections causes the model to produce separate, reasoned answers rather than conflating them into one muddled block of YAML.
The closing instruction -- "provide all file contents in full, not as diffs" -- is load-bearing. Without it, many AI tools produce partial file snippets that are easy to misapply.
The Anti-Prompt
Here is what most people actually type:
set up vercel preview deployments for my nextjs app
This fails for several compounding reasons. The model does not know whether you have Stripe, Supabase, or any external service at all, so it produces a generic tutorial that matches Vercel's own documentation but tells you nothing specific to your stack. It has no idea you need to isolate test keys from live keys. It will not touch CORS because you never mentioned auth. It will not write a GitHub Actions workflow because you implied Vercel's native GitHub integration was sufficient. And because there are no constraints on output format, you will get a mixture of prose, partial YAML, and dashboard screenshots descriptions -- none of it directly committable. The result is a 400-word explanation of what preview deployments are, which you already knew, rather than the configuration you actually need.
Variations
Variation 1: Next.js + Supabase with Row Level Security testing
Append this to the base prompt:
In addition, my preview Supabase project has Row Level Security enabled with
different seed data than production. Add a Supabase migration check step to the
GitHub Actions workflow that runs `supabase db push --linked` against the staging
project after the preview deploys, using SUPABASE_ACCESS_TOKEN and
SUPABASE_PROJECT_REF secrets scoped to preview.
Variation 2: Monorepo with multiple Vercel projects
Replace the intro of the base prompt with:
I have a monorepo containing two Next.js apps: /apps/web and /apps/dashboard.
Each is a separate Vercel project. Configure preview deployments for both so
that a single PR triggers two preview URLs and the GitHub bot comment lists
both. Use the Vercel GitHub integration's monorepo support and vercel.json
rootDirectory settings for each project.
Variation 3: Team with required reviewer approval before preview is public
Append this to the base prompt:
Preview deployments should be protected by Vercel Authentication so only team
members can access them. Show me where to enable Deployment Protection in
Vercel project settings, and also generate the VERCEL_AUTOMATION_BYPASS_SECRET
for our internal Playwright regression suite so automated tests can still reach
the preview URL.
When You Would Actually Use This
You reach for this prompt the first time you onboard a new project to Vercel -- before any feature work starts. You also use it whenever a new external service enters the stack (say, you add a payment processor mid-project and now you need a second set of test keys scoped away from production). Teams with dedicated QA reviewers or stakeholders who need to click through changes before merge find the PR comment bot variation essential: the link is right there in the PR thread, updated on every push, with no manual deploy step.
Ask The Guild
How are you handling preview environment secrets for services that do not support wildcard OAuth redirect URLs? Some auth providers require you to register every exact redirect URL, which breaks the dynamic Vercel preview URL pattern. Share your workaround below -- or show us the prompt you used to solve it.