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 and leaves every application already running exactly where it is. Nothing is stopped, scaled down or torn down for want of credit — the only thing that changes is that the next sc deploy is refused, with the balance and a link back to this page:

bundle upload failed: Deploying is paused: Acme has a credit balance of $0.00.
Anything already running stays up. Top up at
https://someones.computer/organizations/…/billing to deploy again.

A managed database or bucket is the one exception. A zero balance suspends every managed service the organization owns immediately — logins refused, data untouched — the same reversible action the service's own Suspend button takes. It is not a grace period the way the deploy refusal is not a teardown: the difference is that a database's data survives suspension exactly as it was, so there is nothing a delay would protect.

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.