PathruleBu sayfa yalnızca İngilizce olarak mevcut.
Vercel Deployment
Pathrule2 kural • 3 hafıza kaydı • 1 beceri
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.
Önerilen yol haritası
Pathrule her parçayı eşleşen yola yerleştirir; böylece asistanınız onu yalnızca ait olduğu yerde görür. İçe aktardığınızda kapsam böyle kurulur; isterseniz çalışma alanınızda değiştirebilirsiniz.
/ çalışma alanı kökü
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
Kurallar
2Preview first, then promote to production/rootyüksekkatıNever 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/rootyüksekkatıOnly 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. |
Hafıza kayıtları
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. |
Beceriler
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. |
Neden bu kalıp
Teams break production on Vercel by pushing untested changes, leaking secrets into client bundles, and misconfiguring functions and caching.
Hedef kitle: Frontend and full-stack teams deploying Next.js apps on Vercel.
Asistanınızı şunlardan alıkoyar:
- 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
- Lisans
- Apache-2.0
- Sürüm
- 1.0.1
- Güncellendi
- 2026-08-25