How One Team Cut $4,000/mo in Vercel Build Costs with OpenRelay Runners

The Problem: Vercel Build Minutes at Scale

Vercel charges for build minutes on every deploy. For small projects with a handful of pushes per week, this is negligible. But for teams shipping multiple times a day — running preview deploys on every PR, building on every merge to main — the minutes compound.

This particular team runs a Next.js production site with frequent deploys. Their Vercel invoice had climbed to roughly $4,000 per month in build-related costs — a line item that was easy to overlook until it wasn't.

The builds themselves weren't slow by Vercel standards. But Vercel's build infrastructure runs on shared, metered compute. Every second counts against your bill, and you don't control the hardware.

The Fix: Self-Hosted Runners on OpenRelay

The solution was straightforward: move builds off Vercel's infrastructure and onto a OpenRelay self-hosted GitHub runner. Instead of paying Vercel per build minute, the team runs their own runner that picks up GitHub Actions jobs, builds the Next.js app locally, and deploys the prebuilt output to Vercel.

Vercel still handles hosting and serving the site — that part doesn't change. The only thing that moves is where the build happens.

How It Works

The setup takes about 10 minutes. Here's what the team did:

The workflow looks something like this:

name: Production Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: [self-hosted, vectorlay-4gb]
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - run: npm install -g vercel

      - run: vercel pull --yes --environment=production
      - run: vercel build --prod
      - run: vercel deploy --prebuilt --prod

That's the entire workflow. The runner checks out the code, installs the Vercel CLI, builds the project, and pushes the prebuilt output to Vercel for serving. Environment variables are pulled directly from the Vercel project — no need to duplicate them in GitHub secrets.

The Results

The team reported zero issues from first setup to production deploy. In their words:

“Runner picked up queued jobs within seconds. Full build + deploy completes in under 2 minutes on the 4gb tier. Spins down when idle and comes back on demand — no wasted compute. Zero config on our end beyond the workflow label vectorlay-4gb.”

Why Build Minutes Get Expensive

Vercel's pricing is designed for convenience. You push code, Vercel builds and deploys — no infrastructure to manage. That convenience comes at a cost, and the cost scales linearly with how often you deploy.

Here's what Vercel actually charges for build execution on the Pro plan:

That last row is the one that catches people off guard. As of February 2026, Turbo is the default build machine for new Pro projects. That means new projects are billed at $0.126/min unless you explicitly change the setting — 9x the Standard rate.

The Pro plan includes a $20/month usage credit that covers build minutes alongside other resource consumption. Once that credit is exhausted, every minute is billed on-demand. For a team doing 30+ deploys a day on the Turbo tier, it adds up fast.

Common things that inflate the bill further:

• Preview deploys on every PR — each one triggers a full build
• Monorepos — builds often re-run even when unrelated packages change
• Large Next.js apps — ISR pages, image optimization, and route generation all add minutes
• Frequent merges — active teams can trigger dozens of builds per day
• Concurrent build slots — need more than 12 parallel builds? That's $50/month per additional slot

None of these are problems by themselves. But combined, they turn build minutes into a real line item.

Why This Works

OpenRelay's GitHub runner environments are purpose-built for this pattern. A few things make it work smoothly:

• On-demand scaling — runners spin up when a job is queued and spin down when idle. You're not paying for a server sitting around waiting for builds.
• Dedicated compute — unlike Vercel's shared build infrastructure, your runner has dedicated resources. Builds are consistently fast because you're not contending with other tenants.
• Standard GitHub Actions — no proprietary build system to learn. It's just a self-hosted runner label in your workflow YAML.
• Vercel stays for hosting — you keep Vercel's edge network, serverless functions, and CDN. Only the build step moves.

Should You Do This?

If you're spending less than a few hundred dollars a month on Vercel builds, the built-in build system is probably fine. The convenience is worth it at that scale.

But if your build minutes bill is climbing into the thousands — especially if you're on a team that ships frequently — moving builds to a self-hosted runner is a straightforward way to cut costs without changing your deployment workflow.

The migration is a single workflow file. You can test it on a branch before committing. And if it doesn't work for you, Vercel's auto-build is one toggle away.

Get Started

Set up a GitHub runner on OpenRelay in a few clicks. No credit card required to start.

1. Go to GitHub Runners in the OpenRelay dashboard
2. Create a runner environment and connect your repo
3. Add the workflow file to your repo with runs-on: [self-hosted, vectorlay-4gb]
4. Disable Vercel's auto-build
5. Push and watch it go