How billing works
Pay only for what your namespace really uses, priced by the hour, settled once a day, paid over lightning.
On-demand: you pay for use, not for reservations
Every namespace on the cluster is metered from the same Prometheus data the operator uses. Nothing is billed per pod, per replica, or per request. If your deployment sits idle, its CPU cost is near zero; if it spikes for an hour, that hour costs more. Memory is charged on the working set actually held, not on the limit you set. Disk is charged on bytes present, not on the size of the claim.
| Meter | Price | What it measures |
|---|---|---|
| CPU | … | CPU time your containers actually consumed, sampled every minute. One core busy for an hour = 1 core-hour; idle pods cost almost nothing. |
| Memory | … | Working-set memory actually resident, sampled every minute. 2 GiB held for an hour = 2 GiB-hours. Requests and limits do not matter, only what is used. |
| Disk used | … | Bytes really written into your volumes, measured once an hour. A 10 GiB claim holding 1 GiB of data costs 1 GiB-hour per hour. |
| Disk reserved | … | The capacity your PersistentVolumeClaims ask for. Shown for information; currently free. |
| Egress | … | Bytes your pods transmitted. Shown for information; bandwidth is included, currently free. |
For scale: a pod using half a core and 1 GiB around the clock costs about … a month.
The daily rollup
Samples are summed per UTC day. Each day is priced with the table above and becomes one line in your ledger, written about two hours after midnight UTC once all the samples have landed. The dashboard shows the current day as provisional: it grows through the day and is only charged when the day is over.
If late samples arrive for a day that was already settled, only the difference is charged as a second line for that day. Usage is never refunded automatically; if a day was over-reported, the operator posts a manual adjustment.
Estimates on the dashboard
Month to date is the sum of the settled days this month plus the provisional current day. Projected month takes that amount, divides by the time observed so far this month, and scales it to the full calendar month, so early in the month it swings more than late in the month. Burn rate is the average of the last seven days, and days remaining is your balance divided by it. None of these estimates are charged; only settled days are.
Balance in dollars, payments in lightning
Your balance is kept in US dollars, because the prices are in dollars and your usage should cost the same whatever bitcoin does that week. Daily usage is deducted from it in dollars.
All payments are lightning payments. When you top up, you choose a dollar amount and the portal converts it to sats at the market price at that moment (spot price from mempool.space, Coinbase as fallback) and creates a lightning invoice for exactly that many sats. The invoice is valid for 24 hours. When it is paid, your balance is credited the dollar amount you chose, regardless of where the price moved in between. Pay $20 today and you have $20 of credit; the sats it took depended on the price the day you paid.
A balance can go negative. The dashboard then shows overdue; nothing is switched off automatically, so top up when you see it. Every top-up, daily charge, and adjustment is listed in your ledger with the running balance after it.
Where the numbers come from
CPU, memory, and egress come from the cluster's Prometheus (cAdvisor container metrics), collected every minute. Disk used comes from an hourly measurement of your volumes on the node. They are stored as metering events in OpenMeter, which is also where the operator's own dashboards read from, so what you see here is the same data the operator sees.
Sign in with nostr to see your namespace.