# Vercel — full corpus # LLM Wiki An open-source template for building LLM-powered knowledge bases, following [Andrej Karpathy's "LLM Wiki" pattern](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f). You provide raw sources. The LLM reads them, writes structured wiki pages, cross-links everything, and maintains it over time. You never edit the wiki directly — you curate sources and ask questions. ## How It Works The system has three layers: ``` raw/ Sources you collect (articles, transcripts, notes, PDFs) wiki/ LLM-written & maintained pages (summaries, concepts, entities, syntheses) CLAUDE.md Schema that tells the LLM how to structure everything ``` Three operations drive the workflow: | Operation | Trigger | What happens | |-----------|---------|--------------| | **Ingest** | "ingest raw/my-source.txt" | LLM reads the source, creates a summary page, creates/updates concept and entity pages, adds cross-links, updates the index and log | | **Query** | Ask any question | LLM searches the wiki, synthesizes an answer with citations, optionally creates a synthesis page for novel insights | | **Lint** | "lint" or "health check" | LLM audits all pages for orphans, contradictions, missing links, incomplete sections, and low-confidence claims — fixes what it can, reports the rest | ## Quick Start 1. **Clone this repo** ```bash git clone https://github.com/YOUR_USERNAME/llm-wiki.git my-knowledge-base cd my-knowledge-base ``` 2. **Customize CLAUDE.md** for your domain - Update the Purpose section with your topic - Replace the placeholder tagging taxonomy with your own categories - Adjust confidence level descriptions if needed - Everything else (workflows, page formats, linking rules) works as-is 3. **Drop sources into `raw/`** - Text files, transcripts, articles, notes — any plain text - These are immutable once added; the LLM never modifies them 4. **Tell the LLM to ingest** ``` ingest raw/my-first-source.txt ``` The LLM will create summary pages, concept pages, entity pages, cross-links, and update the index. 5. **Ask questions** ``` What are the key differences between X and Y? ``` The LLM answers from the wiki, citing specific pages. 6. **Run health checks** ``` lint ``` The LLM audits the wiki and fixes issues. ## Directory Structure ``` . ├── CLAUDE.md # Schema — the LLM's instructions ├── raw/ # Your source documents (immutable) └── wiki/ ├── index.md # Master catalog of all pages ├── log.md # Append-only activity log ├── dashboard.md # Dataview dashboard (Obsidian) ├── analytics.md # Charts View analytics (Obsidian) ├── flashcards.md # Spaced repetition cards ├── summaries/ # One page per source document ├── concepts/ # Concept and framework pages ├── entities/ # People, tools, organizations, etc. ├── syntheses/ # Cross-cutting analyses and comparisons ├── journal/ # Research/session journal entries │ └── template.md # Journal entry template └── presentations/ # Marp slide decks ``` ## Enhancements This template includes several extras beyond the core wiki pattern: ### Dataview Dashboard (`wiki/dashboard.md`) Live queries that surface low-confidence pages, recent updates, concepts by tag, and pages with the most sources. Requires the [Dataview](https://github.com/blacksmithgu/obsidian-dataview) Obsidian plugin. ### Charts View Analytics (`wiki/analytics.md`) Visual analytics with pie charts, bar charts, and word clouds. Requires the [Charts View](https://github.com/caronchen/obsidian-chartsview-plugin) Obsidian plugin. ### Mermaid Diagrams Use Mermaid code blocks in any wiki page to create flowcharts, sequence diagrams, or concept maps. Native support in Obsidian and GitHub. ### Marp Slides (`wiki/presentations/`) Create slide decks from markdown using [Marp](https://marp.app/). Drop presentation files in this directory. ### Research Journal (`wiki/journal/`) Track your research sessions, experiments, or applied work with the included template. The LLM can reference journal entries when answering queries. ### Spaced Repetition (`wiki/flashcards.md`) Flashcards in the format used by the [Spaced Repetition](https://github.com/st3v3nmw/obsidian-spaced-repetition) Obsidian plugin. Ask the LLM to generate flashcards from any wiki page. ### MCP Server This repo works with Claude Code's MCP server capabilities. Point an MCP-compatible client at this repo and the LLM can read/write the wiki programmatically. ## Customizing for Your Domain The schema in `CLAUDE.md` is domain-agnostic. To adapt it: 1. **Purpose** — Describe your knowledge domain in one paragraph 2. **Tagging taxonomy** — Replace placeholder categories with your own (e.g., for a cooking KB: `cuisine`, `technique`, `ingredient`, `equipment`) 3. **Confidence levels** — Adjust the descriptions to match your domain's evidence standards 4. **Entity types** — Update the entity page description to match what entities mean in your domain (people, tools, companies, etc.) 5. **Journal template** — Customize `wiki/journal/template.md` for your workflow Everything else — page format, linking conventions, workflows, rules — is universal and works across domains. ## Example Domains This template works for any knowledge-intensive topic: - **Research notes** — papers, experiments, methodologies - **Book analysis** — themes, characters, author techniques - **Competitive analysis** — companies, products, market trends - **Course notes** — lectures, readings, key concepts - **Personal development** — frameworks, habits, book summaries - **Technical documentation** — APIs, architectures, design patterns - **Hobby deep-dives** — any subject you want to master ## License MIT --- title: "Knowledge Base Index" type: index updated: 2026-06-19 --- # Knowledge Base Index Master catalog of all wiki pages. Every page in the wiki must have an entry here. ## Concepts | Page | Tags | Confidence | Updated | |------|------|------------|---------| | [what-is-vercel](concepts/what-is-vercel.md) | vercel, platform, overview | high | 2026-06-19 | | [deployments](concepts/deployments.md) | deployments, urls, rollback | high | 2026-06-19 | | [builds](concepts/builds.md) | builds, build-system, cache | high | 2026-06-19 | | [functions](concepts/functions.md) | functions, serverless, edge | high | 2026-06-19 | | [frameworks](concepts/frameworks.md) | frameworks, nextjs, isr | high | 2026-06-19 | | [git-integration](concepts/git-integration.md) | git, github, deploy-hooks | high | 2026-06-19 | | [preview-and-production](concepts/preview-and-production.md) | preview, production, skew-protection | high | 2026-06-19 | | [environment-variables](concepts/environment-variables.md) | env-vars, secrets, config | high | 2026-06-19 | | [caching-and-cdn](concepts/caching-and-cdn.md) | cdn, caching, cache-control | high | 2026-06-19 | | [routing-and-headers](concepts/routing-and-headers.md) | redirects, rewrites, headers | high | 2026-06-19 | | [project-configuration](concepts/project-configuration.md) | vercel-json, configuration | high | 2026-06-19 | | [domains](concepts/domains.md) | domains, dns, tls | high | 2026-06-19 | | [monorepos-and-storage](concepts/monorepos-and-storage.md) | monorepos, turborepo, blob, edge-config | high | 2026-06-19 | ## Entities | Page | Tags | Updated | |------|------|---------| | [vercel-cli](entities/vercel-cli.md) | cli, deploy, local-dev | 2026-06-19 | ## Summaries | Page | Source | Key Topics | Created | |------|--------|------------|---------| | [docs-catalog](summaries/docs-catalog.md) | vercel.com llms.txt | area map + excluded spaces | 2026-06-19 | ## Syntheses | Page | Pages Compared | Created | |------|----------------|---------| | [deployment-protection-and-security](syntheses/deployment-protection-and-security.md) | protection + security docs | 2026-06-19 | | [build-and-runtime-troubleshooting](syntheses/build-and-runtime-troubleshooting.md) | build/cache/function debugging | 2026-06-19 | ## Statistics - **Total pages**: 17 - **Concepts**: 13 - **Entities**: 1 - **Summaries**: 1 - **Syntheses**: 2 - **Sources ingested**: 301 (vercel.com llms.txt: 1 index + 300 core docs pages; rest-api/ai-gateway/integrations excluded) - **High confidence**: 16 - **Medium confidence**: 1 --- title: "Builds & the Build System" type: concept tags: [builds, build-system, build-cache, output] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-build-system.md, raw/llms_txt_doc-builds.md, raw/llms_txt_doc-configuring-a-build.md, raw/llms_txt_doc-build-features.md] --- # Builds & the Build System When you deploy, Vercel runs a **build** in an isolated environment, turning your source into static assets + [Functions](functions.md) (the "Build Output"). ## How a build runs 1. **Install** dependencies (auto-detected package manager: npm/pnpm/yarn/bun). 2. **Build** via the framework's build command (auto-detected) or your override. 3. **Collect output** — static files go to the [CDN](caching-and-cdn.md), serverless/edge entrypoints become [Functions](functions.md). ## Configuring a build Per-project settings (dashboard or [`vercel.json`](project-configuration.md)): - **Build command / output directory / install command** — override framework defaults. - **Root directory** — for [monorepos](monorepos-and-storage.md), point Vercel at a subdirectory. - **Node.js version** and other runtime selection. - **Environment variables** available at build time ([environment-variables](environment-variables.md)). ## Build features - **Build cache** — dependencies and framework caches persist between builds to speed them up; can be cleared when stale. - **Ignored build step** — skip a build when a commit doesn't affect the project (great for monorepos). - **Build logs** — full logs per deployment for debugging ([build-and-runtime-troubleshooting](../syntheses/build-and-runtime-troubleshooting.md)). - **Build queues / concurrency** — builds queue when you exceed concurrent-build limits. ## Build Output API Frameworks target a standard **Build Output** format so Vercel can deploy any framework's result uniformly — the mechanism behind zero-config [framework](frameworks.md) support. --- title: "Caching & the CDN" type: concept tags: [cdn, caching, cache-control, edge, isr] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-caching.md, raw/llms_txt_doc-how-vercel-cdn-works.md, raw/llms_txt_doc-cache-control-headers.md, raw/llms_txt_doc-runtime-cache.md] --- # Caching & the CDN Vercel serves your app from a **global CDN / edge network**, caching content close to users for low latency. ## What gets cached where - **Static assets** — automatically cached at the edge and served from the nearest region. - **Function responses** — cacheable at the edge via `Cache-Control` headers, so dynamic responses can be served like static ones until they expire. - **Runtime cache / Data Cache** — caches data fetches (e.g. Next.js `fetch` caching, ISR) so repeated work is avoided across requests/regions. ## Controlling the cache - **`Cache-Control` / `CDN-Cache-Control`** — the primary lever: `s-maxage` sets edge TTL, `stale-while-revalidate` serves stale content while refreshing in the background (the key pattern for fast + fresh). - **ISR** revalidation (time-based or on-demand) for [framework](frameworks.md) pages. - **Purging** — invalidate the CDN cache on demand when content changes out of band. ## How the CDN works Requests hit the nearest edge location; a cache hit returns immediately, a miss falls through to the function/origin and the result is cached per its headers. `x-vercel-cache` response header (HIT/MISS/STALE) tells you what happened — the first thing to check when debugging staleness ([build-and-runtime-troubleshooting](../syntheses/build-and-runtime-troubleshooting.md)). ## Request optimization Vercel adds **compression** (gzip/brotli) and **request collapsing** (deduping concurrent identical origin requests) automatically. Routing rules and headers that interact with caching are in [routing-and-headers](routing-and-headers.md). --- title: "Deployments" type: concept tags: [deployments, immutable, urls, rollback] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-deployments.md, raw/llms_txt_doc-managing-deployments.md, raw/llms_txt_doc-generated-urls.md, raw/llms_txt_doc-instant-rollback.md] --- # Deployments A **deployment** is the result of building your project at a point in time — an **immutable** snapshot with its own unique URL. Every push (or `vercel` CLI run) creates a new one. ## URLs - **Generated URLs** — each deployment gets a unique auto-generated URL (`--.vercel.app`) that always points to that exact build. - **Production domain** — your custom [domain](domains.md) (and the project's main `.vercel.app`) point to the *current* production deployment. - **Preview URLs** — branch/PR deployments get stable preview URLs ([preview-and-production](preview-and-production.md)). ## Production vs preview - Pushing to the **production branch** (default `main`) promotes to production. - Other branches and PRs become **preview** deployments for review. - You can **promote** an existing preview to production without rebuilding. ## Rollback Because deployments are immutable and retained, **instant rollback** re-points production to a previous known-good deployment in seconds — no rebuild, no redeploy. This is the safety net for a bad release. ## Managing deployments The dashboard and [CLI](../entities/vercel-cli.md) list deployments with status, source commit, and logs; you can redeploy, promote, roll back, or delete. Deployment **retention** policies control how long old deployments are kept. Builds that produce a deployment are covered in [builds](builds.md); protecting who can access them is [deployment protection](../syntheses/deployment-protection-and-security.md). --- title: "Domains" type: concept tags: [domains, dns, custom-domain, tls] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-vercel-domains.md, raw/llms_txt_doc-production-checklist.md, raw/llms_txt_doc-vercel-dns.md, raw/llms_txt_doc-encryption-tls.md, raw/llms_txt_doc-vercel-certs.md] --- # Domains Custom domains point your own hostname at a Vercel project's production [deployment](deployments.md). ## Adding a domain 1. Add the domain to the project (dashboard or `vercel domains` / `vercel domains add` via the [CLI](../entities/vercel-cli.md)). 2. Point DNS at Vercel: - **Apex/root** (`example.com`) → an `A` record to Vercel's IP (or `ALIAS`/`ANAME` where supported). - **Subdomain** (`www`) → a `CNAME` to `cname.vercel-dns.com`. - Or **delegate the whole domain** to Vercel nameservers (Vercel manages DNS). 3. Vercel **provisions TLS automatically** (Let's Encrypt) once DNS validates — HTTPS with auto-renewal, no manual certs. ## Domain features - **Assign per environment** — a domain can target production; previews use [preview suffixes](preview-and-production.md). - **Redirects** — e.g. force `www` → apex or vice versa ([routing-and-headers](routing-and-headers.md)). - **Buy/transfer** — domains can be registered or transferred to Vercel for unified management. - **Wildcard domains** — `*.example.com` for multi-tenant apps. ## Production checklist Before launch: custom domain assigned with HTTPS enforced, correct redirects for canonical host, environment variables set for production, and a tested rollback path ([deployments](deployments.md)). The production checklist in [docs-catalog](../summaries/docs-catalog.md) enumerates the rest. --- title: "Environment Variables" type: concept tags: [environment-variables, secrets, config] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-environment-variables.md, raw/llms_txt_doc-managing-environment-variables.md, raw/llms_txt_doc-system-environment-variables.md, raw/llms_txt_doc-sensitive-environment-variables.md] --- # Environment Variables Environment variables configure your app per environment without hardcoding values. ## Environments Each variable is scoped to one or more of: - **Production** — used by production deployments. - **Preview** — used by [preview deployments](preview-and-production.md) (optionally per-branch). - **Development** — pulled locally via `vercel env pull` for `vercel dev`. ## Managing them Set variables in the dashboard or [CLI](../entities/vercel-cli.md) (`vercel env add`). They're injected at **build time** and/or **runtime**; for client-side exposure, frameworks require a prefix (e.g. Next.js `NEXT_PUBLIC_`) — anything without it stays server-only. ## Sensitive & encrypted - **Sensitive environment variables** — values that can be written but never read back in the dashboard/API, reducing leak risk. - All variables are **encrypted at rest**; runtime secrets are decrypted only in the function environment. - **Shared variables** — define once at the team level and link to multiple projects. ## System & reserved variables Vercel injects **system environment variables** (e.g. `VERCEL`, `VERCEL_ENV`, `VERCEL_URL`, `VERCEL_GIT_*`) describing the deployment/commit — useful for runtime logic. Some names are **reserved** and can't be overridden. Rotate secrets regularly; never commit them (Vercel is the source of truth). For build-vs-runtime nuances see [builds](builds.md) and [functions](functions.md). --- title: "Frameworks & Next.js" type: concept tags: [frameworks, nextjs, isr, zero-config] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-supported-frameworks.md, raw/llms_txt_doc-all-frameworks.md, raw/llms_txt_doc-next-js.md, raw/llms_txt_doc-incremental-static-regeneration.md] --- # Frameworks & Next.js Vercel offers **zero-config** support for a wide range of web frameworks: it detects the framework and applies the correct build command, output directory, and runtime mapping automatically. ## Supported frameworks Next.js, React Router/Remix, Astro, SvelteKit, Nuxt, Vue, Vite (and Vite+Nitro), Angular, Gatsby, Create React App, plus backend frameworks (Express, Hono, Nest.js, Fastify, and Python: Flask, Django, FastAPI). Each maps onto Vercel's [build output](builds.md) and [Functions](functions.md). Static site generators and SPAs deploy as static assets on the [CDN](caching-and-cdn.md). ## Next.js (first-class) Vercel builds and maintains **Next.js**, so it's the most deeply integrated: - **App Router & Server Components**, server actions, and route handlers map directly to Vercel Functions. - **ISR (Incremental Static Regeneration)** — pages are generated on demand and cached, then revalidated by time or on-demand, combining static speed with fresh data. Vercel implements ISR natively at the edge. - **Image/font optimization, Middleware** (edge), and streaming are supported out of the box. ## Choosing build settings Zero-config is usually enough; override the build/install commands and output dir in project settings or [`vercel.json`](project-configuration.md) when needed (common for [monorepos](monorepos-and-storage.md) or custom toolchains). The full framework list and per-framework guides are mapped in [docs-catalog](../summaries/docs-catalog.md). --- title: "Vercel Functions" type: concept tags: [functions, serverless, edge, compute] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-functions.md, raw/llms_txt_doc-configuring-functions.md, raw/llms_txt_doc-what-is-compute.md] --- # Vercel Functions **Vercel Functions** run your backend code on demand — no servers to manage. They're created from your framework's API routes/server code or from files in an `api/` directory. ## Execution models - **Serverless (Node.js and other runtimes)** — full-featured functions that scale to zero and up automatically; run in a chosen **region**. Best for most backend logic, database access, and heavier work. - **Edge** — lightweight functions running on the global edge network close to users (low latency, limited APIs). Best for middleware, redirects, personalization, and fast simple responses. Vercel's compute model abstracts the underlying infrastructure ("what is compute"): you write a handler; Vercel provisions, scales, and routes to it. ## Configuring functions - **Region(s)** — pin where serverless functions run (near your database). - **Memory / CPU and max duration** — sized per function; advanced configuration sets per-route limits. - **Runtime** — Node.js (and community/other runtimes); Python and other backends are increasingly supported ([frameworks](frameworks.md)). - **Streaming** — stream responses (important for AI/LLM apps). ## Practical notes - Functions are billed by usage (invocations + compute duration). - Cold starts apply to serverless; edge has minimal cold start but a restricted API surface. - Slow functions are debuggable via logs/observability ([build-and-runtime-troubleshooting](../syntheses/build-and-runtime-troubleshooting.md)). Static assets serve from the [CDN](caching-and-cdn.md); functions handle the dynamic parts. Responses can be cached at the edge ([caching-and-cdn](caching-and-cdn.md)). --- title: "Git Integration" type: concept tags: [git, github, gitlab, deploy-hooks, ci] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-git-integrations.md, raw/llms_txt_doc-github.md, raw/llms_txt_doc-deploy-hooks.md] --- # Git Integration Vercel's primary workflow is **Git-driven**: connect a repository and every push deploys automatically. ## Supported providers GitHub, GitLab, and Bitbucket. After connecting, Vercel installs an app/integration that listens for pushes and PRs. ## What happens on push - **Push to production branch** → production [deployment](deployments.md). - **Push to any other branch / open a PR** → [preview deployment](preview-and-production.md), with the URL posted back as a PR comment/check. - **Commit status** — Vercel reports build/deploy status back to the Git provider (a required check you can gate merges on). ## Configuration - **Production branch** — which branch is production (default `main`). - **Ignored build step** — skip deploys for irrelevant commits (monorepo-friendly). - **Connected directory / root directory** — for [monorepos](monorepos-and-storage.md). - **Restricting connections** — limit which Git accounts/teams can connect to your Vercel team (security). ## Deploy hooks A **deploy hook** is a unique URL that triggers a deployment of a specific branch when called (HTTP POST) — useful for deploying on external events: a CMS publish, a cron, or another CI system. It's the "deploy without a git push" escape hatch, complementing the normal Git flow and the [CLI](../entities/vercel-cli.md). --- title: "Monorepos & Storage" type: concept tags: [monorepos, turborepo, storage, blob, edge-config] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-monorepos.md, raw/llms_txt_doc-turborepo.md, raw/llms_txt_doc-remote-caching.md, raw/llms_txt_doc-vercel-blob.md, raw/llms_txt_doc-vercel-edge-config.md] --- # Monorepos & Storage ## Monorepos A single repo can host multiple Vercel **projects** (e.g. `apps/web`, `apps/admin`). Each project sets a **root directory**; an **ignored build step** skips deploys when a commit doesn't touch that project's files ([builds](builds.md), [git-integration](git-integration.md)). - **Turborepo** — Vercel's monorepo build system; understands the dependency graph and only rebuilds what changed. - **Remote caching** — Turborepo caches build artifacts on Vercel so CI and teammates skip redundant work; a cache hit can turn a multi-minute build into seconds. Works in Vercel builds and external CI. ## Storage Vercel offers managed storage primitives that integrate with [Functions](functions.md): - **Vercel Blob** — object storage for files/images/user uploads, served over a CDN URL. Good for static-ish large assets you generate or accept at runtime. - **Edge Config** — ultra-low-latency global key-value store for configuration/feature flags read at the edge with near-zero latency (reads don't hit a database). Built for data read on almost every request. (Vercel also partners for Postgres/KV/Redis via the storage marketplace — see [docs-catalog](../summaries/docs-catalog.md).) ## Choosing storage - **Blob** → files/binaries. - **Edge Config** → tiny, read-heavy config/flags needing edge-speed reads. - App databases (Postgres/Redis) → a managed provider connected via [environment variables](environment-variables.md), with functions pinned to the DB's [region](functions.md). --- title: "Preview & Production Deployments" type: concept tags: [preview, production, promote, skew-protection] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-preview-deployment-suffix.md, raw/llms_txt_doc-sharing-a-preview-deployment.md, raw/llms_txt_doc-promote-preview-to-production.md, raw/llms_txt_doc-skew-protection.md] --- # Preview & Production Deployments Every non-production branch/PR gets a **preview deployment** — a full, live copy of the app for that change, the feature most teams adopt Vercel for. ## Previews - **Per-PR URLs** — each push updates the preview; the URL is stable per branch and posted to the PR. - **Preview deployment suffix** — customize the preview domain (e.g. use your own domain for previews instead of `*.vercel.app`). - **Sharing** — previews can be shared with stakeholders; combine with [deployment protection](../syntheses/deployment-protection-and-security.md) (password/SSO) for private previews, or sharable links for external reviewers. - **Preview environment variables** — separate values for preview vs production ([environment-variables](environment-variables.md)). ## Promotion to production A preview that's been validated can be **promoted to production** without rebuilding — the exact artifact reviewers approved becomes production, eliminating "works in preview, breaks in prod." The inverse is [instant rollback](deployments.md). ## Skew protection During a deploy, users mid-session might have an old client talking to a new backend (or vice versa) — **version skew**. **Skew protection** routes a client's requests to the deployment version it loaded, preventing broken states during rollouts. Essential for SPAs and apps with client/server contracts that change between deploys. ## Rolling releases Vercel also supports gradual **rolling releases** (shifting traffic to a new production deployment in stages) for safer launches — see [docs-catalog](../summaries/docs-catalog.md). --- title: "Project Configuration (vercel.json)" type: concept tags: [vercel-json, configuration, project-settings] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-advanced-configuration.md, raw/llms_txt_doc-configuration-redirects.md, raw/llms_txt_doc-rewrites.md, raw/llms_txt_doc-response-headers.md, raw/llms_txt_doc-cron-jobs.md, raw/llms_txt_doc-configuring-functions.md, raw/llms_txt_doc-git-integrations.md] --- # Project Configuration (vercel.json) Most projects need no config (zero-config [framework](frameworks.md) detection), but `vercel.json` at the project root lets you override defaults and declare platform behavior in version-controlled form. ## Common keys - **`buildCommand` / `installCommand` / `outputDirectory` / `framework`** — override [build](builds.md) detection. - **`redirects` / `rewrites` / `headers` / `cleanUrls` / `trailingSlash`** — [routing](routing-and-headers.md) rules. - **`functions`** — per-function config: memory, `maxDuration`, runtime, and regions ([functions](functions.md)). Advanced configuration sets these per path pattern. - **`regions`** — where serverless functions execute. - **`crons`** — scheduled invocations of function paths (Cron Jobs). - **`git` / `ignoreCommand`** — ignored build step logic. ## Precedence Dashboard settings and `vercel.json` interact: `vercel.json` is committed with the code, so it is versioned, reviewable, and consistent across environments. Framework config files (`next.config.js`, etc.) handle framework-internal concerns. ## Why prefer vercel.json Putting redirects, headers, function limits, and crons in `vercel.json` keeps configuration with the code, versioned and reviewed in [pull requests](git-integration.md), rather than as out-of-band dashboard clicks. The exhaustive key reference is mapped in [docs-catalog](../summaries/docs-catalog.md). --- title: "Routing: Redirects, Rewrites & Headers" type: concept tags: [routing, redirects, rewrites, headers, security-headers] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-routing.md, raw/llms_txt_doc-redirects.md, raw/llms_txt_doc-rewrites.md, raw/llms_txt_doc-security-headers.md] --- # Routing: Redirects, Rewrites & Headers Vercel routes incoming requests to static assets, [functions](functions.md), redirects, or rewrites — configurable in [`vercel.json`](project-configuration.md) or via your framework. ## Redirects Send clients to a new URL with a status code (301/302/307/308). Defined as `source` → `destination` with optional path params and `permanent` flag. Use for moved pages, enforcing canonical hosts, and locale routing. **Bulk redirects** handle large redirect maps at scale. ## Rewrites Serve content from a different path **without changing the URL** the user sees — proxy `/api/*` to a backend, mask a path, or implement clean URLs. Unlike a redirect, the browser URL stays the same. Rewrites can target external origins (a reverse-proxy pattern). ## Headers Add custom HTTP headers per path — most importantly **security headers**: - `Strict-Transport-Security`, `X-Content-Type-Options: nosniff`, `X-Frame-Options`, `Referrer-Policy`, `Content-Security-Policy`, `Permissions-Policy`. - `Cache-Control` for [caching](caching-and-cdn.md). ## Order & precedence Routing rules have a defined precedence (redirects before rewrites before filesystem before functions). Framework-level routing (Next.js `next.config.js`, middleware) composes with `vercel.json`. Project routing rules and edge middleware handle more dynamic cases — see [docs-catalog](../summaries/docs-catalog.md). --- title: "What is Vercel" type: concept tags: [vercel, platform, overview, frontend-cloud] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-fundamental-concepts.md, raw/llms_txt_doc-getting-started.md] --- # What is Vercel **Vercel** is a cloud platform for deploying and hosting web applications — the "frontend cloud." You connect a Git repository (or push from the CLI); Vercel **builds** your app, deploys it to a global **CDN/edge network**, and gives every push a live URL, with serverless **Functions** for backend logic. ## The core model - **Git-driven** — every push creates a [deployment](deployments.md); the default branch becomes production, other branches/PRs become [preview deployments](preview-and-production.md). - **Zero-config for frameworks** — Vercel detects your [framework](frameworks.md) (Next.js, Astro, SvelteKit, Nuxt, Vite, …) and applies the right build + output settings automatically. - **Build → immutable deployment** — each build produces an immutable, independently-addressable deployment ([builds](builds.md), [deployments](deployments.md)). - **Compute on demand** — [Functions](functions.md) run serverless/edge code; static assets serve from the [CDN](caching-and-cdn.md). ## What you manage A **project** ties a repo to its settings: [environment variables](environment-variables.md), [domains](domains.md), build config ([project-configuration](project-configuration.md) / `vercel.json`), and [deployment protection](../syntheses/deployment-protection-and-security.md). Teams add collaboration and access control. ## Why teams use it Push-to-deploy with automatic previews per PR, instant rollbacks, global low-latency delivery, and no server management. Vercel created and maintains **Next.js**, so that framework is especially first-class — but the platform supports any framework or static output, and increasingly backend runtimes ([frameworks](frameworks.md)). Full area map: [docs-catalog](../summaries/docs-catalog.md). --- title: "Vercel CLI" type: entity tags: [cli, vercel-cli, deploy, local-dev] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-deploying-from-cli.md, raw/llms_txt_doc-cli-reference.md] --- # Vercel CLI The **Vercel CLI** (`vercel`, installed via `npm i -g vercel`) drives the platform from the terminal — deploy, manage env vars, run a local dev server, and inspect deployments without the dashboard. ## Core commands - **`vercel`** — deploy the current directory to a **preview**; **`vercel --prod`** deploys to production ([deployments](../concepts/deployments.md)). - **`vercel dev`** — run the project locally, emulating Functions and routing. - **`vercel env pull`** — download [environment variables](../concepts/environment-variables.md) into `.env.local` for local dev; `vercel env add/rm` to manage them. - **`vercel link`** — connect a local directory to a Vercel project. - **`vercel logs `** — stream runtime logs; **`vercel inspect`** for deployment details. - **`vercel domains` / `vercel dns`** — manage [domains](../concepts/domains.md) and DNS. - **`vercel pull`** — fetch project settings/env for reproducible local builds. ## When to use it The CLI is the path for deploying **without Git** (CI systems, scripts, or local one-offs — complementing [deploy hooks](../concepts/git-integration.md)), for local development that matches production behavior, and for scripting project/env management. In [Actions](../concepts/git-integration.md) or other CI, `vercel deploy --prebuilt` deploys a locally-built output. The full command/flag reference is on the docs site; this page covers the high-traffic commands. (Note: Vercel also ships a separate **Sandbox CLI** for its sandbox product — distinct from this project CLI.) --- title: "Activity Log" type: log --- # Activity Log Append-only record of all wiki changes. ## Format Each entry follows this format: ``` ### YYYY-MM-DD HH:MM — [Action Type] - **Source/Trigger**: what initiated the action - **Pages created**: list of new pages - **Pages updated**: list of updated pages - **Notes**: any contradictions flagged, decisions made ``` --- ### 2026-04-08 00:00 — Setup - **Source/Trigger**: Repository initialized - **Pages created**: index.md, log.md, dashboard.md, analytics.md, flashcards.md - **Pages updated**: none - **Notes**: Empty knowledge base ready for first source ingestion ### 2026-06-19 00:00 — Initial curation (medium rung) - **Source/Trigger**: vercel.com llms.txt (1020-link index); two gather passes (see note) - **Pages created**: 13 concepts, 1 entity (vercel-cli), 1 summary (docs-catalog), 2 syntheses (deployment-protection-and-security, build-and-runtime-troubleshooting) - **Pages updated**: index.md - **Notes**: First gather (max 150) starved CLI/functions/domains/storage (they sort after the included sections in the llms.txt). Fixed by raising max to 300 + re-gather (raw/ union = 301). Excluded rest-api (329 links)/ai-gateway (97)/integrations/pricing/rbac by url_exclude. build-troubleshooting confidence:medium. --- title: "Docs Catalog" type: summary tags: [catalog, map, reference] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-vercel-documentation.md, raw/llms_txt_doc-fundamental-concepts.md] --- # Docs Catalog Map of the vercel.com docs (published via a 1020-link llms.txt; ~300 core pages mirrored in `raw/` as `llms_txt_doc-.md`). This wiki distills the developer-platform core; large reference and adjacent-product spaces are mapped here, not ingested. | Area | Raw slugs (selection) | Wiki coverage | |---|---|---| | Fundamentals | fundamental-concepts, getting-started, vercel-documentation | [what-is-vercel](../concepts/what-is-vercel.md) | | Deploy | deployments, managing-deployments, generated-urls, instant-rollback, rolling-releases, deploy-hooks | [deployments](../concepts/deployments.md), [preview-and-production](../concepts/preview-and-production.md) | | Build | build-system, builds, configuring-a-build, build-features, build-queues | [builds](../concepts/builds.md) | | Compute | functions, configuring-functions, what-is-compute, advanced-configuration | [functions](../concepts/functions.md) | | Frameworks | supported-frameworks, all-frameworks, next-js, nuxt, astro, sveltekit, remix, vite, express, fastapi, django, flask | [frameworks](../concepts/frameworks.md) | | Git | git-integrations, github, gitlab, bitbucket | [git-integration](../concepts/git-integration.md) | | Env vars | environment-variables, managing/system/sensitive/shared-environment-variables | [environment-variables](../concepts/environment-variables.md) | | CDN/cache | caching, how-vercel-cdn-works, cache-control-headers, runtime-cache, purge-cdn-cache, compression | [caching-and-cdn](../concepts/caching-and-cdn.md) | | Routing | routing, redirects, rewrites, security-headers, bulk-redirects, project-routing-rules | [routing-and-headers](../concepts/routing-and-headers.md) | | Config | advanced-configuration, configuration-redirects | [project-configuration](../concepts/project-configuration.md) | | Domains | vercel-domains (CLI), dns | [domains](../concepts/domains.md) | | CLI | deploying-from-cli, cli-reference | [vercel-cli](../entities/vercel-cli.md) | | Monorepo/storage | monorepos, turborepo, remote-caching, vercel-blob, vercel-edge-config | [monorepos-and-storage](../concepts/monorepos-and-storage.md) | | Protection/security | deployment-protection, password-protection, trusted-ips, protection-bypass-for-automation, vercel-firewall, saml-sso | [deployment-protection-and-security](../syntheses/deployment-protection-and-security.md) | | Troubleshooting | troubleshoot-build-errors, debug-cache-issues, debug-slow-functions, accessing-build-logs | [build-and-runtime-troubleshooting](../syntheses/build-and-runtime-troubleshooting.md) | ## Excluded by design (look up live) - **REST API reference** (`/docs/rest-api`, ~329 pages) and **webhooks API reference** — use the docs site / SDK. - **AI Gateway / AI SDK** (separate product, ~97 pages), **integrations marketplace**, **pricing/plans**, **RBAC/observability/drains**, **microfrontends**, **multi-tenant** — adjacent or enterprise; out of scope here. --- title: "Build & Runtime Troubleshooting Casebook" type: synthesis tags: [troubleshooting, builds, cache, functions, casebook] updated: 2026-06-19 confidence: medium sources: [raw/llms_txt_doc-troubleshoot-build-errors.md, raw/llms_txt_doc-debug-cache-issues.md, raw/llms_txt_doc-debug-slow-functions.md, raw/llms_txt_doc-accessing-build-logs.md, raw/llms_txt_doc-configuring-a-build.md, raw/llms_txt_doc-monorepos.md, raw/llms_txt_doc-environment-variables.md, raw/llms_txt_doc-cache-control-headers.md, raw/llms_txt_doc-purge-cdn-cache.md, raw/llms_txt_doc-sharable-links.md, raw/llms_txt_doc-vercel-domains.md] --- # Build & Runtime Troubleshooting Casebook Common Vercel failure modes and where to look. Confidence medium — distilled from the troubleshooting docs. ## Build fails - **Read the build logs first** — every deployment has full logs (dashboard or `vercel logs`/inspect). The error is almost always there ([builds](../concepts/builds.md)). - **Works locally, fails on Vercel** — usually a missing [environment variable](../concepts/environment-variables.md) at build time, a case-sensitive import (Vercel builds on Linux), or a Node version mismatch (pin it in settings/`vercel.json`). - **Wrong package manager / lockfile** — Vercel auto-detects from the lockfile; commit the right one. - **Monorepo building the wrong thing** — set the **root directory** and an **ignored build step** ([monorepos-and-storage](../concepts/monorepos-and-storage.md)). ## Stale or wrong content served - **Check `x-vercel-cache`** (HIT/MISS/STALE) on the response — tells you if you're seeing a cached copy ([caching-and-cdn](../concepts/caching-and-cdn.md)). - **Purge the CDN cache** after out-of-band content changes; verify `Cache-Control`/`s-maxage` are what you intend. - **ISR not revalidating** — confirm the revalidate interval / on-demand revalidation is wired correctly ([frameworks](../concepts/frameworks.md)). ## Slow or failing functions - **Cold starts** — serverless functions cold-start; keep bundles small, pin the [region](../concepts/functions.md) near your database to cut latency. - **Timeouts** — raise `maxDuration` (within plan limits) or move long work off the request path; stream responses for AI workloads. - **Debug slow functions** — use logs/observability to find the slow span (DB query, external API). ## Access issues - **404 / login wall on a preview** — [deployment protection](deployment-protection-and-security.md) is on; use an automation-bypass token or a sharable link. - **Domain not resolving / no HTTPS** — DNS not pointed correctly or still propagating ([domains](../concepts/domains.md)); TLS provisions only after DNS validates. --- title: "Deployment Protection & Security" type: synthesis tags: [security, deployment-protection, access, headers] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-deployment-protection.md, raw/llms_txt_doc-password-protection.md, raw/llms_txt_doc-trusted-ips.md, raw/llms_txt_doc-protection-bypass-for-automation.md, raw/llms_txt_doc-security-headers.md, raw/llms_txt_doc-sharable-links.md, raw/llms_txt_doc-sensitive-environment-variables.md, raw/llms_txt_doc-restricting-git-connections-to-a-single-vercel-team.md, raw/llms_txt_doc-firewall.md, raw/llms_txt_doc-configuring-functions.md] --- # Deployment Protection & Security How to control who can reach your deployments and harden what you ship — pulled together from the protection and security docs. ## Restricting access to deployments By default preview/production URLs are public. **Deployment Protection** locks them down: - **Vercel Authentication** — require a logged-in Vercel team member to view a deployment (great for staging/previews). - **Password protection** — a shared password gate on deployments (share previews with external stakeholders privately). - **Trusted IPs** — allowlist specific IP ranges (enterprise). - **Sharable links** — time-limited links that bypass protection for specific reviewers. ## Automation bypass Protected deployments block bots/tests too. **Protection Bypass for Automation** issues a secret token (`x-vercel-protection-bypass` header / query param) so CI, synthetic monitors, and automated agents can reach a protected deployment without a human login. Rotate it like any secret. ## Hardening what you ship - **Security headers** — set HSTS/CSP/`X-Content-Type-Options`/etc. via [routing-and-headers](../concepts/routing-and-headers.md) or `vercel.json`. - **Sensitive env vars** — write-only secrets that can't be read back ([environment-variables](../concepts/environment-variables.md)). - **Least-privilege functions** — pin regions, set `maxDuration`, validate input ([functions](../concepts/functions.md)). - **Restrict Git connections** — limit which accounts can deploy ([git-integration](../concepts/git-integration.md)). - **Vercel Firewall / DDoS** — platform-level request filtering and rate limiting (see [docs-catalog](../summaries/docs-catalog.md)). ## A sane default posture Public production behind a custom domain with security headers + WAF; previews behind Vercel Authentication or password; an automation-bypass token for CI; secrets as sensitive env vars scoped per environment.