Billing

Each organization has a shared credit balance, funded by any member via Stripe Checkout (test mode for now — this is a demo integration). Every top-up attempt is recorded as a row in the organization's transaction ledger, whether it succeeds, fails, or is still pending.

Viewing billing

Click the Billing pill on an organization's page to see its balance and transaction history. Any member — owner, admin, or plain member — can view and top up; it isn't restricted to owners/admins the way some other org settings are.

The balance is the sum of everything in the ledger below — money in and money out — and is never a stored figure.

Usage this month

Under the balance is what the organization's applications have actually run this calendar month, in container-hours. It is counted per container, not per service: three replicas running for half an hour each are an hour and a half, not half an hour.

The rates themselves are still placeholders — /pricing says so on the page — but the meter is real and it is what the hourly charge below is computed from.

If a container was seen starting but never seen stopping — and the platform can no longer confirm it is running — it can't be counted honestly, so it isn't. The card says so in amber and the number is a floor rather than a total.

Containers the platform put in the stack are not counted either. Binding a managed database makes the deployer write a small proxy alongside the organization's own services — it is how the platform reaches the database rather than something the organization asked for, so it never reaches the meter, and neither does the shared engine behind it. That is deliberate rather than an oversight: billing the proxy would make the same database cost more the more applications bound to it, and the engine's cost belongs in the database rate rather than on a compute line. The containers are still shown on the application's own page, because they are really running; they just do not appear here.

What spends the balance

Once an hour, each organization is charged for what it ran — and, if it owns a managed database or bucket, what that stored and how much it was used — as Usage rows in the ledger below: one for compute, one for a managed service's storage, one for its engine load, each independent of the others. Three rules are worth knowing:

Running out

A zero or negative balance refuses the next deploy immediately, and puts everything already running on a clock. The refusal is instant, and it says both halves — the balance, what is about to happen to what is already running, and a link to this page:

bundle upload failed: Deploying is paused: Acme has a credit balance of $0.00.
Anything already running is now scheduled to be torn down, after a grace period
as long as it has been up and capped at seven days. Top up at
https://someones.computer/organizations/…/billing to call that off and deploy
again.

Nothing is stopped at the moment the balance crosses zero. What happens at that moment is that a teardown is scheduled for each running application, with a grace period of however long that application has been up, capped at seven days. Top up before the deadline and the teardown is cancelled on the next check, with nothing having been touched; leave it, and the stack comes down.

You are told, without having to run a deploy to find out. A Teardown scheduled notification arrives when the clock starts, Teardown cancelled when a top-up calls it off — one per application, naming each — and Application torn down if it runs out instead. See Notifications. Before those, the refusal above was the only warning, and it only reaches whoever happens to deploy next; the cancellation in particular had nothing at all behind it, so the deadline you were given simply stopped being mentioned.

Lifecycles has the whole of that — what the grace period works out to, what a teardown actually removes, and how to put the application back afterwards.

A managed database or bucket gets no grace period at all, and does not need one. A zero balance suspends every managed service the organization owns immediately — logins refused, data untouched. That is the whole difference: a suspension is one reversible statement and the data survives it exactly as it was, so there is nothing for a delay to protect, where an application coming down is not reversible in the same way. See Managed databases.

Top up and everything reverses — the next deploy goes through, and any service this suspended for the same reason resumes on its own. There is nothing else to reset.

New accounts get $5

An account is granted $5 of credit once, when a platform operator approves it — the Trial tier on /pricing. It lands on the personal organization created with the account, and it is once per account, not per organization: a second organization you create starts at zero, and an approval switched off and on again does not grant it twice. The row shows in the ledger as a Grant.

Topping up

Choose one of the three fixed amounts ($5/$10/$20), or enter a custom amount between $1 and $500 and click Add. Either one creates a pending transaction and redirects you to Stripe Checkout to complete payment; Stripe's webhook then flips it to succeeded (or failed, if the Checkout session expires unpaid).

Amounts outside the $1–$500 range are rejected before anything is created:

Transaction history

Every movement stays in the ledger, newest first, money in and money out in one list — the balance above is the plain sum of it. The Kind column says which is which:

Every top-up attempt — successful, failed, or still pending — stays in the ledger. Only succeeded rows count towards the balance; grants and usage charges are succeeded from the moment they are written, since neither is waiting on anything.

For operators: a Stripe refund does not adjust the balance. The platform subscribes to checkout.session.completed and checkout.session.expired and nothing else, so a refund issued from the Stripe dashboard never reaches this ledger — the credit stays spendable and the balance shown here is then wrong by the refunded amount. This is deliberate: there is no refund path, and money going back out is handled outside the platform. If you issue one, correct the ledger by hand.