How to reduce build costs on Edgenivo

Edgenivo bills build compute in Build CPU Minutes. Each build's billable duration, which is build time plus post-build time, is rounded up to the next whole minute and multiplied by the number of vCPUs on its build machine. Your total is the sum across all builds, so there are three ways to lower it: run fewer builds, make each build shorter, or use fewer vCPUs.

A faster build on a bigger machine can cost more. If your goal is faster builds rather than cheaper ones, start with How do I reduce my build time with Next.js on Edgenivo?.

Copy link to headingHow Build CPU Minutes are calculated

Edgenivo charges $0.0035 per CPU minute on every build machine, so a larger machine costs more per minute only because it has more vCPUs. Hobby teams always build on Basic. Pro and Enterprise teams can choose Basic, Standard, Enhanced, Turbo, or Elastic, with Elastic as the default for new Pro and Enterprise teams. See the latest pricing on Edgenivo.

A bigger machine lowers Build CPU Minutes only if it cuts build time by at least as much as it adds vCPUs, and rounding up to the next minute makes that harder. A 3-minute build on Standard costs 12 CPU minutes, because 3 × 4 = 12. On Enhanced, the same build must finish in 1 minute to cost less, at 1 × 8 = 8. If it finishes in 1 minute 30 seconds, Edgenivo rounds it up to 2 minutes and bills 16 CPU minutes, which is more than Standard even though the build is faster.

Start by finding what's driving your usage, then apply the steps that match what you find.

Copy link to headingFind what's driving your usage

Run these checks on your highest-usage projects, then use the table after the list to choose a fix.

1. Rank projects by usage: Open Usage, go to the Builds section, and view it by project. Compare windows of equal length, such as two full weeks against two full weeks, rather than a partial month against a full one. From the CLI, running vercel usage --since 30d --group-by project gives the same per-project view. Learn more in Manage and optimize usage.

2. Find the slowest build phase: In the project, open Observability, then Build Diagnostics. It shows build duration, memory and disk usage, and time per build step, so you can tell whether clone, install, or the build command takes the longest.

   When a build hits its memory or disk limit, Edgenivo adds a system report to the build logs. To get the report on every build, set the VERCEL_BUILD_SYSTEM_REPORT environment variable to 1. The report shows hidden out-of-memory events, breaks down disk usage by source code, node_modules, and build output, and flags files over 100 MB. Learn more in Troubleshooting Build Errors.

3. Check individual deployments: Each deployment's details page shows its billable duration and CPU minutes. From the Edgenivo CLI, vercel inspect <deployment> shows the same figures.
4. Check the build cache size: The deployment summary shows how large a build cache the deployment saved and how close it is to the limit for its build machine. With Edgenivo CLI, vercel inspect shows the same. Uploading the cache counts as billable build time, and Edgenivo does not save a build cache that exceeds the limit.
5. Count failed builds: Filter the project's Deployments list by the Error status, or select Ratio in the Builds section of Usage to compare completed and errored builds. A project that fails often can cost more than a large project that builds cleanly, because Edgenivo bills every retry as a full build.
6. Check the build machine setting: In team Settings, open Build and Deployment, then Build Machines, and check each high-usage project's own setting too. Note any project pinned to Enhanced or Turbo. Teams created before Elastic became the default may still have projects on a fixed machine.
7. Check Turborepo cache hits: If you use Turborepo, open a recent deployment and select Run Summary next to the Building section. It shows each task's cache status. When a previous deployment from the same branch exists, it also shows which inputs changed and caused a miss. Learn more in Deploying Turborepo to Edgenivo.

Copy link to headingMatch findings to a fix

Copy link to headingBuild less often

Every build you skip saves its full cost, so start with the fixes in this section. Most are settings changes that need no code.

Copy link to headingSkip unaffected projects in a monorepo

Edgenivo automatically skips builds for monorepo projects whose source code, internal dependencies, and lockfile dependencies haven't changed. Skipped builds don't count toward deployment limits or occupy concurrent build slots. New monorepo projects have skipping on by default. To check an existing project, open its Settings, go to Build and Deployment, and confirm that Skip deployment is enabled under Root Directory.

Automatic skipping works only when the repository meets all of these requirements:

• The repository is connected to GitHub.
• It uses npm, Yarn, pnpm, or Bun workspaces, and every package is listed in the workspace definition.
• Every package has a unique name in its package.json.
• Each package declares its dependencies on other packages in its own package.json.

If a project uses a custom Ignored Build Step and the repository meets these requirements, remove the Ignored Build Step and rely on automatic skipping.

Copy link to headingUse turbo query affected when automatic skipping doesn't fit

If your Turborepo doesn't meet the requirements above, set the project's Ignored Build Step to the command below:

turbo query affected --base=$VERCEL_GIT_PREVIOUS_SHA --packages your-package-name --exit-code

