██FR█████ █INTELL███████████

Deploy your application on Vercel with GitHub Actions


This content originally appeared on DEV Community and was authored by OctoLab Team

A very common CI/CD pattern for frontend apps is: build in CI and deploy to production automatically when the code reaches main.
If you use Vercel, you can do this with a short and reliable GitHub Actions workflow that:

  • downloads your project’s configuration and variables from Vercel,
  • builds the app in CI,
  • and deploys the already built artifacts to production.

In this article, we’ll walk through it step by step and I’ll give you some tips to help you understand what each line does.

🎯 Purpose of the workflow

Every time there is a push to main, the following should be executed:

  • Pull config from Vercel (includes production environment variables).
  • Reproducible build in CI.
  • Deploy that artifact (without rebuilding in Vercel).

This will give you predictable deployments that are easy to audit and debug.

🧬 General workflow structure 

name: Vercel PRO deployment
on:
  push:
    branches:
      - main
jobs:
  deploy:
    name: deploy
    runs-on: ubuntu-latest
    steps:
      - id: checkout-step
        name: Checkout code
        uses: actions/checkout@v4
      - id: install-vercel-cli-step
        name: Install Vercel CLI
        run: npm install --global vercel@latest
      - id: pull-vercel-env-info-step
        name: Pull Vercel Environment Information
        run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN
          }}
      - id: build-vercel-artifacts-step
        name: Build Project Artifacts
        run: vercel build --prod --token=${{ secrets.VERCEL_TOKEN }}
      - id: deploy-vercel-artifacts-step
        name: Deploy Project Artifacts to Vercel
        run: vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}

💡 Prerequisites
Create the secret VERCEL_TOKEN in your repository (Settings → Secrets and variables → Actions).
Either commit .vercel/project.json, or provide VERCEL_ORG_ID and VERCEL_PROJECT_ID as secrets when you do vercel pull.

🪜 Step by step

on: push (to main)
Each push to main triggers the production pipeline. If you prefer to only deploy when merging by PR, simply avoid pushing directly to main.

uses: actions/checkout@v4
Download your code to the runner so that the following tools (Vercel CLI) have it available.

npm install –global vercel@latest
Install the Vercel CLI.

💡 Tip: to avoid surprises, you can set version: vercel@xx (or whatever you use on your team).

vercel pull –yes –environment=production
Bring the project configuration and production environment variables to .vercel/ on the runner.
In CI there are no interactive questions, so we use --yes.

You need:

  • .vercel/project.json in the repository or
  • VERCEL_ORG_ID and VERCEL_PROJECT_ID as variables/secrets.

vercel build –prod
Builds in CI using your framework (Next.js, SvelteKit, etc.) or what is defined in vercel.json.
The result is stored in .vercel/output and is exactly what you are going to deploy.

vercel deploy –prebuilt –prod
Uploads the already built artifact to production.
With --prebuilt, Vercel does not rebuild: what you tested in CI is what your user will see.

✅ Final result

With this workflow, each merge to main runs a clean build and deploys that same artifact to production in Vercel. You get:

  • reproducible builds,
  • faster deploys,
  • and clear CI logs for debugging.

🐙 Prefer to configure it visually?

Writing workflows by hand gives you total control, but sometimes you want speed with built-in validations.

With OctoLab, you can set up this same pipeline visually: choose actions, fill in fields, and the YAML is generated instantly, ready to commit.

👉 Try it out: https://www.octolab.app/templates/vercel-pro-deployment

🧵 Conclusion

This workflow provides you with a clean CI → production flow on every push to main, using Vercel’s recommended approach: pull → build → deploy. It’s easy to adapt to previews, monorepos, or strict reproducibility (fixed Node and CLI).

Use it as a base and evolve it with caching, notifications, or environment gates as your team grows.


This content originally appeared on DEV Community and was authored by OctoLab Team