Vercel deployment & CI/CD guide: preview, Promote, Instant Rollback, and Rolling Releases at production quality

If you end deployment at "I git pushed and it went to production," someday it'll surely cause an accident. Vercel's true value is that it's equipped from the start with safety valves that hold down production accidents both "before shipping" and "after shipping." This article, faithful to the official specs of Rolling Releases and Instant Rollback, collects in real commands a deployment operation that ships safely and reverts instantly.

For the big picture, see the Vercel production-operations guide. This piece concentrates on "how to ship and how to revert."

The four safety valves

These work because Vercel deployments are immutable snapshots. Each deployment has a unique URL, and past ones live on. So "revert" isn't a redeploy but a routing switch that finishes in an instant.

Preview deployments: review in a production-quality environment

Once Git-linked, a preview deployment is created on every push, with an independent URL issued. It runs on the same build, same functions, and same edge as production, so you can crush "it worked locally."

# 手動でプレビューを作る（CLI）
vercel deploy
# → https://your-app-git-feature-xyz.vercel.app のような固有URL

The preview is commented on the PR, and reviewers can touch the real thing to confirm. Running E2E (Playwright, etc.) against the preview URL catches regressions before merge (Playwright E2E design).

Protect the preview too: preview URLs are public. If you have staging-equivalent confidential content, control access with Vercel's deployment protection (password/SSO) or the Firewall.

To production: Promote and Instant Rollback

Production Promote

Promote a verified preview deployment to production without rebuilding. "The built artifact = the artifact that goes to production" is guaranteed, and accidents from build differences disappear.

vercel promote <deployment-url-or-id>   # 本番へ昇格

Instant Rollback

If a problem appears in production, instantly revert to a past production deployment. Being an immutable deployment, you don't wait for a build either.

vercel rollback <deployment-url-or-id>  # 指定デプロイへ即時復帰
# 引数なしなら直前の本番へ

The ISR cache reverts too: even on rollback, a past deployment's ISR cache isn't purged, so you can revert without losing generated content (caching strategy).

Rolling Releases: don't ship to 100% all at once

"Releasing a new deployment to all users at once" is the highest-risk act. Rolling Releases flows the new deployment to only a part first (e.g., 5%) and gradually widens to 100% while watching metrics (Pro is 1 project, Enterprise is custom).

Stage design

Once enabled, set two or more stages. Each stage is the ratio flowing to the canary, larger for later stages, with the final stage always 100%. Many projects suffice with the two-step "one small stage + 100%."

例）2段：  5%  → 100%
例）3段：  5%  →  25%  → 100%

Each promote operation (auto-promotion on git push, the dashboard's Promote, vercel promote) starts a new Rolling Release. While a Rolling Release is in progress, the next won't start until it's resolved (completed or aborted).

Judge the canary

While in progress, the deployment list shows the release candidate with a "Canary" badge and the inflow ratio, and the Rolling Releases section of the Observability tab lets you compare Vercel-measured metrics (Speed Insights, etc.) canary vs. current. If good, "Advance" to the next stage, or for the final stage promote to 100% and return to the normal state. If bad —

Abort（中断）/ Instant Rollback でベースデプロイへ戻す

Required: Skew Protection

In Rolling Releases, a given user splits over which of the new/old pages they receive. At this time, if the version of the backend API call going out from the page diverges from the page, it breaks. Skew Protection ensures "every user, whichever deployment they hit, communicates with the same-version backend as that page."

The official docs also state plainly, "Skew Protection is strongly recommended for Rolling Releases." Enable them as a set. Forget it and you'll be plagued by tricky bugs that only reproduce during delivery (e.g., an old client hitting the new API).

Verify without production traffic

During a Rolling Release, appending a special query to the URL forcibly directs only your own session to the canary/current.

• ?vcrrForceCanary=true … always canary (accessible even on a 0%-set stage)
• ?vcrrForceStable=true … always base (current)

# カナリアだけを自分で確認（一般ユーザーには5%しか出していない状態で）
open "https://your-app.vercel.app/checkout?vcrrForceCanary=true"

Caution: anyone can append vcrrForceCanary=true. A 0% canary isn't delivered by default, but it's not hidden. Protect features you truly want to hide not with Rolling Releases but with feature flags (Edge Config) or authorization.

Automate with the REST API / CLI

Rolling Releases can be controlled via API and built into CI/CD.

Caution on aborting via API: even if you disable the config (PATCH/DELETE) while in progress, that alone doesn't stop the current Rolling Release (it only affects future releases). You need to separately call complete (canary to 100%) or rollback (to the base).

CI/CD: rebuild-free promotion with GitHub Actions

CI/CD runs with Vercel's Git linkage alone, but when you want to insert your own tests/gates, the standard is to ship with --prebuilt from GitHub Actions. You can promote "the once-built artifact as-is to production," erasing build differences and build time.

# .github/workflows/deploy-production.yml
name: Deploy Production
on:
  push:
    branches: [main]

permissions:
  contents: read
  id-token: write   # OIDC（鍵レス）に必要

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 24 }

      - run: npm ci

      # 品質ゲート（型・lint・テスト）— 通らなければ出さない
      - run: npm run lint && npm run test && npx tsc --noEmit

      - run: npm i -g vercel@latest

      # ① 環境情報を取得 → ② ビルド → ③ 成果物をそのままデプロイ
      - run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}
      - run: vercel build --prod --token=${{ secrets.VERCEL_TOKEN }}
      - run: vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}

