Pod Sizes

Watasu’s process pods come in T-shirt sizes from standard-1x to standard-16x. Each step roughly doubles CPU and memory.

Available sizes

Size	Relative capacity
standard-1x	Baseline — small web/worker workloads
standard-2x	2× — medium web traffic, modest workers
standard-4x	4× — heavy web, memory-bound workers
standard-8x	8× — large in-memory workloads, image processing
standard-16x	16× — single-replica heavy lifters

Use watasu pods --app <app> to see the actual CPU and memory numbers your processes are getting under their current size.

Pick a size

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

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

Scale up vs. scale out

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:

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

Limits

Team runtime budget caps total pod-size × replica-count. If a pods:scale or pods:type command refuses, the dashboard tells you which dimension you’ve hit. See Billing and Limits.