Sizing a container is mostly a memory decision. CPU matters far less than most people expect, because a service that is waiting on a database or a network call is not consuming a core — it is blocked. Peak memory during a request is what actually terminates a container.
Start from what you are running
- Discord or WhatsApp bots — dominated by the runtime baseline plus your bot framework. A JavaScript bot on Node.js typically settles around 90–150 MB once running. Python sits higher, roughly 40–60 MB more, because the interpreter plus imported libraries are heavier than people expect.
- HTTP APIs and webhooks — add per-worker memory. Each additional worker process or thread multiplies the baseline, so concurrency is usually the first thing to reduce when memory is tight.
- Background workers and cron jobs — the baseline plus whatever the job holds in memory while running. If a job streams a large file or loads a whole result set, size for the peak, not the idle state.
- Databases you host yourself — MySQL and PostgreSQL need far more headroom than an application. Running a database inside the same container as your app is the single most common cause of out-of-memory restarts.
What the plans give you
| Plan | RAM | vCPU | Storage | Backups | Databases |
|---|---|---|---|---|---|
| Starter | 512 MB | 0.5 core | 3 GB | 1 | 1 |
| Basic | 1 GB | 1 core | 5 GB | 2 | 2 |
| Pro | 2 GB | 2 cores | 10 GB | 4 | 4 |
| Max | 4 GB | 4 cores | 20 GB | 8 | 8 |
The pattern is worth noting: each step roughly doubles memory and storage together. Moving up a plan is therefore rarely about “more CPU” — it is almost always about more memory headroom and more room to store backups.
A rule of thumb that works
Measure instead of guessing. Run your service for a real hour, then look at the memory graph in the panel while it is under normal load. Take the peak, and size your plan at roughly 2× that peak. The multiplier matters because it absorbs traffic spikes, deploys that briefly hold two versions in memory, and garbage collection that has not settled yet.
A container that sits at 85 % of its limit is not “fine”. It has no room to absorb a spike, and the failure mode is an abrupt out-of-memory kill rather than a slowdown you can see coming.
Changing plans later
You can change plan from the client area without losing files, databases or configuration. When you do, restart the container so it picks up the new limits — a running process keeps its old limits until it is recreated.
If you are still unsure, every plan includes a free 7-day trial of the Starter tier, and you can upgrade a few days in once you have measured real usage rather than a guess.