Vercel platform and deployments

The Vercel platform is built around a simple invariant: every git push produces an immutable, isolated deployment with its own URL. Production is one of many deployments — promoted from a preview by clicking a button or by merging to the default branch. The build, deployment cache, environment variables, and routing config are all framework-aware (Next.js, Astro, SvelteKit, Nuxt, Remix, Vue, React, Svelte, Solid, Hugo, and others auto-detected from package.json). Operational primitives — Skew Protection, Rolling Releases, Instant Rollback, Deployment Protection — make this a real production platform, not just a preview-URL service.

1. Projects and deployments

Per vercel.com/docs/deployments.

A project is a Vercel-managed unit linked to a git repository (GitHub, GitLab, Bitbucket — or external). A project has:

Build settings — auto-detected from framework or configured in vercel.json / dashboard
Environment variables — three scopes: Production / Preview / Development
Domains — custom or *.vercel.app
Functions — server code (auto-deployed alongside frontend)
Storage bindings — Blob, Edge Config, Marketplace databases

A deployment is an immutable build:

Every git push to the linked repo produces a deployment.
Each deployment has a unique URL like <project>-<git-hash>-<scope>.vercel.app.
Deployments are immutable — you can promote, demote, alias, redirect to them, but you cannot edit a deployment in place. Build a new one.
The most recent deployment on the production branch (default main) becomes the production deployment, unless overridden.

2. Environments

Three default environments, each with its own env var scope:

Environment	Trigger	URL pattern
Production	Push to production branch (default `main`) or manual promote	Custom domain + `<project>.vercel.app`
Preview	Push to any other branch, or open PR	`<project>-<git-hash>-<scope>.vercel.app`
Development	`vercel dev` locally	`localhost:3000`

Custom environments (Pro+) — define additional named environments (e.g. staging, qa) with their own env vars and domain pattern. Useful when more than 3 envs are needed.

3. Git integration

Per vercel.com/docs/git. Connect a project to a repo and Vercel auto-deploys:

Push to a non-production branch → new preview deployment.
Open a PR → preview URL is commented on the PR.
Push to production branch → new production deployment (or, if Rolling Releases enabled, a partial rollout).
Tag a commit → preview deployment with tag-based URL.

Ignored Build Step — define a script that decides whether to skip the build. Useful for monorepos where only certain paths changing should trigger a rebuild:

# vercel.json or in Project Settings → Git → Ignored Build Step
git diff HEAD^ HEAD --quiet -- apps/web packages/ui && exit 0 || exit 1

Exit 0 = skip build, exit 1 = build.

4. Skew Protection

Per vercel.com/docs/skew-protection. When you deploy a new version of your app, in-flight requests from clients with the old JavaScript may hit incompatible new server code. Skew Protection routes API calls from a known-version client to the server deployment of the same version for up to 24 hours after deployment.

How it works:

Each deployment is tagged with a deployment ID.
Client-side code embeds the deployment ID in API request headers (x-deployment-id).
Vercel’s edge router uses that header to route to the corresponding server deployment if it still exists.

Enable in next.config.js:

module.exports = {
  experimental: { skewProtection: true },
};

Other frameworks: set VERCEL_SKEW_PROTECTION_ENABLED=1 in env vars and ensure your client sends x-deployment-id.

5. Build Cache

Per vercel.com/docs/build-cache. Vercel caches build outputs between deployments. For Next.js, the cache includes .next/cache/, node_modules/.cache/, and webpack/turbopack incremental state. Typical reduction: 30-70% in build time on incremental changes.

The cache is per project, scoped per branch. Cache misses on first build of a new branch.

Force a clean build via vercel build --force or “Redeploy without build cache” in the dashboard.

6. Skew Protection vs Rolling Releases vs Instant Rollback — the operational trio

These three features address related but distinct production concerns:

Feature	Purpose	Plan
Skew Protection	Avoid client-server version skew during rollout (clients with old JS hit matching old server)	Pro+
Rolling Releases	Gradually shift traffic to a new deployment (canary)	Enterprise (or Pro with the toggle)
Instant Rollback	Atomically revert production to a previous deployment	All plans

6.1 Rolling Releases

Per vercel.com/docs/rolling-releases. Configure a release stage in the dashboard:

Stage 1: 5% traffic for 10 min
Stage 2: 25% traffic for 10 min
Stage 3: 50% traffic for 10 min
Stage 4: 100%

Vercel monitors error rates and pauses/rolls back automatically if errors spike during a stage.

6.2 Instant Rollback

