Resources
Sizing
Start with the workload, then measure the machine doing it. These are practical starting points, not a calculator pretending to be exact.
Start with the workload
Saphira itself is small. Your workload is usually what determines the size of the machine. Static nginx delivery, a Node or PHP application, MariaDB, mail scanning and compiler workloads have different CPU, memory and I/O characteristics.
- Static or nginx-only service
- Web application
- Database-backed web service
- Mail server
- Combined small infrastructure server
- Build or development host
- Higher-concurrency production service
Suggested starting points
| Workload | CPU | Memory |
|---|---|---|
| Static / very light web | 1–2 vCPU | 512 MiB–2 GiB RAM |
| Small application server | 2 vCPU | 2 GiB RAM |
| Application + MariaDB | 4 vCPU | 4 GiB RAM minimum practical baseline |
| Mail services | +1 vCPU | +1 GiB RAM minimum; add more for scanning and indexing |
| Combined small server | 4 vCPU | 8 GiB RAM |
| Build / development host | 4+ vCPU | 8 GiB+ RAM: scale with parallel jobs |
What changes the answer
Higher concurrency changes sizing materially. Do not turn a static nginx benchmark into a promise about Node SSR, PHP, databases, mail or AIE processing.
Measure the real workload and watch:
- CPU saturation and run queue pressure.
- Memory pressure and swap activity.
- I/O wait and storage latency.
- Database buffer requirements and query load.
- Mail scanning, indexing, concurrency and retention cost.
Add headroom before saturation. A machine that only works when every resource is full is already undersized.