Most sites are over sold and under protected
The usual mistake is paying for cores that sit idle while having no working backup. Capacity is easy to add later. Losing a database with no restore is not something you fix later.
Size the server for what you run today, then spend the difference on backups and monitoring.
What each resource actually does
These four numbers are what you choose in the calculator on our pricing section.
- vCPU: how many requests can be processed at once. A content site is rarely CPU bound; report generation and image processing are
- RAM: the usual first limit. Databases and application workers hold memory, and running out causes crashes rather than slowness
- NVMe storage: the database, uploads and logs. Logs grow quietly, so leave headroom
- Traffic: how much leaves the server each month. Video and large images dominate this, ordinary pages rarely do
A reasonable starting point
For a content managed website with a few editors, 2 vCPU and 4 GB of RAM is comfortable. For a production application with real users and background jobs, start at 4 vCPU and 8 GB, then watch memory for a month before changing anything.
Scale on evidence. Monitoring tells you which resource is actually the limit, and it is often not the one people assume.
The parts nobody asks about until it is too late
Hosting is judged on the worst day, not the average one. These are the questions worth asking any provider, including us.
- How often are backups taken, how long are they kept, and has a restore actually been tested
- Is there a second copy somewhere other than the same machine
- Who applies security patches, and how quickly
- Who answers at two in the morning, and what does that cost
Where we stand
Every plan we run includes NVMe storage, free SSL, a firewall, and a migration of your existing site. Daily backups with a fourteen day history and an offsite copy are options in the calculator, and for most business systems we would take both.