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 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 14 sizes
The current General Purpose lineup ranges from 1 vCPU / 1 GB RAM / 25 GB NVMe at $4.99/month to 16 vCPU / 32 GB RAM / 320 GB NVMe at $139.99/month. Current monthly pricing verified against Raff’s September 2026 pricing source is:
| vCPU | Memory | NVMe SSD | Monthly price | Practical role |
|---|---|---|---|---|
| 1 | 1 GB | 25 GB | $4.99 | Lightweight sites, test services, very small apps |
| 1 | 2 GB | 50 GB | $8.99 | Small services that need more runtime memory |
| 2 | 2 GB | 40 GB | $12.99 | Lightweight sites, dev, test, small services |
| 2 | 4 GB | 80 GB | $17.99 | Small apps that need more runtime memory |
| 4 | 4 GB | 80 GB | $24.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 | $33.99 | Balanced production apps |
| 8 | 8 GB | 160 GB | $48.99 | CPU-active shared-vCPU workloads |
| 4 | 16 GB | 240 GB | $55.99 | Memory-heavy services and multi-service VMs |
| 8 | 16 GB | 240 GB | $71.99 | Larger balanced applications |
| 16 | 16 GB | 240 GB | $103.99 | High parallelism where shared CPU remains acceptable |
| 12 | 24 GB | 320 GB | $109.99 | Larger mixed workloads needing CPU and memory |
| 8 | 32 GB | 320 GB | $119.99 | RAM-heavy workloads with moderate CPU needs |
| 16 | 32 GB | 320 GB | $139.99 | Large balanced or consolidated workloads |
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 1 vCPU plan is available with either 1 GB or 2 GB RAM. 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 plans cover lightweight workloads without forcing 2 vCPU
The two 1 vCPU plans now provide a lower-cost starting point for workloads that do not need 2 vCPU from day one.
| Workload pattern | Starting plan to evaluate | Current price | What to verify after launch |
|---|---|---|---|
| Very small site, test service, lightweight utility | 1 vCPU / 1 GB / 25 GB | $4.99/mo | Memory headroom, storage growth |
| Small service needing more runtime memory | 1 vCPU / 2 GB / 50 GB | $8.99/mo | RAM pressure, swap, response time |
| Lightweight app, dev, or test environment | 2 vCPU / 2 GB / 40 GB | $12.99/mo | Memory headroom, CPU saturation |
| Small API or app needing more runtime memory | 2 vCPU / 4 GB / 80 GB | $17.99/mo | p95 latency, memory, swap |
The 1 GB plan is appropriate only when the operating system, runtime, and application can fit safely with headroom. Container stacks, database-backed applications, or memory-hungry runtimes often need 2 GB, 4 GB, or more even at low traffic.
The point of the smaller entry plans is flexibility, not a recommendation to under-size production workloads.
Midrange plans cover many small production applications
The middle of the General Purpose ladder gives teams several CPU-to-memory ratios without jumping immediately to a large server.
| Workload pattern | Starting plan to evaluate | Current price | What to verify after launch |
|---|---|---|---|
| Balanced app needing more parallel CPU | 4 vCPU / 4 GB / 80 GB | $24.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 | $33.99/mo | CPU, RAM, database and worker contention |
| CPU-active app where shared compute is still acceptable | 8 vCPU / 8 GB / 160 GB | $48.99/mo | Sustained CPU and tail latency |
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 up to 320 GB NVMe in the current General Purpose lineup;
- 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 provide 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 keeps the core network and management model consistent across the lineup
The current Raff Cloud Server model keeps the main operating experience consistent across plan sizes. Relevant platform characteristics include:
- 3 Gbps public network port;
- unmetered VM traffic with no egress fee;
- resize support for CPU, RAM, and storage;
- free private networking through VPC;
- DDoS protection;
- browser console and full root access;
- API and Terraform access;
- live monitoring.
These characteristics matter because the size decision can stay focused on the workload: CPU, memory, local storage, and whether shared compute is still the right allocation model.
Public IP pricing and other add-ons should be checked separately on the Raff pricing page rather than assumed to be included in every plan.
Billing term should match workload certainty
General Purpose VMs support pay-as-you-go billing. Check the live pricing page for current billing terms.
Use more flexible billing when the workload is temporary, experimental, or still being sized. Use longer commitments when the workload is stable enough that both its existence and size are unlikely to change soon.
A discount on an oversized or unnecessary VM is still wasted spend, so commitment length should come after the sizing decision, not before it.
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 currently provide a 14-size shared-vCPU ladder from 1 vCPU / 1 GB / 25 GB at $4.99/month to 16 vCPU / 32 GB / 320 GB at $139.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.
