PLANNING · 4 MIN READ
Start with the workload you can describe. Then leave room for the part you have not met yet.
Memory: count the things that stay alive.
List your web server, application workers, database and any background processes. Look at memory use under realistic traffic, not just immediately after boot. If services are killed or the server swaps heavily, adding CPU alone will not fix the underlying memory pressure.
CPU: measure busy time, not just core count.
Image processing, builds, reports and complex queries can use CPU in bursts. More virtual cores can help parallel work, but a single-threaded bottleneck may need application changes. Compare measurements from your own code.
Storage: leave space for change.
Include the OS, application releases, logs, package caches and temporary files. Databases may need spare space for indexes and maintenance. Treat local snapshots or local archive files as disk usage, not as an independent disaster-recovery plan.
Transfer: follow the outbound bytes.
Images, downloads, API responses and backup transfers all matter. Estimate typical transfer, then watch a real usage period. Confirm how inbound and outbound traffic are measured and what happens at the limit before using the server for a bandwidth-heavy service.
Three useful starting points.
- Tempo 2: evaluate for a small personal site or lightweight service.
- Tempo 6: evaluate for an application and modest database.
- Studio 32: evaluate for a larger memory working set or several persistent services.
The numbers that tell you to move.
Watch sustained resource pressure together with application latency and errors. A single busy minute is not a capacity plan. First rule out inefficient queries, unbounded queues and accidental memory growth; then discuss an upgrade with support.
Discuss a configuration