[← Blog](https://watasu.io/blog) August 7, 2026

# Your quiet apps can finally be quiet on the bill

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](https://watasu.io/pricing#pods). 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.

<!-- Prev / next post navigation -->