Start with the workload
There is no universal VPS size for a given number of visitors. A cached brochure site, a busy WooCommerce store and a background-worker API have different CPU, memory, disk and database profiles. List the web server, application workers, database, cache, scheduled jobs and monitoring agents that will share the host.
Estimate peak concurrent work, not just monthly page views. Record the heaviest user journeys and expected bursts. If the database is on the same VPS, reserve memory and disk I/O for it before allocating the rest to application workers.
Budget memory and storage
Measure representative process memory under load, allow for the operating system and leave headroom for bursts. A process limit derived from an average alone can overcommit memory when several expensive requests arrive together. Include backup and restore working space, temporary files and log retention in storage planning.
Disk capacity is not the same as disk performance. Check latency and throughput under a representative read/write mix, as well as provider limits. Monitor inode usage separately when the workload creates many small files.
Test and adjust
Use a staging or agreed test environment with production-like configuration. Run a realistic mix of requests, including login, search and background jobs. Observe response times, error rates, memory pressure, CPU scheduling and disk latency. Increase capacity or change the architecture based on the measured bottleneck.
Document a recovery plan before resizing: backups, provider resize behavior, maintenance window and rollback. Review capacity after major releases and seasonal traffic changes; a larger server does not fix every slow query or external dependency.
Further reading
Read the official documentation. For help applying these checks, explore Clouvenix services.