Raff General Purpose VM plans are shared-vCPU cloud server configurations that balance CPU, memory, and NVMe storage for variable and mixed workloads.
The useful choice is not simply “small, medium, or large.” Two plans with the same vCPU count can have very different memory ratios, and two plans with the same RAM can provide very different compute headroom. Raff Technologies supports 3,000+ customers and 15,000+ VMs, and in customer conversations the recurring sizing mistake is choosing by vCPU count before identifying whether memory, CPU, storage, or service contention is actually limiting the application.
This guide is the plan-level companion to Cloud VM Machine Classes Explained. Use that parent guide when deciding between General Purpose, CPU-Optimized, and memory-forward resource shapes. Use this page when General Purpose is already the right class and you need to choose a current Raff size without overbuying.
Raff General Purpose VM plans currently span 12 sizes
The current General Purpose lineup ranges from 2 vCPU / 2 GB RAM / 40 GB NVMe to 16 vCPU / 32 GB RAM / 640 GB NVMe. Monthly pricing on August 10, 2026 is:
| vCPU | Memory | NVMe SSD | Monthly price | Practical role |
|---|---|---|---|---|
| 2 | 2 GB | 40 GB | $8.49 | Lightweight sites, dev, test, small services |
| 2 | 4 GB | 80 GB | $13.99 | Small apps that need more runtime memory |
| 4 | 4 GB | 80 GB | $16.99 | Balanced apps needing more parallel CPU |
| 2 | 8 GB | 160 GB | $27.99 | Memory-forward workloads with modest CPU demand |
| 4 | 8 GB | 160 GB | $30.99 | Balanced production apps; currently marked Popular |
| 8 | 8 GB | 160 GB | $37.99 | CPU-active shared-vCPU workloads |
| 4 | 16 GB | 320 GB | $52.99 | Memory-heavy services and multi-service VMs |
| 8 | 16 GB | 320 GB | $59.99 | Larger balanced applications |
| 16 | 16 GB | 320 GB | $75.99 | High parallelism where shared CPU remains acceptable |
| 12 | 24 GB | 480 GB | $90.99 | Larger mixed workloads needing both CPU and memory |
| 8 | 32 GB | 640 GB | $115.99 | RAM-heavy workloads with moderate CPU needs |
| 16 | 32 GB | 640 GB | $129.99 | Large balanced or consolidated workloads |
Raff General Purpose plans start at $8.49/month for 2 vCPU, 2 GB RAM, and 40 GB NVMe.
The table is a current plan map, not a guarantee that a workload will fit a specific size. Application behavior, concurrency, database activity, container count, cache usage, and storage growth can move the requirement in either direction.
The plan ladder also shows why vCPU count alone is a poor sizing method. A 2 vCPU plan is available with 2 GB, 4 GB, or 8 GB RAM. An 8 vCPU plan is available with 8 GB, 16 GB, or 32 GB RAM. The right choice depends on the resource ratio the workload consumes, not only the largest number in the plan name.
The plan decision starts with CPU-to-memory ratio
Once General Purpose is the correct machine class, the next decision is whether the workload needs more CPU, more memory, or a balanced increase in both.
| Workload signal | Better direction | Why |
|---|---|---|
| CPU is comfortable but memory is tight | Increase RAM before vCPU | More CPU does not fix memory pressure |
| Memory is comfortable but requests or workers saturate CPU | Increase vCPU | More compute may improve concurrency or throughput |
| CPU and memory rise together | Move to a balanced larger plan | Both resources need headroom |
| Swap is active or OOM events occur | Choose a higher-memory shape | Stability is constrained by RAM |
| CPU spikes briefly and then returns to normal | Stay on General Purpose and observe | Short bursts do not automatically justify dedicated CPU |
| CPU stays busy for long periods and timing consistency matters | Evaluate CPU-Optimized | CPU allocation model may matter more than General Purpose size |
| Local disk is filling rapidly | Increase storage or change storage architecture | CPU/RAM upgrades do not solve durable data growth |
| App, database, and workers compete on one VM | Measure each service separately | Service separation may be better than one larger server |
From Raff customer conversations, the cleanest upgrade decisions happen when a team can name the constrained resource before opening the pricing table. “The app feels slow” is not enough. “Memory is consistently near exhaustion while CPU remains moderate” points toward a different plan than “CPU is saturated while half the RAM is unused.”
This is why the General Purpose ladder should be read horizontally as well as vertically. A workload can move from 2 vCPU / 4 GB to 4 vCPU / 4 GB when it needs more compute, or to 2 vCPU / 8 GB when it needs more memory.
Entry and midrange plans cover most small application starting points
The first six General Purpose plans cover a useful range for small websites, APIs, SaaS applications, development environments, and self-hosted tools.
| Workload pattern | Starting plan to evaluate | Current price | What to verify after launch |
|---|---|---|---|
| Lightweight site, dev server, test environment | 2 vCPU / 2 GB / 40 GB | $8.49/mo | Memory headroom, storage growth |
| Small API or app needing more runtime memory | 2 vCPU / 4 GB / 80 GB | $13.99/mo | p95 latency, memory, swap |
| Balanced app with more active request processing | 4 vCPU / 4 GB / 80 GB | $16.99/mo | CPU saturation, memory pressure |
| RAM-sensitive app with modest compute | 2 vCPU / 8 GB / 160 GB | $27.99/mo | Working set, cache behavior |
| Small production stack with balanced needs | 4 vCPU / 8 GB / 160 GB | $30.99/mo | CPU, RAM, database and worker contention |
| CPU-active app where shared compute is still acceptable | 8 vCPU / 8 GB / 160 GB | $37.99/mo | Sustained CPU and tail latency |
The 4 vCPU / 8 GB / 160 GB configuration is currently marked Popular on the pricing page. That label is useful as a product signal, but it should not replace workload measurement.
Raff's 4 vCPU / 8 GB / 160 GB General Purpose plan is currently $30.99/month.
For a small application, the 2 GB plan can be a sensible entry when the runtime is lightweight and durable data is limited. A container stack, database-backed application, or memory-hungry runtime may need 4 GB or 8 GB even with low traffic.
Likewise, moving from 2 vCPU to 4 or 8 vCPU should be driven by CPU behavior. More vCPU can help concurrent request handling, workers, builds, or application processing, but it does not automatically improve a workload waiting on a database, storage, or external service.
Larger plans fit consolidation and higher resource demand
The 16 GB, 24 GB, and 32 GB tiers are useful when a workload has already outgrown the entry and midrange shapes or when several services intentionally share one VM.
Common reasons to evaluate these plans include:
- larger application heaps or caches;
- database-backed services with a bigger memory working set;
- several containers sharing the same host;
- app + worker + queue combinations that need more aggregate headroom;
- higher request concurrency while shared vCPU remains suitable;
- local data or package growth requiring 320–640 GB NVMe;
- temporary consolidation before services are separated.
The larger plans still follow the same ratio logic. 4 vCPU / 16 GB and 8 vCPU / 16 GB share the same memory and storage but offer different compute capacity. 8 vCPU / 32 GB and 16 vCPU / 32 GB do the same at the top of the current ladder.
That makes the decision clearer:
- choose the lower-vCPU version when memory is the main need;
- choose the higher-vCPU version when both memory and compute are active constraints;
- evaluate CPU-Optimized when sustained CPU predictability, not just core count, becomes important;
- split services when independent scaling or recovery is more valuable than one larger VM.
A large General Purpose VM is not automatically the final architecture. If a database, worker tier, or file workload has a different lifecycle, separation may reduce contention and make future sizing easier.
General Purpose remains a shared-vCPU decision
All General Purpose sizing decisions sit inside one important boundary: the class uses shared compute.
That is appropriate for many websites, APIs, development environments, customer applications, and mixed workloads because CPU demand is often variable. Shared compute provides cost efficiency when the workload does not need reserved CPU capacity continuously.
The class becomes less attractive when a workload is consistently CPU-bound and execution-time predictability itself has operational value. Examples include long-running CI builds, continuous compute workers, encoding, heavy transformation jobs, or latency-sensitive services where CPU pressure repeatedly aligns with p95 or p99 latency.
In that case, the better question is not “Should I buy the 16 vCPU General Purpose plan?” It may be “Should this workload move to dedicated compute?”
Use Shared vs Dedicated vCPU for that decision. If the issue is simply core count within a shared-vCPU workload, 2 vCPU vs 4 vCPU Cloud VMs provides the narrower framework.
Raff includes the same core network and management defaults across the lineup
The current pricing page lists the following platform characteristics across Raff Cloud Server plans:
- 3 Gbps public network port;
- unmetered bandwidth with no caps or bandwidth billing;
- resize support for CPU, RAM, and storage;
- one IPv4 with optional IPv6 dual-stack;
- free private networking (VPC);
- included DDoS protection;
- browser console and full root access;
- API and Terraform access;
- live monitoring.
Every current Raff Cloud Server plan includes a 3 Gbps public port and unmetered bandwidth.
These defaults matter because they remove several variables from the size decision. A team choosing between 2 vCPU / 4 GB and 4 vCPU / 8 GB does not also need to choose a different bandwidth allowance or public port tier.
The sizing problem therefore stays focused on the workload: CPU, memory, local storage, and whether shared compute is still the right allocation model.
For exact current prices, always verify the Raff pricing page before deployment. Pricing and plan tables can change faster than long-lived Learn content.
A measured upgrade path avoids both waste and instability
The first VM size is an informed estimate. The next size should be based on evidence.
A practical upgrade sequence is:
- Start with the smallest plan that safely fits the known workload. Leave enough memory and storage for the runtime, operating system, logs, deployments, and expected data growth.
- Measure CPU, memory, swap, disk usage, latency, and application-specific outcomes. Do not use one resource graph in isolation.
- Change one resource direction at a time when possible. More RAM and more vCPU solve different problems.
- Re-test under comparable load. Confirm that the upgrade improved latency, throughput, stability, or operational headroom.
- Change class when the allocation model becomes the constraint. Sustained CPU predictability points toward CPU-Optimized rather than endlessly increasing shared-vCPU size.
- Change architecture when services need independent boundaries. Databases, workers, uploads, or other stateful components may eventually deserve separate resources.
When the bottleneck is unclear, use Cloud Server Performance Bottlenecks before upgrading. For memory-specific pressure, continue with HiMem VMs Explained.
The point is not to run infrastructure as close to failure as possible. It is to keep enough headroom for normal traffic, deployments, maintenance, and expected growth without buying resources that the workload does not use.
The right Raff General Purpose plan follows the measured bottleneck
Raff General Purpose VM plans give small teams a 12-size shared-vCPU ladder from 2 vCPU / 2 GB / 40 GB at $8.49/month to 16 vCPU / 32 GB / 640 GB at $129.99/month.
Start at the lower end when the workload is lightweight and uncertain. Move toward higher-memory shapes when RAM pressure appears first. Add vCPU when compute is the measurable constraint. If sustained CPU predictability becomes important, evaluate CPU-Optimized rather than treating a larger General Purpose plan as the only upgrade path.
For the parent decision, return to Cloud VM Machine Classes Explained. For CPU allocation, continue with Shared vs Dedicated vCPU, and use the live Raff pricing page for the latest plan table before deployment.