Most applications are not busy in a straight line.
A webhook receiver waits, then handles forty requests at once. A worker sleeps between queues. Staging gets a workout before a release and spends the rest of the week being politely available. A review app may need a full CPU while it boots and almost nothing while it waits for somebody to open the link.
Fixed pods are wonderfully simple for steady work: pick a size, get the capacity, know the monthly price. But charging a quiet process for its busiest possible minute has never felt quite right.
So today we’re adding Dynamic pods: always-reachable app processes that bill the CPU and memory they actually use, with a hard ceiling you choose in advance.
Running, not scaled to zero
Dynamic does not mean your app disappears between requests. The process stays up, its routes stay live, and there is no cold-start queue in front of it. It simply carries a very small scheduler reservation while idle and can use resources up to its selected limit whenever work arrives.
Every minute, Watasu measures two things across the process’s replicas:
- CPU time, at €20 per average vCPU-month
- memory working set, at €10 per average GiB-month
That is the bill. Requested capacity is not usage, and the size of the pod is not the amount we pretend it consumed.
As a concrete example, a Dynamic 1× process averaging 0.05 vCPU and 0.2 GiB of memory runs at about €3/month. When a burst arrives, it can still reach 1 vCPU and 2 GiB immediately.
A ceiling you can read before you deploy
The same sizes form a simple ladder:
| Size | Hard limit per replica | Maximum at continuous full use |
|---|---|---|
| Dynamic 1× | 1 vCPU · 2 GiB | €40/mo |
| Dynamic 2× | 2 vCPU · 4 GiB | €80/mo |
| Dynamic 4× | 4 vCPU · 8 GiB | €160/mo |
| Dynamic 8× | 8 vCPU · 15 GiB schedulable | €310/mo |
| Dynamic 16× | 16 vCPU · 30 GiB schedulable | €620/mo |
Those are ceilings, not subscriptions. A Dynamic 1× replica cannot turn into a €90 surprise: Kubernetes cannot give it more than 1 vCPU or 2 GiB, so its usage bill cannot cross the size’s €40 ceiling.
Dynamic and Standard are both honest choices
Dynamic is intentionally more expensive at full utilisation. Standard 1× is €15/month; Dynamic 1× held at its full 1 vCPU and 2 GiB for the whole month reaches €40. If your process works hard all day, choose Standard and keep the difference. We are not trying to hide a fixed plan inside a complicated meter.
Dynamic wins when the idle hours dominate: webhook endpoints, background workers with uneven queues, admin processes, staging environments, demos, and review apps. You get room for the busy minute without renting that minute 24/7.
Each process type makes the choice independently. A production web process can stay on Standard while a sleepy worker uses Dynamic. Replicas still scale independently, and 2+ replicas still receive automatic multi-data-centre placement at no extra charge.
Review apps inherit the decision
Review apps inherit their parent app’s process sizes and cap each process at one replica. That means a Dynamic staging app naturally produces Dynamic review apps. If a pull request needs a different shape, app.json can say so explicitly:
{
"environments": {
"review": {
"formation": {
"web": { "quantity": 1, "size": "dynamic-1x" }
}
}
}
}The result is pleasantly boring: open a pull request, get a real app, leave it available for reviewers, and pay very little while nobody is looking at it.
Available now
Dynamic 1× through Dynamic 16× are in the pod-size selector today. Pick one for any web, worker, TCP, RTC, release, or app-script process; the dashboard shows the current spend and a forecast based on its recent billing minutes.
The full rate card and ceilings are on the pricing page. If you have a workload whose shape makes the choice non-obvious, write to us at info@watasu.io. Send us the boring graph with one enormous spike — those are our favourite ones now.