Billing and Limits
Watasu billing is prepaid: you top up a balance, and usage draws it down as it happens. There’s no end-of-month invoice surprise — what you can spend is bounded by what you’ve loaded.
How the balance works
Section titled “How the balance works”- Top up from the dashboard with a payment card. Card top-ups start at €5 and credit the selected personal or team balance after payment succeeds.
- Usage is metered continuously — app compute and add-ons are metered minute by minute, builds and sandboxes by running seconds — and charged against the balance.
- Auto top-up is optional. Enable it if you’d rather never think about the balance; leave it off if you want a hard ceiling on spend.
- Low-balance warnings arrive before anything is affected, so you have time to top up.
If the balance runs out, the team is suspended: deploys are blocked, running workloads are paused, and sandbox creation and commands are refused (stopping and destroying sandboxes still works, so you can always clean up). Topping up lifts the suspension.
Every charge is visible in the dashboard’s billing view, itemized per app, build, add-on, and sandbox, with a current-month running total.
Creating apps and add-ons
Section titled “Creating apps and add-ons”An unsuspended account with a zero balance can create an empty app. Creating or attaching any add-on requires a strictly positive balance, including free logs, metrics, and automatically provisioned Grafana. This also applies to add-ons selected during app creation, app.json provisioning, replacement restores, and followers. Use the personal owner’s balance for a personal workspace or the team’s balance for a shared workspace; no saved card is required. See Add-on balance requirements.
What you pay for
Section titled “What you pay for”| What it is | |
|---|---|
| App compute | Fixed plans charge per replica and provisioned time. Dynamic plans charge measured CPU and memory, with a €0.30 minimum per running replica-month and a size-specific ceiling. See Pod Sizes. |
| App builds | €0.50/hour by actual running seconds, with limits of 16 vCPU and 30 GiB RAM. Failed and canceled builds count. Queue time and image-only promotions have no build charge. |
| Add-ons | Each add-on plan has its own monthly price, metered per minute while provisioned. Higher tiers add capacity, durability, replication, and scheduled backups. |
| Sandboxes | The team’s Basic, Pro, or Enterprise plan, plus vCPU-seconds and GiB RAM-seconds while running and retained disks, checkpoints, and template storage. Pro is €150/month; usage is separate. |
| Observability | Logs, metrics, and traces have plan-tiered ingest, retention, and active series limits. |
App compute and add-on prices are listed per month for readability and prorated by usage time — destroy an add-on after a day and you’ve paid for a day. Sandbox Pro is a separate monthly team subscription; its cancellation and refund terms are described in Sandbox Billing.
App builds
Section titled “App builds”Every app build costs €0.50 per hour, billed by actual running seconds, with 16 vCPU and 30 GiB RAM limits. The rate applies to Dockerfile and Cloud Native Buildpacks builds triggered manually, by Git push, through the API or MCP, by GitHub auto-deploy, and by pipelines or review apps. There is no free monthly build allowance.
A six-minute build costs €0.05. Failed and canceled builds are charged for the seconds they ran. Waiting in the queue costs nothing. An image-only pipeline promotion reuses an existing image and has no build charge; the promoted app’s runtime and add-ons keep their normal pricing.
Available balance and temporary holds
Section titled “Available balance and temporary holds”The app’s billing account needs enough available balance for at least one running second before a build can start. For a personal workspace, this is the owner’s personal balance; for a team workspace, it is the team’s balance. A collaborator’s balance does not fund someone else’s app. You do not need a saved card or auto top-up when the correct account already has funds.
Before execution, Watasu reserves up to €0.50, enough for at most one hour. If less is available, it reserves the amount needed for a shorter funded deadline. Held funds cannot be spent by another build or transferred. The build stops at its funded deadline; topping up does not extend an already funded build.
After the build stops, its actual running time determines the final charge and unused funds return to the available balance. A hold is temporary, not an extra fee: a €0.50 hold followed by a six-minute build produces a €0.05 charge and a €0.45 return. Build details show the hold or final running time and cost; billing usage records the settled charge.
If a build is refused for insufficient balance, top up the account that owns the app and retry. Card top-ups have a €5 minimum. An account suspended for billing must also be restored before new builds can run.
Limits that shape usage
Section titled “Limits that shape usage”Depending on the area:
- builds — 16 vCPU and 30 GiB RAM limits, a funded deadline of at most one hour, and sufficient available balance
- runtime — max replicas per process, max pod size;
hobbypods cap at one replica - storage — database storage size, object storage size and egress allowance
- sandboxes — maximum sandbox TTL, CPU/memory/disk runtime limits, retained disk, checkpoint, and template storage
- monitoring — active metric series, log ingest rate, log retention window
- add-on connections — each database plan has a connection ceiling; size your pools to fit
When you hit a plan limit, the fix is almost always a plan upgrade, not a workaround. The plan catalog in Add-on Plans lists the ceilings per tier.
Plan choice is a workload decision
Section titled “Plan choice is a workload decision”Plans aren’t just a price tier. They shape:
- durability and replication
- scheduled backups vs. manual-only
- query and ingest performance
- retention windows
Pick based on what your workload actually needs. The cheapest plan that fits is the right one — but if you guess wrong upward (over-provisioned) you waste money, and if you guess wrong downward (under-provisioned) you wake up at 3am.
See Add-on Plans for the full plan catalog and Sandbox Billing for sandbox runtime and storage billing.
- match plans to workload, not to the price ladder
- keep staging on smaller plans than production
- review observability plans before a traffic surge — log ingest is a common surprise
- if you run automation that creates sandboxes, set timeouts and destroy on completion
- enable auto top-up for production teams; a paused app costs more than a top-up