Write down the workload first
A mostly static website, an API with background workers and a shop with a database put different pressure on a machine. Count the services that run together: web server, database, cache, queue workers and any administration panel. Include scheduled jobs, not just normal page requests.
For an existing application, collect memory use, CPU peaks, disk growth and response times. For a new project, create a modest test environment and load it with representative data. A small empty database can hide the bottlenecks that appear with a real catalogue.
Use a starting estimate, then measure
The examples below are planning estimates, not hosting plans or performance guarantees. They assume a lightweight server setup without a desktop environment. Traffic volume alone cannot determine the right size: application code and caching matter too.
Scroll sideways to see the full table
| Workload | vCPU | RAM | Storage |
|---|---|---|---|
| Learning basic Linux | 1 | 1–2 GB | 20 GB |
| Small dynamic site | 2 | 2–4 GB | 30 GB |
| API and a few services | 2 | 4 GB | 40 GB |
| Shop with a local database | 4 | 8 GB | 80 GB |
Leave capacity for updates, logs and backups in progress. If the machine regularly swaps during requests, adding memory may help more than adding CPU. If disk latency is high, find the source of I/O before paying for additional cores.
Read what CPU and storage actually mean
Check whether CPU time is shared, dedicated or subject to a fair-use policy. The same vCPU count does not establish identical sustained performance. Ask whether sustained compilation, video processing or intensive batch jobs fit the plan.
Storage capacity is only one part of the decision. Check the disk type, any I/O limits and whether storage can grow independently. Resizing a disk and shrinking it later may have different rules. Keep an exportable backup before changing the storage layout.
Check the complete network path
Choose a region based on the people and services that communicate with the application. A database in another region can add latency to every request even when the web server looks fast in isolation. Test from a location close to your actual users.
Read the included traffic allowance, overage price, port speed and public address charges. Confirm inbound restrictions if you need email delivery or unusual protocols. A high advertised connection speed is not a promise that every external destination will transfer at that rate.
Compare the monthly bill, not the headline
Add the VM, public addresses, extra volumes, backups, traffic and management services. Check the billing unit and what happens when a server is stopped. Some resources can remain billable until they are deleted or released.
Record the currency and whether applicable taxes are included in the displayed amount. Compare the same recovery setup across providers; a cheap machine without the backup storage you need is an incomplete comparison. Avoid treating introductory pricing as a permanent operating cost.
Know which tasks remain yours
With an unmanaged VPS, the application and operating system usually remain your responsibility. Read the support scope: infrastructure assistance is different from debugging your database or repairing a deployment. Confirm access to a console, reinstall tools and a clear incident channel.
For a business application, ask how backups are retained, how restoration works and whether a snapshot is stored independently of the affected host. Practise an export before committing important data. Your exit plan should work even if the control panel is unavailable.
A practical acceptance test
- Deploy the same application build and representative dataset you expect to use.
- Run a realistic workload, including background jobs and scheduled imports.
- Observe response times, memory pressure, CPU saturation and disk latency.
- Test a restart and restore a backup in a separate environment.
- Record the full recurring cost and decide whether there is enough headroom.
Once the plan fits, use the first deployment checklist to prepare the machine.
Questions and answers
Is the cheapest plan enough for a website?
It can be enough for a small, efficient workload. Test the actual application and leave space for maintenance; the number of pages alone does not determine resource use.
Should I pay for managed hosting?
Consider it when you need someone else to maintain the operating system and respond to incidents. Check exactly which tasks are included before comparing it with an unmanaged VPS.