Credit, hours and budget

Hourly rental is paid from prepaid credit. You top up, you order, and each hour started is charged the moment it begins. Everything else follows from that sentence.

Prepaid credit

There is no month-end invoice, no payment method to chase, no debt possible: the hour is paid at its start, and an hour is only opened if it can be paid. Your balance can therefore never go negative.

The counterpart is that a machine stops when the credit runs out. It does not vanish for all that. See below.

Credit can also come from a credit code (a gift card, a welcome campaign), entered on the Credits page of the console. That gifted credit is spent first, before purchased credit, and may carry a use-by date: GET /v1/account tells credit.paid, credit.gifted and credit.gifted_expires_at apart, their sum being credit.balance. It also pays for orders and renewals settled from credit. It can be neither refunded nor withdrawn.

An hour started is owed

A machine created at 14:05 and destroyed at 14:20 costs one hour. It is the simplest rule to hold on both sides: no refunds prorated to the second, and the cost of a script stays predictable.

The meter starts at the minute of creation, not on the round hour. The hour-by-hour ledger is readable on GET /v1/usage: one line per hour charged, with its rate and amount.

Where the hourly price comes from

It derives from the monthly price: ×1.5 over 730 hours, rounded up to the thousandth. The premium pays for flexibility: running for three hours costs more, per day, than committing to a month.

For the Nano at 8.50 CAD a month that gives 0.018 CAD an hour, or 13.14 CAD if the machine stays on for a whole month. Both figures are in GET /v1/plans, as hourly and hourly_month_equivalent: the second is the one to compare with the monthly price.

The 24-hour advance

An hourly order is accepted only if the balance covers the first 24 hours. Without that floor we would be delivering machines that stop within the hour, which helps nobody.

dry_run gives you the exact amount before committing to anything, and a refusal answers 402 insufficient_credit with what is missing, to the cent.

Runway and budget

GET /v1/account returns three numbers that are enough to drive a fleet: the balance, the combined hourly burn of running machines (burn_rate) and how long that lasts (runway_hours).

A monthly budget can be set in the console. It warns at 50, 80 and 100 % of spend; past 120 %, machines are stopped. With no budget set, nothing cuts: we do not stop someone who asked for nothing.

It can also be set through the API, with a key that carries billing.write: PUT /v1/account/budget with {"monthly": "250.00"}, or {"monthly": null} to remove it. The response is the budget block of GET /v1/account; replaying the same request changes nothing, so a tool can reapply its configuration on every run.

What stops a machine

Credit exhausted: the machine is stopped and its disk is kept for seven days, free of charge. Top up within that window and it restarts where it left off, with no retroactive billing for the time spent off. After the window, the machine and its disk are deleted.

The state is on the machine, in the suspension block: the reason (credit, budget, bandwidth, admin) and the end of the grace period. A suspended machine can be read but no longer obeys: any action answers 409 service_suspended.

Monthly mode

An order with billing: monthly raises an invoice, and the machine is built only once it is paid. With payment: credit it is settled from your balance when that balance covers the total: in full or not at all. We do not half-empty a credit for a machine that will not ship.

Deleting a monthly machine files a cancellation: at the end of the paid period by default, at once with ?when=now. Neither is refunded.

Traffic

Every machine includes 1 TB of traffic a month, by the hour, the month or the year: its traffic with the Internet, inbound and outbound added together. Traffic carried by a private network, between machines or with your managed databases, is never counted; what a load balancer serves to the Internet counts on its target machines. The network card sits on a shared 1 Gbps port: a burst speed, not a reserved one.

A monthly or yearly machine's traffic month follows its due date; an hourly machine's, the day it was created. GET /vms/{id} shows where it stands:

"traffic": { "used_gb": 212.4, "limit_gb": 1000, "percent": 21.2, "overage_rate": "2.00",
             "period_ends_at": "2026-11-05T04:00:00Z" }

Beyond the allowance nothing is cut off or slowed down. At the end of the traffic month (period_ends_at) the overage is billed pro rata, 2 CAD per TB, from your credit if it covers it, otherwise by an invoice that waits; the counter restarts from zero. Deleting a machine settles the overage of the month in progress. An email warns at 50, 80, 90 and 100 percent.