Skip to content

Pod Sizes

Watasu offers fixed-price pods for sustained workloads and usage-billed Dynamic pods for uneven ones. Pod size is selected per process type, so one app can mix both models.

SizeCPUMemoryPrice per replica-monthNotes
hobbyup to 1 (0.25 guaranteed)1 GB€8Max 1 replica. Prototypes and small internal tools.
standard-1x12 GB€15Baseline small web and worker workloads.
standard-2x24 GB€30Medium web traffic and modest workers.
standard-4x48 GB€60Heavy web or memory-bound workers.
standard-8x815 GB schedulable€120Large in-memory workloads and image processing.
standard-16x1630 GB schedulable€240Single-replica heavy lifters.
SizeHard CPU limitHard memory limitMaximum at continuous full use
dynamic-1x12 GiB€40/replica-month
dynamic-2x24 GiB€80/replica-month
dynamic-4x48 GiB€160/replica-month
dynamic-8x815 GiB€310/replica-month
dynamic-16x1630 GiB€620/replica-month

Dynamic pods stay running and reachable; they do not scale to zero between requests. Watasu samples and aggregates actual CPU time and memory working set for each process every minute. The rate is:

  • €20 per average vCPU-month
  • €10 per average GiB-month

The small scheduler request (0.01 vCPU and 0.01 GiB per replica) is not a billing minimum. Billing uses measured consumption. The selected size remains a Kubernetes hard limit and therefore an upper bound on the usage charge.

If a CPU or memory sample is absent, that component uses the selected size’s cap for the affected minute rather than creating an unmetered gap. Usage rows record whether they came from metrics or this conservative fallback.

Dynamic is intentionally more expensive than Standard at continuous full use. Choose Standard for steady workloads and Dynamic when idle time dominates. For example, a dynamic-1x process averaging 0.05 vCPU and 0.2 GiB has an approximate €3/month run rate while retaining room to burst to 1 vCPU and 2 GiB.

The dashboard shows current per-size pricing. Use watasu pods --app <app> to see what your processes are running on right now.

Terminal window
watasu pods:type web=standard-2x worker=dynamic-1x --app my-app

Each process type gets its own size — they’re independent.

Two questions decide which lever to pull:

“Is one process running out of CPU or memory?” → Scale up (bigger pod). Indicators:

  • OOMKilled events
  • one process pegged at high CPU while others are idle
  • a single hot path that won’t parallelize

“Are concurrent requests piling up?” → Scale out (more replicas). Indicators:

  • request queue depth growing
  • response time degrading at high load even though no single request is slow
  • needing redundancy for HA

You can do both. A common production formation:

Terminal window
watasu pods:scale web=3 worker=2 --app my-app
watasu pods:type web=standard-2x worker=standard-1x --app my-app

Remember hobby is capped at one replica. Both standard-* and dynamic-* process types can scale out.

If a pods:scale or pods:type command is refused, the dashboard tells you which limit you’ve hit and what to do about it. See Billing and Limits.