Keyless (OIDC) is the 2026 standard: instead of placing external-cloud (AWS, etc.) credentials in CI, obtain temporary credentials with GitHub's OIDC token. Using Vercel's OIDC federation, you avoid storing long-lived access keys in secrets (the thinking on OIDC keyless CI/CD). Scope VERCEL_TOKEN itself narrowly and rotate it.

Configuration is vercel.ts (type-safe, dynamic)

Build, routing, headers, Cron, and function settings can be declared type-safely in vercel.ts. Unlike vercel.json, it runs at build time, so you can branch on environment variables or fetch settings from an API (use only one of the two).

// vercel.ts
import { routes, deploymentEnv, type VercelConfig } from "@vercel/config/v1";

const isProd = deploymentEnv.VERCEL_ENV === "production";

export const config: VercelConfig = {
  framework: "nextjs",
  buildCommand: "npm run build",
  // 本番だけ別バックエンドへ rewrite するような動的設定が書ける
  rewrites: [
    routes.rewrite("/api/(.*)", isProd
      ? "https://api.example.com/$1"
      : "https://staging-api.example.com/$1"),
  ],
  headers: [
    routes.cacheControl("/assets/(.*)", { public: true, maxAge: "1 year", immutable: true }),
  ],
  crons: [{ path: "/api/cron/cleanup", schedule: "0 0 * * *" }],
};

Just add @vercel/config and export config. If migrating from vercel.json, copy the content into config and then make it dynamic.

Production checklist (deployment)

• Run review and E2E on the preview URL before merging
• Put a type/lint/test quality gate in CI, and don't ship if it doesn't pass
• Rebuild-free promotion with --prebuilt, eliminating build differences
• CI auth is OIDC keyless, VERCEL_TOKEN scoped minimally + rotated
• Stage-deliver important releases with Rolling Releases
• Always use Skew Protection with Rolling Releases
• Share the Instant Rollback procedure with the team (anyone can revert instantly)
• Unify configuration to one of vercel.ts/vercel.json

Conclusion

Vercel deployment operation is a design that stacks four safety valves on the foundation of immutable deployments.

1. Preview to catch it before shipping
2. Promote to promote the artifact as-is
3. Instant Rollback to revert in an instant even after shipping
4. Rolling Releases + Skew Protection to widen gradually and consistently
5. CI/CD safely and fast with --prebuilt + OIDC keyless

Next, go to the Firewall, WAF, BotID guide, which protects the entrance of the production you shipped.

This article is based on the official documentation of Rolling Releases / Instant Rollback / Vercel CLI (as of June 2026). The spec gets updated, so confirm the latest values in the official docs when adopting in production.