Docs / Guardrails

Capacity & cost planning

Exploring An idea we are working through. The method below is how we plan sizing with customers today; any tooling for it is not committed.

In the cloud, capacity is a price list and a credit card. On premises it is hardware you buy once, power you pay for every month and rack space you may run out of. On-premise capacity and cost planning is about knowing how much headroom you have, how fast you are using it, and when the next purchase or the next stage pays for itself. TractorStack targets Proxmox VE first, or the infrastructure you already run, such as VMware vSphere, another hypervisor or bare-metal servers, and the same planning applies to all of them.

On-premise capacity and cost planning: what to measure

The monitoring stack already collects most of what is needed. The figures that matter for planning:

• CPU. Average and busy-hour use per host, and how much is reserved for VMs compared with how much is used.
• Memory. Usually the first limit on a hypervisor. Count what VMs are given, not only what they use, since Proxmox VE and vSphere both let you overcommit and it is easy to overdo.
• Disk. Used space, growth per month, and free space per pool. Databases and object storage grow steadily; logs and backups grow faster than people expect.
• Disk performance. Latency at busy times. A disk that is half empty but slow is still full in practice.

Headroom and growth

A plan needs two numbers per resource: how much headroom you keep, and how long until you hit it at the current growth rate. Headroom covers spikes, upgrades and the loss of one host. In stage 2 and beyond, the remaining hosts must be able to carry the load of a failed one, so a cluster that runs every host at 80% has no real spare capacity. The growth figure turns into a date, and the date tells you when to order hardware, allowing for delivery times.

Backup storage multiples

Backup storage is often underestimated. The space needed is a multiple of the live data, depending on retention, how much changes each day, and how many copies you keep. A rough way to estimate it:

• one full backup per retention cycle, plus daily changes for every day kept;
• write-ahead log archives for PostgreSQL point-in-time recovery;
• the same again for each extra copy, such as off-site or offline.

We work the multiple out from your real data and the retention you choose; see backups and restore tests. It is rarely less than two or three times the live data, and often more.

Power, cooling and rack space

Every server adds power draw, heat and rack units. Before a stage that adds hosts, check the circuit capacity in the room or colocation contract, the cooling, and free rack units including space for switches. These limits are slow and expensive to change, so they belong in the plan, not in a surprise during installation.

When the next stage pays off

Moving up a stage adds hardware and running effort. It pays off when the cost of staying is higher: outages that hurt, maintenance windows you can’t get, or teams waiting on each other. The guidance in moving between stages lists the usual signs. For costs, we compare your actual hardware quotes, power price and support contracts; we don’t publish example prices, because they vary too much between countries and suppliers to be useful.

Last updated 25 October 2026 · Questions or corrections: sales@infratractor.com