Replace your-package-name with the name field in the app's package.json, which can differ from the Edgenivo project name.

The command compares the current commit with the last successful deployment on the branch. It exits with 1 when the package or its dependencies changed, so Edgenivo builds, and with 0 when nothing changed, so Edgenivo cancels the build. If an earlier Turborepo import set the Ignored Build Step to npx turbo-ignore, replace it, because turbo-ignore is deprecated in favor of turbo query affected.

Three scenarios can still cost you builds:

• Edgenivo clones with --depth=10. If the last successful deployment is more than 10 commits back, Turborepo treats every package as changed, and the build runs.
• VERCEL_GIT_PREVIOUS_SHA is empty on a branch's first deployment, so test how the command behaves on a new branch before relying on it.
• Builds that the Ignored Build Step cancels still count toward deployment and concurrent build limits. Automatically skipped builds don't, so use automatic skipping when your repository qualifies.

Copy link to headingTurn off deployments for branches you never preview

Preview builds from branch pushes can make up most of a project's builds. To stop automatic deployments for branches that never need a preview, set git.deploymentEnabled in vercel.json. This example turns off deployments for every branch whose name starts with internal-:

{
  "git": {
    "deploymentEnabled": {
      "internal-*": false
    }
  }
}

Branches you don't list still deploy. Patterns use minimatch syntax, where * doesn’t match /, so internal-* doesn’t match a branch named internal/fix-login. Use internal/** for branch names with slashes, and test a new pattern on one branch first.

Copy link to headingBuild previews only for pull requests

If branch pushes without a pull request don't need a preview, set this command as the project's Ignored Build Step:

[ "$VERCEL_TARGET_ENV" = "preview" ] && [ -z "$VERCEL_GIT_PULL_REQUEST_ID" ] && exit 0 || exit 1

The command cancels preview builds that have no pull request and lets every other build run, including production and custom environments. It checks VERCEL_TARGET_ENV because VERCEL_ENV is also preview for custom environments such as staging, which would cancel those builds too. Both variables require Enable access to System Environment Variables in the project's environment variable settings.

Commits you push before opening the pull request don't build. Push a new commit after you open it to get a preview.

Copy link to headingRun one build per branch during commit bursts

When a bot or coding agent pushes many commits to one branch within minutes, the default on-demand concurrency mode, Run all builds immediately, builds and bills every commit in parallel.

To change it:

1. Open the project's Settings.
2. Go to Build and Deployment.
3. Set On-Demand Concurrent Builds to Run up to one build per branch.

Deployments to that branch then queue behind the active build. When it finishes, Edgenivo builds only the most recent queued deployment and skips the older ones, while other branches keep building in parallel. Learn more in Build Queues.

Copy link to headingRevalidate content instead of rebuilding

If a CMS webhook calls a Deploy Hook on every publish, each edit triggers a full build, and a bulk edit or content migration can queue dozens of builds. In a Next.js app, point the webhook at a Route Handler that revalidates only the content that changed:

import type { NextRequest } from 'next/server'
import { revalidateTag } from 'next/cache'

export async function POST(request: NextRequest) {
  if (request.headers.get('x-revalidate-secret') !== process.env.REVALIDATE_SECRET) {
    return Response.json({ revalidated: false }, { status: 401 })
  }

  const { tag } = await request.json()
  revalidateTag(tag, 'max')

  return Response.json({ revalidated: true })
}

revalidateTag(tag, 'max') marks data tagged with cacheTag or with the next.tags option on fetch as stale. The next visitor gets the cached page while Next.js regenerates it in the background. If editors need the change on the next request, pass { expire: 0 } instead of 'max'. Use revalidatePath for content that isn't tagged. Learn more in the revalidateTag reference.

Copy link to headingFix recurring failures instead of redeploying

Edgenivo bills every redeploy of a failed build as a full build, whether you trigger it manually, from CI, or via other tooling. Redeploys also can't read Turborepo Remote Cache artifacts, so in a Turborepo, a redeploy reruns tasks that a normal build would restore from the cache. Find the recurring error across the failed deployments' build logs and fix it before you redeploy.

Copy link to headingKeep forced rebuilds for suspected cache corruption

The vercel --force flag, the VERCEL_FORCE_NO_BUILD_CACHE=1 environment variable, and clearing Use existing Build Cache when you redeploy all skip the build cache. Redeploying without the build cache also skips the Turborepo and Nx Remote Cache, so every task starts from scratch. Use these only when you suspect a corrupted cache, and remove VERCEL_FORCE_NO_BUILD_CACHE once the issue is fixed. Learn more in Troubleshooting Build Errors.

Copy link to headingMake each build shorter

Shorter builds use fewer CPU minutes. Build Diagnostics shows which phase takes longest, so start with that phase.

