Vercel Deployment
Pathrule2 Rules • 3 Memories • 1 Skill
An opinionated bundle for teams deploying Next.js and other apps on Vercel in 2026. It codifies the preview-then-promote workflow, per-environment secrets with OIDC and Sensitive variables, Fluid Compute function config, and CDN-aware caching so deploys stay fast, safe, and reversible.
Suggested path map
Pathrule places each piece on the matching path, so your assistant only sees it where it belongs. This is the scoping you get on import; you can adjust it in your workspace.
/ workspace root
Preview first, then promote to production
Scope secrets to the server and the right environment
vercel.json and project-level configuration conventions
Function runtime config with Fluid Compute
vercel-deploy-review
app/
Caching and ISR on the Vercel CDN
Rules
2Preview first, then promote to production/roothighstrictNever push directly to the production branch; validate a preview deployment and promote it.
| 1 | Production traffic only ever serves a deployment that was first validated as a preview. |
| 2 | |
| 3 | - Land changes on a non-production branch or PR so Vercel builds a preview, and run health checks against that preview URL before promoting. |
| 4 | - Promote the exact preview build with `vercel promote <url>` or the dashboard Promote action instead of re-merging, so the bytes serving production are the bytes you tested. |
| 5 | - Keep instant rollback usable: a known-good earlier production deployment must always exist, since rollback just reassigns the domain rather than rebuilding. |
| 6 | - Treat the production branch (usually `main`) as protected; do not force-push or rebase history that has been deployed. |
Scope secrets to the server and the right environment/roothighstrictOnly NEXT_PUBLIC_ vars reach the client; mark real secrets Sensitive and prefer OIDC.
| 1 | Environment variables are scoped per environment and never leak server secrets to the browser. |
| 2 | |
| 3 | - Only prefix a variable with `NEXT_PUBLIC_` when it is safe in client JS; everything else (API keys, DB URLs, tokens) stays server-only. |
| 4 | - Set distinct values per environment (Production, Preview, Development) rather than reusing production credentials in previews. |
| 5 | - Mark credentials as Sensitive so Vercel redacts them in logs and the UI, and never commit `.env*` files; pull with `vercel env pull` for local dev. |
| 6 | - For backend access (AWS, GCP, Azure, databases), prefer OIDC Federation via `VERCEL_OIDC_TOKEN` (TTL ~60 min, cached ~45 min) to get short-lived tokens instead of long-lived static secrets. |
Memories
3vercel.json and project-level configuration conventions/rootWhat belongs in vercel.json vs the dashboard, and what to avoid.
| 1 | vercel.json is the file-based configuration layer that version-controls routing, headers, and per-function overrides. Know what it can and cannot do. |
| 2 | |
| 3 | - Use `vercel.json` for: `rewrites`, `redirects`, `headers`, `cleanUrls`, `trailingSlash`, per-function `maxDuration` and `runtime` overrides, and `crons`. |
| 4 | - Do NOT put environment variable values in `vercel.json`; they belong in the Vercel dashboard or `vercel env add`. The file is committed to the repo and world-readable. |
| 5 | - Memory cannot be set in `vercel.json` when Fluid Compute is enabled; configure it in the project dashboard under Functions. Fluid Compute is on by default for new projects, raising the Pro `maxDuration` ceiling to 800 s. |
| 6 | - Avoid setting `version: 2` explicitly; it is the default and the only supported schema. An old `version: 1` in the file disables modern routing features. |
| 7 | - Framework-detected projects (Next.js) apply their own output directory and command defaults; overriding `outputDirectory` or `buildCommand` in `vercel.json` for a Next.js app usually breaks the build unless you know exactly why. |
Function runtime config with Fluid Compute/rootHow maxDuration, runtime, and memory work on Vercel Functions in 2026.
| 1 | Fluid Compute is the default execution model for new Vercel projects as of 2025, and it changes how function limits behave. |
| 2 | |
| 3 | - Set `maxDuration` per function in `vercel.json` (or via route segment config in Next.js); with Fluid Compute the Pro max rises to 800s, versus 300s without it. |
| 4 | - Memory can no longer be set in `vercel.json` when Fluid Compute is on; configure it under Functions in the project dashboard. |
| 5 | - Choose the runtime deliberately: Edge for low-latency middleware and lightweight routes, Node.js for heavier or dependency-rich work. |
| 6 | - Use Cron Jobs for scheduled invocations rather than external pingers, and keep cold-start-sensitive paths lean. |
Caching and ISR on the Vercel CDN/appHow revalidation, cacheTag/cacheLife, and CDN purges fit together.
| 1 | Next.js sets `Cache-Control` from the rendering strategy, and Vercel's CDN serves those responses; on-demand invalidation must reach both layers. |
| 2 | |
| 3 | - Static pages emit `s-maxage=31536000`; ISR pages emit `s-maxage={revalidate}` with `stale-while-revalidate` so users get fast pages that refresh in the background. |
| 4 | - With Cache Components (`use cache`), set lifetime via `cacheLife` and label entries with `cacheTag` for targeted invalidation. |
| 5 | - Invalidate on mutation with `revalidateTag` / `revalidatePath` (or `updateTag`); these clear the Next.js cache and Vercel propagates the CDN purge for those keys. |
| 6 | - Avoid `revalidate = 0` or fully dynamic rendering on hot pages unless the data truly cannot be cached; it eliminates CDN offload entirely and increases function invocation cost. |
Skills
1vercel-deploy-review/rootPre-promotion checklist before sending a Vercel deployment to production.
| 1 | --- |
| 2 | name: vercel-deploy-review |
| 3 | description: Run this checklist before promoting any Vercel deployment to production. Covers preview validation, environment variables, function config, caching, and rollback readiness for Next.js apps on Vercel in 2026. |
| 4 | --- |
| 5 | |
| 6 | # Vercel deployment review |
| 7 | |
| 8 | - [ ] Change landed on a non-production branch or PR and produced a green preview deployment. |
| 9 | - [ ] Preview URL passed health checks and key flows; build logs show no errors or unredacted secrets. |
| 10 | - [ ] No server secret is exposed via a `NEXT_PUBLIC_` variable; secrets are marked Sensitive. |
| 11 | - [ ] Environment variables are set per environment (Production/Preview/Development), with no production credentials reused in previews. |
| 12 | - [ ] Backend access uses OIDC (`VERCEL_OIDC_TOKEN`) or short-lived credentials where possible. |
| 13 | - [ ] `vercel.json` does not contain env var values, does not override `outputDirectory`/`buildCommand` for a Next.js app without good reason, and has no `version: 1`. |
| 14 | - [ ] `maxDuration` and runtime (Edge vs Node.js) are correct for each function; if Fluid Compute is on, memory is set in the dashboard, not `vercel.json`. |
| 15 | - [ ] Caching is intentional: ISR `revalidate` / `cacheLife` set, hot pages tagged with `cacheTag`, mutations call `revalidateTag` / `revalidatePath`. |
| 16 | - [ ] A known-good prior production deployment exists so instant rollback is available. |
| 17 | - [ ] Promotion will reuse the tested preview build (`vercel promote` or dashboard Promote), not a fresh rebuild. |
Why this pattern
Teams break production on Vercel by pushing untested changes, leaking secrets into client bundles, and misconfiguring functions and caching.
Built for Frontend and full-stack teams deploying Next.js apps on Vercel.
Keeps your assistant from:
- Promoting an untested build straight to the production branch
- Leaking server secrets through NEXT_PUBLIC_ variables or unredacted env values
- Stale or runaway pages from missing revalidation and wrong function durations
- License
- Apache-2.0
- Version
- 1.0.0
- Updated
- 2026-06-09