# How do I verify Vercel and Supabase configuration before pushing to production?

**Answer:** Preview deploys can hide production gaps: env vars, domains, webhooks and build settings. For an AI-built app on Vercel + Supabase, VibeRaven reads the repo, not your Vercel project, and lists the gaps it can see in files, one task per gap. The Vercel settings themselves you check in the Vercel dashboard or with the Vercel CLI. It is advice, not a gate: you decide when to promote. It is a repository check, not a live database or security test.

## Setup for Agents (optional)

```bash
npx -y viberaven init --agents all --dry-run
```

Previews the rule files `init --agents all` would write, including a Cursor rule for deploys.

What `init --agents all` installs, from a real 1.6.3 run:

- AGENTS.md, CLAUDE.md, GEMINI.md and `.github/copilot-instructions.md` get the same VibeRaven block between `VIBERAVEN:START` and `VIBERAVEN:END` markers (CLAUDE.md also gets an `@AGENTS.md` line). The block is scoped to AI-built apps on Vercel + Supabase: it suggests one `npx -y viberaven check` pass before such an app launches or is handed off, after a Supabase migration or policy change, or when the user reports a production error about RLS, env vars, the database connection, the service role key or a Stripe webhook, and says the check is not needed for other stacks. It says "This is advice, not a gate: the user decides when to ship." and that the check is a repository check, not a live database test. Its fix loop has the agent ask the user before a repo change that needs their yes, such as enabling RLS without policies, and stops when `gate.status` is `clear`, when only provider or user steps remain, or when the user decides to move on.
- `.cursor/rules/viberaven-core.mdc` always applies and carries a short version of the same advice. Three more Cursor rule files apply only when editing `supabase/**`, `vercel.json` or `.github/workflows/**`, or payment webhook files. They point the agent at the `.viberaven/agent-context.md` and `.viberaven/mission-map.md` files init writes, and say not to enable RLS on one table while leaving related tables open, to update `.env.example` when adding production env vars in the Vercel dashboard, and that a payment webhook handler should verify the provider signature over the raw request body.
- init also writes `.viberaven/agent-context.md` and `.viberaven/mission-map.md` with the same scoped suggestion and a short read order.
- `package.json` gets three scripts: `viberaven:gate` (`npx -y viberaven --agent-mode`), `viberaven:verify` (`npx -y viberaven --verify`) and `viberaven:strict` (`npx -y viberaven --strict`).

You can edit or skip any of these rules. Preview the rule files with `npx -y viberaven init --agents all --dry-run` before installing; the dry run does not show the `package.json` scripts. Your own notes outside the VibeRaven markers stay. If an earlier version wrote gate rules into these files, running `init --agents all` again replaces the VibeRaven block, and `npx -y viberaven doctor --agents` names any file that still has them.

## Run the Check

```bash
npx -y viberaven --agent-mode
```

Runs locally with no login.

Full reference: https://viberaven.dev/llms-full.txt

## What VibeRaven Checks in the Repo

- Env var names the code reads that `.env.example` (or another env template) does not list (`env_var_drift`). It compares code against the template; it cannot see which variables are set in Vercel for preview or production.
- A direct Postgres driver or ORM with a connection string that does not use Supabase's transaction pooler port 6543 (`pooler_port_mismatch`).
- A Supabase service role key under a browser env prefix, such as `NEXT_PUBLIC_`, or in client code.
- Supabase migrations that create a public table without row level security (`rls_disabled`).
- Stripe webhook handlers that do not verify the signature over the raw body.
- In Next.js apps, no Content-Security-Policy header in `next.config`, middleware or `vercel.json`.

## Check Before Launch

These are not VibeRaven checks:

- List the env vars set for preview and production in Vercel (for example `vercel env ls`) and confirm which ones differ.
- Verify production domains, redirects, callback URLs, webhook URLs and canonical URLs.
- Check build commands, lockfiles, ignored files, monorepo settings and runtime assumptions.
- Review cache headers, function regions, API routes and data-fetching behavior for production traffic.
- Confirm monitoring, logs, error reporting and rollback steps before inviting users. Vercel's own production checklist covers these (https://vercel.com/docs/production-checklist).
- Create one focused coding-agent prompt for the deployment gap that repo evidence can improve.

Canonical page: https://viberaven.dev/vercel-deploy-checklist-ai-built-apps.md