The hard spending limit: why we cap instead of billing you more

Nearly every hosting platform lets you set a budget. Almost none of them let that budget bind them.

Read the documentation carefully and you find the sentence. Vercel's is the clearest: "Setting a spend amount does not automatically stop usage." The check runs every few minutes; pausing happens after the fact, only on Pro, only if you turned it on, and seats and marketplace add-ons fall outside it entirely.

That is not dishonest. It is what a budget alarm is. It is just not what most people think they bought.

The mechanical difference

The difference is not the size of the number. It is when the check happens.

A budget alarm samples your accrued spend on an interval and reacts. By the time it fires, the spend already happened, so the only question left is who pays for it. The answer is you.

A hard limit checks before the spend. Every minute a job prices what ran in the previous minute and books it against your ceiling. Before anything expensive begins — a build, a new database, an extra replica, a bigger instance — the platform reserves the credits it expects to consume and refuses the operation if the reservation does not fit.

remaining = cap − used − reserved

if remaining < 0:
    the operation does not start

Three lines, and they are the product. A reservation that fails simply does not let the expensive thing happen, so there is no invoice to argue about afterwards.

Why we can afford this and a reseller cannot

This is the part that decides whether you believe the rest.

A platform that buys capacity from a hyperscaler pays per gigabyte transferred, per gigabyte stored and per CPU second. Their cost curve tracks your usage almost exactly. Passing that through is their margin. For them, a ceiling is not stubbornness — it is a loss they eat, on purpose, forever.

Our costs are mostly fixed. We own the machines and depreciate them over years. The rack space is a monthly amount. The transit is committed rather than metered per gigabyte. A customer who hits their ceiling costs us capacity we already paid for, not a purchase invoice.

That is the whole trick, and it is not clever. It is a different balance sheet. It is also why we can write the sentence without an asterisk, and why a platform built on rented capacity cannot copy it in a sprint without damaging its own model.

What happens when you hit it

Your apps pause. Visitors get an error page from the edge — not a dropped connection.

Then the list of things that do not happen, which is the part people actually worry about:

• Your data is not deleted. Not the database, not the volumes, not the object storage.
• Your backups keep the snapshots they already have.
• Your domains keep resolving and your certificates keep renewing.
• Your environment variables and secrets are untouched.
• No invoice follows. Not that month, not later, not as a back-charge.

At the new billing period everything starts again by itself. If you would rather not wait, raise the limit and the workloads come back within seconds.

You can raise it whenever you like. An AI assistant cannot, no matter how the request is phrased — that is one of five operations with no scope, no profile and no tool behind it.

The two things outside the ceiling

We would rather list these plainly than have you find them.

Domain registrations and renewals. A registry charges us at the moment of purchase and the name is yours for a year. If domains were inside the limit, a paused workload could cost you a domain name, which is a worse outcome than a separate charge. They are billed on a card, at cost plus a fixed 25% margin, with the renewal price shown before you confirm.

VAT. The ceiling is on the amount excluding VAT. VAT is added according to your tax status, because we do not get to decide that.

Everything metered — compute, memory, storage, databases, backups, builds, requests — is under the ceiling.

"Can you make an exception, just once?"

No, and the reason is worth stating.

The moment we grant one exception, the promise becomes a policy with discretion in it. A policy with discretion is exactly the thing this product exists to replace, because you cannot plan around discretion and you certainly cannot plan around someone else's.

Raise your limit instead. It takes seconds and it is entirely yours to do.

Where the competition actually stands

Railway has a real hard limit — minimum $10, and hitting it takes workloads offline, which they themselves describe as a possibly destructive action. Netlify's prepaid credit model effectively caps you as long as auto-recharge is off. Neither of those is nothing, and we would rather say so here than have a stranger say it for us in a thread.

The rest — Render, Fly, DigitalOcean, Cloudflare — bill the overage. Cloudflare caps CPU time per invocation, which bounds a runaway function but not an invoice.

The comparison table has all of it, including the places where they beat us.