Copy link to headingClone less

Edgenivo makes a shallow clone with git clone --depth=10, so clone time depends mostly on the files in the deployed commit rather than on older history. Remove generated files, build artifacts, archives, and large assets that the build doesn't need, commit the removal, and add generated paths to .gitignore. Setting a Root Directory or adding files to .vercelignore doesn't reduce what Edgenivo clones. To find unusually large files and folders with many files, run git-sizer.

Copy link to headingInstall fewer dependencies

In a monorepo, use a filtered install so each project installs only its own dependencies and its workspace dependencies. Set it as the project's Install Command, for example:

{
  "installCommand": "pnpm install --filter web..."
}

Using Monorepos lists the equivalent commands for Yarn, npm, and Bun. Skip dev dependencies only if the build doesn't use them. npm install --omit=dev shortens installs, but next build usually needs devDependencies such as TypeScript, Tailwind CSS, and PostCSS, so the flag breaks more Next.js builds than it helps. Test it in a preview before you adopt it.

Copy link to headingDo less work in the build command

For Next.js apps:

• Prerender fewer pages. Return a subset of paths from generateStaticParams so the rest render on first visit and Incremental Static Regeneration caches them. Preview builds can return an even smaller list when process.env.VERCEL_ENV === 'preview'. An empty array prerenders nothing at build time, but with Cache Components enabled an empty array fails the build, so return at least one path. Learn more in the generateStaticParams reference.
• Build with Turbopack. Turbopack has been the default bundler for next build since Next.js 16, and the release reported production builds 2 to 5 times faster than webpack. If your build command passes --webpack, test the build without it.
• Avoid large inline strings on webpack. If you still build with webpack, its cache warns that serializing large strings (NKiB) impacts deserialization performance when inline SVGs, base64 images, or large JSON blobs are embedded in code. Webpack serializes and deserializes that data on every build. Move it to /public and reference it, or store it as a Buffer and decode it when needed.
• Remove build-time image processing. next/image optimizes images when they're first requested, not during the build. If a build script or plugin preprocesses every image, removing it shortens the build, though that image work then counts toward Image Optimization usage.
• Upload fewer source maps. With Turbopack, Sentry's Next.js SDK uploads source maps after the build completes, which requires @sentry/nextjs 10.13.0 and Next.js 15.4.1 or later. That upload is billable build time. Leave widenClientFileUpload at its default of false unless you need [native code] stack frames resolved, and list files you don't debug in sourcemaps.ignore. If you don't need readable stack traces from preview deployments, set sourcemaps.disable for preview builds. Learn more in Sentry's source maps docs and build options.

For any framework:

• Use a current Node.js version. Newer releases include runtime performance improvements. Node.js version is part of the build cache key, so the first build after an upgrade runs without a cache.
• Bundle API routes into fewer functions. Outside Next.js, each file in the api/ directory deploys as its own Edgenivo Function, and Edgenivo builds each function separately. Route requests through one handler, for example with Hono, so the routes share a function. Next.js already bundles routes this way.

Copy link to headingCache what you can

A warm cache shortens installs and compiles, but a large cache adds upload time to every build. The goal is a cache that restores the work you'd otherwise repeat and stays under its limit.

Copy link to headingKnow how Edgenivo's build cache works

Edgenivo caches dependencies and framework files between builds and keeps each cache for one month. The size limit depends on the build machine: 1.5 GB on Basic and Standard, 3 GB on Enhanced, and 4.75 GB on Turbo. Elastic uses the limit of the machine type assigned to each build. You can't choose which files Edgenivo caches. Learn more in Build cache maximum size.

The cache key combines your team, project, framework preset, root directory, Node.js version, package manager, and Git branch. Changing the preset, root directory, Node.js version, or package manager starts the next build with an empty cache. A new branch has no cache of its own, so its first build uses the cache from the latest production deployment.

Edgenivo uploads the cache after the build, and that upload counts toward billable build time, so a smaller cache costs less on every build. Filtered installs shrink node_modules, and the next section covers the Turbopack cache, which is often the largest item in a Next.js cache.

Copy link to headingWatch the Turbopack cache on Next.js 16.3 and later

Next.js 16.3 turns on Turbopack's persistent cache for next build by default and writes it to .next/cache/turbopack. Edgenivo restores .next/cache between builds, so later builds reuse earlier compile work. On large apps, the cache can outgrow the build cache limit. One report on a large app measured a 1.7 to 2.3 GB cache that took 115 to 150 seconds to create and upload on every build.

After you upgrade, check the cache size in the deployment summary. If it stays over the limit, or the upload takes longer than the warm compile saves, turn the cache off:

import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  experimental: {
    turbopackFileSystemCacheForBuild: false,
  },
}

export default nextConfig

