Plan resource-pool capacity

Capacity planning does not need to begin with perfect numbers. Start with a realistic estimate, observe the application, and change capacity through supported dashboard controls as needs become clearer.

Estimate each workload

For every application, write down:

whether it is a web service, static site, or worker;
expected CPU use during normal and peak traffic;
expected memory use after startup and under load;
persistent storage requirements and growth rate;
whether a deployment temporarily increases resource demand.

Then compare the total with the pool’s CPU, memory, and storage.

Leave operational headroom

A pool that is constantly at its limit is harder to deploy and recover. Leave enough spare capacity for demand spikes, application restarts, and new releases. If several applications peak at the same time, plan for that shared peak rather than each average in isolation.

Choose application allocations

The application deployment form offers presets for common sizes and allows explicit CPU and memory values. Presets are starting points, not performance guarantees.

Use a smaller allocation for development and lightweight services. Use larger allocations only when workload measurements or known requirements support the choice. If an application repeatedly exits, slows down, or cannot complete work, compare its allocation with runtime logs and pool capacity before increasing resources.

Storage planning

Persistent volumes keep application data at a configured mount path. Keep these rules in mind:

request only the storage the application needs;
monitor growth outside of emergency periods;
do not store secrets in filenames or volume names;
maintain an independent backup strategy for important data;
understand the application’s behavior when a volume is full.

Cost review

Pool capacity determines the estimate shown during creation. Use the dashboard or current pricing page for current prices. Recheck cost before any capacity-changing action, especially for production resources.