Choose a VPS from the resources your application actually needs: memory for persistent services and concurrency, CPU for the work it can execute, and storage and transfer for its data. Keep enough headroom and measure the delivered environment.
Start with the work the machine will do
A VPS purchase gets easier when you describe the application before choosing the plan. List the processes you expect to run: a web application, a database, background workers, monitoring and perhaps a control panel. Note which are always active and which only run occasionally. A quiet static website and a database with many simultaneous users can have very different needs even when their visitor counts look similar.
If you already run the project, record normal usage and busy periods. CPU load, memory pressure, disk growth and transfer volume give you a starting point. For a new project, begin with an explicit estimate and plan to measure it after launch. An estimate you can revise is more useful than a large machine chosen without a reason.
Memory often decides the practical starting point
Count the memory required by the operating system and every persistent service, then leave room for real traffic. A database cache or a build process can change the picture quickly. If the machine spends time swapping or terminating processes under pressure, adding more CPU will not resolve the underlying shortage.
CPU specifications deserve a separate reading. A virtual core is a resource presented to the guest environment; the processor model and the provider's allocation policy influence the result. KVM provides a virtual machine with its own virtual hardware, but the word KVM by itself is not a guaranteed benchmark. Compare the actual configuration and test your own application when the service becomes available.
Budget the data that accumulates quietly
Storage includes more than the application directory. Operating system packages, logs, database indexes, uploaded files, temporary exports and deployment artefacts all consume capacity. Leave headroom for updates and maintenance tasks, and decide how long each kind of data should remain. Logs that grow without a retention policy can fill even a generous disk.
Separate capacity from responsiveness. An NVMe configuration may be relevant when disk access is a bottleneck, while a storage-oriented product fits large archives. Neither label replaces a backup plan. Confirm whether an optional backup includes the data you need and keep an independent recovery route for important services.
Read the network and the extras as part of the machine
A port rate and a monthly transfer allowance are different constraints. Include downloads, API traffic, replication and backups in your estimate. An optional faster port may help a bursty workload but does not automatically change the included transfer. Read the configuration after selecting extras, rather than relying only on the starting price.
Choose an operating system you can maintain. Add management, extra addresses, software licences or backups only when they answer a real requirement. Record the recurring total and billing period so the decision remains clear when the initial setup is forgotten.
A practical scenario: a website with background exports
Imagine a small site with a database, two web workers and an export job. Normal page requests are light, but exports create temporary files and use more memory. The owner lists those processes separately, measures their behaviour with representative data and includes the export directory in the capacity estimate. The first shortlist is based on that combined workload, not on the visitor count or the cheapest starting price.
During testing, allowing several exports to overlap delays ordinary requests. The owner limits export concurrency, observes the queue and repeats the test before buying more CPU. On a supported Linux setup, resource-control mechanisms can also help organise processes, but their settings must match the environment. If the constrained workload still needs more memory, an upgrade now answers a measured requirement rather than masking an unbounded task.
The owner then adds an independent backup and checks restoration. This exercise illustrates a selection method, not a performance claim for a SwissOctet plan. Record the assumptions with the selected configuration and revisit them when the site adds a feature, a larger dataset or a different maintenance job.
| Workload part | What to measure | Selection implication |
|---|---|---|
| Web requests | Worker memory and response times | Allow room for normal concurrency |
| Export job | Peak memory and temporary storage | Bound overlap and reserve capacity |
| Recovery | Backup size and restore time | Plan independent storage and transfer |
Prepare the first week before the first login
After delivery, verify access, update the system and expose only the ports the project needs. Deploy a small working version before moving all data. Observe the resource use under representative traffic and compare it with your estimate. Keep the previous environment until you have checked the application and tested a restoration.
The best starting VPS is the one that meets your measured needs with sensible headroom and a clear next step. Use the SwissOctet comparison to shortlist specifications, then prepare questions about availability, upgrades and operational responsibility before committing.
Your practical checklist.
- List all persistent services.
- Estimate memory and busy-period CPU.
- Include logs, exports and growth in storage.
- Read port speed and monthly transfer separately.
- Plan updates, backups and a migration rollback.
The details that matter.
Can I choose a VPS from visitor count alone?+
No. Request complexity, concurrent processes, data size and maintenance work can create very different resource demands.
Does KVM describe a guaranteed performance level?+
No. It identifies the virtualisation technology. The processor, allocation and actual workload still matter.
Which optional upgrade should I choose first?+
Choose the option that addresses the measured constraint. More CPU will not necessarily resolve memory pressure or storage waits.
Go to the source.
These references support the technical concepts in this guide. Follow the current documentation before changing a production system.
- KVM project: Kernel Virtual Machine www.linux-kvm.org
- Linux kernel: Control Group v2 docs.kernel.org
- Linux kernel: Pressure Stall Information docs.kernel.org
Editorial guidance by SwissOctet. Examples are illustrative. Service specifications, available options and contractual conditions must be verified separately.