Per vercel.com/docs/instant-rollback. Click “Promote to Production” on any prior deployment. The DNS-level routing change is instant (under 1 second). The old build doesn’t have to redeploy — it’s already built and held warm.

vercel rollback <deployment-url> from CLI.

7. Deployment Protection

Per vercel.com/docs/deployment-protection. Three options for protecting preview/production deployments:

Protection mode	Behavior	Plan
Public	Anyone with URL can access	All
Standard Protection	Login required (Vercel team members) for previews	Pro+
Trusted IPs	Restrict to allowlisted CIDR ranges	Enterprise
Password Protection	Single shared password for previews	Pro+

For previews, Standard Protection is the default on new Pro projects. Useful: invite stakeholders to your Vercel team with “viewer” role, they can see all previews.

Bypass tokens — generate per-deployment URLs that include a bypass token in the query string for sharing with external testers without requiring login.

8. Environment variables

Per vercel.com/docs/environment-variables. Set in:

Dashboard (Project Settings → Environment Variables)
CLI: vercel env add <name> [environment]
.env.local for development (loaded by Next.js / SvelteKit / Astro automatically)

Three scopes (per env var):

Production — production deployments only
Preview — preview deployments (or specific branches)
Development — vercel dev

Sensitive flag — variables marked sensitive are write-only (you can’t read them back via the dashboard or CLI after creation).

Edge Config integration — for read-mostly config that changes without redeployment, write to Edge Config instead of env vars. See vercel-storage-and-data.

9. `vercel.json` configuration

Per vercel.com/docs/project-configuration. The optional project config file:

{
  "buildCommand": "pnpm build",
  "outputDirectory": "dist",
  "framework": "vite",
  "regions": ["iad1", "sfo1"],
  "functions": {
    "api/**/*.ts": {
      "runtime": "nodejs22.x",
      "memory": 1024,
      "maxDuration": 30
    },
    "api/edge/*.ts": {
      "runtime": "edge"
    }
  },
  "headers": [
    {
      "source": "/(.*)",
      "headers": [{ "key": "X-Frame-Options", "value": "DENY" }]
    }
  ],
  "redirects": [
    { "source": "/old", "destination": "/new", "permanent": true }
  ],
  "rewrites": [
    { "source": "/api/proxy/(.*)", "destination": "https://api.example.com/$1" }
  ],
  "crons": [
    { "path": "/api/cron/cleanup", "schedule": "0 0 * * *" }
  ]
}

For Next.js, most of this lives in next.config.js instead. vercel.json is mostly used for non-Next frameworks or for vercel-specific overrides.

10. Monorepo support (Turborepo, pnpm workspaces, Nx)

Per vercel.com/docs/monorepos. Configure the root directory + build command per project:

Root Directory — apps/web (the subfolder of the monorepo where this project lives)
Build Command — cd ../.. && pnpm turbo build --filter=web (so Turborepo can use cache across apps)

Turborepo’s remote cache is integrated automatically with Vercel projects — no setup needed beyond npx turbo link. Build outputs cached on Vercel’s CDN are shared across team members + CI.

Multiple Vercel projects can point at the same git repo with different root directories. Common pattern: one repo → one project per app in apps/.

11. CLI reference

Per vercel.com/docs/cli. Key commands:

vercel                           # deploy current dir to preview
vercel --prod                    # deploy to production
vercel ls                        # list deployments
vercel inspect <url>             # detailed info about a deployment
vercel logs <url>                # stream logs
vercel env pull                  # pull production env vars to .env.local
vercel env add <name> <env>      # add env var
vercel link                      # link current dir to a Vercel project
vercel dev                       # local dev server with serverless emulation
vercel build                     # build locally (creates .vercel/output)
vercel deploy --prebuilt         # deploy a pre-built .vercel/output dir
vercel rollback <url>            # rollback production to this deployment
vercel install <integration>     # install a Marketplace integration (Neon, Upstash)
vercel certs ls                  # SSL cert management
vercel project add <name>        # create a new project from CLI
vercel teams ls                  # list teams

vercel.com/docs/cli/install covers the install instructions: npm i -g vercel.

12. Build process and `vc build` output

Per vercel.com/docs/build-output-api. Internally, every Vercel build produces a .vercel/output/ directory in the Build Output API v3 format:

.vercel/output/
├── config.json          # routes, framework metadata
├── static/              # static assets served by CDN
└── functions/           # function bundles (per route)
    └── api/
        └── chat.func/
            ├── .vc-config.json
            └── index.js

This is what gets deployed. Building locally with vercel build then vercel deploy --prebuilt lets you:

Build in your own CI (e.g. GitHub Actions) for security or speed.
Deploy across multiple regions/teams from the same artifact.
Debug a failing build locally without burning Vercel minutes.

