Build pipeline: build minutes, build machines and limits

Every deploy on Voroa starts with a build: your repository is fetched, your dependencies are installed, and your application is compiled or bundled. The time that takes is measured in build minutes, and each plan includes a monthly pool of them.

You can see your pool, your machine and your limit under Settings → Build Pipeline.

How build minutes are counted

Build minutes are counted from the real build-and-deploy time of your services. Two details are worth knowing before they surprise you:

• A build that fails still uses build minutes. The machine did the work up to the point the build stopped — it fetched your dependencies and started compiling — and that time is counted. We would rather tell you this here than have you find it in a number that does not add up.
• Preview-environment builds are not counted. Builds for pull-request previews do not come out of your pool.

From 1 November 2026, minutes are counted per workspace: each workspace gets the included minutes of its own plan, and one workspace using up its minutes does not stop builds in another. Until then, minutes are counted per account, across all of your workspaces. Either way they reset at the start of each monthly period.

Build machines

Your builds run on the machine included with your plan. There is nothing to buy separately.

A larger machine does not give you more minutes — it makes each build finish sooner, which usually means fewer minutes for the same work.

These are the real specifications of the machines that run your builds today. If you need more than this, tell us what you are building and how long it takes; capacity is something we would rather size against a real workload than guess at.

Performance builds

Some plans can also choose Performance builds. When your plan offers them, Settings → Build Pipeline shows two machines side by side, Starter and Performance, each with its price per 1,000 minutes.

How Performance builds work:

• 8 CPU and 16 GB of RAM for every build. When our build machine is free, the build starts on it straight away and has the whole machine to itself. When it is busy, the build runs on a dedicated machine of the same size, which is started for it and removed when the build is done.
• Paid by the minute, with no free minutes. Performance minutes are counted separately from your included build minutes and billed at the price shown on the page, plus GST, as their own line on your next invoice. Only build time is counted: the time spent waiting for the machine to start is not.
• You agree to the price first. Choosing Performance asks you to confirm the price before anything changes. If the price ever goes up, you keep paying the price you agreed to until you confirm the new one. Only a workspace owner or someone who manages billing can switch it on.
• It never stops your deploy. If a Performance machine is not ready in time, or you have reached your plan’s Performance ceiling or your own limit, the build runs on Starter instead and is counted as a Starter build, at the Starter price.
• A monthly Performance spend limit. You can set a rupee limit for Performance builds. Once you reach it, builds run on Starter for the rest of the month, and you are never billed above it.

Performance builds apply to services that build an image. Static sites keep building on Starter.

If the Performance card shows a lock, your current plan does not include it. The card links to the plans that do.

Setting a monthly limit

Under Settings → Build Pipeline you can set a monthly build-minute limit.

It does two things, and they are worth telling apart because only one of them is switched on today:

• It caps what you can be billed. You will never be charged for more minutes than your limit, whatever your usage does. This applies now.
• It stops builds at that number, when stopping builds is in force for your account. The page tells you which of the two applies to you, so you never have to guess.

This is a limit you set for yourself, and it can only ever be lower than your plan’s own ceiling — setting a number higher than what your plan allows has no effect. Leave it blank and your plan’s ceiling applies.

A limit is worth setting if you have automated deploys that could run away — a webhook loop, a busy branch, a scheduled job that redeploys — and you want a known ceiling on what that can cost you.

What happens when you run out

What happens depends on your plan.

Free plan. Builds stop when you reach your included minutes. Nothing extra is charged. To build again, upgrade to a paid plan or wait for your minutes to reset at the start of the next month.

Growth and Scale plans. Your builds continue past your included minutes, up to your plan’s ceiling and any monthly limit you set yourself (see above). Extra minutes are billed at the rate shown in your dashboard, plus GST. They are counted for the month they were used and added to your next invoice as their own line, naming the minutes and the month. Your plan fee is charged in advance; extra usage is always for the previous month.

A build you cancel is not counted. A build that fails still is, as explained above.

You can check your usage, and an estimate of what your extra minutes so far will cost, under Settings → Build Pipeline and Billing → Monthly Included Usage. Voroa also emails the workspace owner and admins once a month when the workspace has used 80% of its included minutes, and again when it has used all of them.

Making builds faster

The cheapest build minute is the one you do not spend:

• Commit your lockfile. Dependency installs are reused between builds when your lockfile has not changed, and a missing lockfile throws that away on every deploy.
• Use build filters, under your service’s Build & Deploy settings, so a change to a README does not trigger a full build.
• Keep the build command to what the deploy actually needs — running the full test suite in the build step doubles the minutes each deploy costs.

Related

• Usage and billing
• Build and start commands
• Deploy history and build logs