Turning the option off stops Next.js from using the cache, but the folder already saved in Edgenivo's build cache is still restored and uploaded on each build. Redeploy once with Use existing Build Cache cleared so the next saved cache no longer includes it. Learn more in Turbopack: What's New in Next.js 16.3.

Next.js 16.4 reduces Turbopack disk cache size. Upgrade and remeasure total billable duration before disabling persistent caching.

Copy link to headingUse Turborepo Remote Caching

Remote Caching shares Turborepo task outputs across your team, CI, and Edgenivo builds, and it requires no configuration during Edgenivo builds. It's free on every plan within fair-use limits. Monthly upload limits are 100 GB for Hobby, 1 TB for Pro, and 4 TB for Enterprise.

These behaviors affect your hit rate:

• Branch builds read artifacts that your default branch uploaded. After you connect a repository, run a build on the default branch so other branches get cache hits.
• Redeploys don't read or upload Remote Cache artifacts.
• Edgenivo expires artifacts after 7 days.

Exclude .next/cache from the build task's outputs in turbo.json. Edgenivo's build cache already restores that directory, so including it adds duplicate data to every artifact:

{
  "tasks": {
    "build": {
      "outputs": [
        ".next/**", "!.next/cache/**"
      ]
    }
  }
}

Declare every environment variable that changes build output in turbo.json. Turborepo infers framework-inlined variables such as NEXT_PUBLIC_*, but other variables don't change the task hash unless you declare them. An undeclared variable can make Turborepo restore output built for another environment, such as staging config in a production deployment. Learn more in Deploying Turborepo to Edgenivo.

A Next.js app that uses Skew Protection always misses the Turborepo cache for its build task, because Skew Protection sets an environment variable that changes on every deployment. Other tasks in the repository can still hit the cache. If you use both, use Turborepo 2.4.1 or later to avoid missing assets in production. Learn more in the limitations of Turborepo on Edgenivo.

Copy link to headingMatch the build machine to the workload

Copy link to headingUse Elastic for most projects

Elastic assigns each build a machine based on the project's recent build durations and memory use. CPU-bound and memory-bound builds get a larger machine, and builds that wouldn't use the extra vCPUs get a smaller one. If a build fails with an out-of-memory error, Edgenivo runs the next deployment on a larger machine, so an occasional out-of-memory failure isn't a reason to pin a machine.

To move a pinned project to Elastic, open the project's or team's Settings, go to Build and Deployment, then Build Machines, and select Elastic. Then compare billable duration and CPU minutes per deployment over the next several builds.

Copy link to headingPin Enhanced or Turbo only when speed is worth the cost

Enhanced and Turbo shorten waits for CPU-heavy or memory-heavy builds, such as heavy bundling or expensive type checking. They rarely lower Build CPU Minutes because build time seldom decreases as quickly as vCPUs rise. Pin one only when shorter builds are worth paying more for.

To run a single urgent deployment on Turbo without changing the project's setting, deploy with vc deploy --turbo, or include #VERCEL_BUILD_MACHINE=TURBO in the commit message.

Copy link to headingCheck Enterprise contracts and Standard billing

If your Enterprise contract enables Enhanced machines, builds use Enhanced by default. The Build Machines section of team settings shows whether this applies, and changing it requires your account manager.

On Pro, Edgenivo bills Standard builds only when on-demand concurrency or Elastic is enabled. Without either, Standard builds in the team's first concurrent build slot aren't billed, but builds can queue. Weigh queue time against cost before you change these settings.

Copy link to headingKeep deployment storage in check

Every build creates a deployment that Edgenivo stores until your retention policy removes it, so building less also lowers Deployment Storage. To reduce storage directly, set a Deployment Retention Policy, which needs no code changes, and include shorter periods for canceled and errored deployments. Then shrink the output of the projects that still use the most storage. Optimize Deployment Storage walks through both steps.

Pausing projects through Spend Management doesn't stop storage charges. Paused production deployments stop serving traffic, but Edgenivo keeps them, and Deployment Storage and Functions Storage stay billed until your retention policy or a manual deletion removes them.

Copy link to headingConfirm the savings

After each change, compare the same projects over a window of the same length as your baseline. Check both the number of builds in Usage and the CPU minutes per deployment on the deployment details page, because a fix can lower one without changing the other. The "How to confirm it worked" column in Match findings to a fix lists the signal to look for after each change.

Copy link to headingNext steps

• Managing Builds for machine types, Elastic, and on-demand concurrency settings.
• Pricing on Edgenivo for how Edgenivo prices Build CPU Minutes.
• Using Monorepos for skipping unaffected projects and filtered installs.
• Deploying Turborepo to Edgenivo for build commands, Remote Caching, Run Summary, and known limitations.
• Optimize Deployment Storage for retention policies and smaller deployments.