13. Deployment Hooks

Per vercel.com/docs/git/deploy-hooks. Webhook URLs that trigger deployments. Use for:

Scheduled deploys (cron + curl).
CMS-driven rebuilds (Sanity, Contentful, Strapi → webhook → Vercel deploys).
Cross-repo dependency rebuilds.

curl -X POST https://api.vercel.com/v1/integrations/deploy/prj_abc/hook_xyz

14. Domains, SSL, edge routing

Per vercel.com/docs/domains. SSL certificates are automatic (Let’s Encrypt + Vercel-managed) and renewal is automatic. Custom domains are added in the dashboard with CNAME or A-record DNS entries.

Multi-region domain routing — same project can serve multiple regions; Vercel’s edge routes requests to the nearest CDN POP. For serverless functions tied to a specific region (e.g. iad1), the function still runs in that region — edge POPs route the request there, but the function execution latency is gated by region distance.

15. Claim deployments — let agents deploy

Per vercel.com/docs/deployments/claim-deployments (re:Invent / Vercel Ship 2024). v0 and other AI agents can deploy a project unattached to any account, then later a human “claims” the deployment to take ownership. Pattern: AI deploys, human reviews, claim if good.

# Agent deploys without auth
vercel --no-auth   # → claim URL emailed/printed
 
# Human claims:
vercel claim <claim-url>

16. Spend management

Per vercel.com/docs/billing/spend-management. Set hard spending caps per project or per team. When the cap is hit, the project enters degraded mode — static assets continue serving, but new function invocations return 402. Avoids surprise bills from a runaway loop or DDoS.

Recommended for new projects: set a low cap (e.g. $10) during development, raise once you understand usage patterns.

17. Plans and pricing tiers

Per vercel.com/pricing. As of 2026-05-25:

Feature	Hobby (free)	Pro ($20/seat/mo)	Enterprise
Bandwidth	100 GB / mo	1 TB included	Custom
Function invocations	100k/mo	1M included	Custom
Function compute	100 GB-Hrs	1000 GB-Hrs included	Custom
Edge requests	1M/mo	10M included	Custom
Build minutes	6000/mo (100h)	24000/mo (400h)	Custom
Team seats	1	Up to 10	Custom
Custom domains	Yes	Yes	Yes
Skew Protection	No	Yes	Yes
SSO	No	No	Yes (SAML)
Trusted IPs	No	No	Yes
99.99% SLA	No	No	Yes
Concurrent builds	1	3-12	Custom

Hobby is genuinely free for personal projects — no credit card required to start. Limits are restrictive (no team members beyond yourself, no commercial use per ToS) but generous for hobbyist learning.

18. Commercial use restriction (Hobby tier)

Per Vercel’s ToS: Hobby is for personal, non-commercial use only. Running a real business on Hobby violates ToS and Vercel reserves the right to require an upgrade. In practice, the limits (100GB/month bandwidth) catch most real businesses anyway.

Compendium

Explorer

Vercel platform and deployments

Vercel platform and deployments

See also

1. Projects and deployments

2. Environments

3. Git integration

4. Skew Protection

5. Build Cache

6. Skew Protection vs Rolling Releases vs Instant Rollback — the operational trio

6.1 Rolling Releases

6.2 Instant Rollback

7. Deployment Protection

8. Environment variables

9. `vercel.json` configuration

10. Monorepo support (Turborepo, pnpm workspaces, Nx)

11. CLI reference

12. Build process and `vc build` output

13. Deployment Hooks

14. Domains, SSL, edge routing

15. Claim deployments — let agents deploy

16. Spend management

17. Plans and pricing tiers

18. Commercial use restriction (Hobby tier)

Further reading

Graph View

Table of Contents

Compendium

Explorer

Vercel platform and deployments

Vercel platform and deployments

See also

1. Projects and deployments

2. Environments

3. Git integration

4. Skew Protection

5. Build Cache

6. Skew Protection vs Rolling Releases vs Instant Rollback — the operational trio

6.1 Rolling Releases

6.2 Instant Rollback

7. Deployment Protection

8. Environment variables

9. vercel.json configuration

10. Monorepo support (Turborepo, pnpm workspaces, Nx)

11. CLI reference

12. Build process and vc build output

13. Deployment Hooks

14. Domains, SSL, edge routing

15. Claim deployments — let agents deploy

16. Spend management

17. Plans and pricing tiers

18. Commercial use restriction (Hobby tier)

Further reading

Graph View

Table of Contents

9. `vercel.json` configuration

12. Build process and `vc build` output