Cloud VM machine classes are server categories that group CPU allocation, memory ratio, and storage capacity around different workload patterns.
Choosing a class is not the same as choosing a bigger server. A balanced web application, a CPU-bound worker, a memory-heavy database, and a multi-service self-hosted stack can all use similar vCPU counts while needing very different resource profiles. The useful question is therefore not “Which VM class is best?” but “Which resource becomes limiting first, and how predictable does that resource need to be?”
Raff Technologies supports 3,000+ customers and 15,000+ VMs. In Raff customer conversations, a recurring sizing mistake is choosing by vCPU count before identifying whether CPU, memory, storage, or service contention is actually controlling the workload.
This guide is the connector for Raff’s VM Machine Classes cluster. It explains the decision model first, then links to the deeper guides on General Purpose VM plans, HiMem VMs, and shared vs dedicated vCPU.
Machine classes describe resource allocation and workload shape
A VM class is a resource model, not a quality grade.
Cloud providers group virtual machines into classes because workloads create pressure in different places. Some applications need a balanced amount of CPU and memory. Others need predictable CPU time for long-running compute. Databases and multi-service applications may need more RAM per vCPU. Storage-sensitive workloads may be limited by capacity or I/O before CPU becomes important.
The main dimensions are:
- CPU allocation: shared or dedicated compute;
- vCPU count: how much parallel compute the VM can expose;
- memory ratio: how much RAM is available per vCPU;
- storage capacity: how much persistent local storage the workload can consume;
- storage behavior: whether the workload depends on frequent reads, writes, or durable data growth;
- network behavior: whether throughput, latency, or transfer billing changes the decision;
- operational role: whether one VM hosts one service or several competing services.
Two 4 vCPU machines can therefore be very different choices. One may provide a balanced memory ratio on shared CPU, while another reserves CPU for sustained compute. A third may keep the same core count but provide substantially more RAM.
The class name should summarize the resource trade-off. It should not replace workload measurement.
Raff’s 3 Gbps unmetered VM network means machine-class selection can focus on CPU, memory, storage, and workload behavior.
The decision framework starts with the first constrained resource
The central machine-class decision is to identify what the workload runs out of first during normal pressure.
| Workload signal | Likely constraint | Better starting direction |
|---|---|---|
| CPU rises briefly, then returns to normal | Variable compute | General Purpose |
| CPU stays high while latency or job time increases | Sustained compute | CPU-Optimized or more vCPU |
| CPU is moderate but memory is near exhaustion | RAM | High-memory shape |
| Swap activity or OOM events appear | RAM | High-memory shape or service separation |
| App, database, queue, and workers compete on one VM | Mixed resource contention | More memory first, then consider separation |
| Builds or workers take too long with sustained CPU pressure | Compute throughput | CPU-Optimized |
| Database is slow while CPU remains comfortable | Query, memory, storage, or locks | Diagnose before changing class |
| Logs, uploads, database files, or containers consume disk rapidly | Storage growth | More storage or separate storage path |
| One VM still meets performance and recovery needs | Simplicity | Stay on one appropriately sized class |
| Different services need independent scaling or recovery | Architecture boundary | Split roles instead of buying one larger class |
This framework prevents a common mistake: upgrading the resource that is easiest to see rather than the resource that controls the workload.
For example, a database-backed application may show 35% CPU and still be unstable because 95% of memory is committed and swap is active. A 4 vCPU upgrade would add compute without solving the real constraint. Conversely, a CI runner may have plenty of free RAM while all available CPU stays busy for long periods. A high-memory class would add the wrong resource.
The first decision should therefore be diagnostic:
- identify the user-visible or operational problem;
- correlate it with CPU, memory, storage, and workload behavior;
- choose the class that changes the constrained resource;
- verify whether the workload outcome actually improves.
This is also why production status alone should not determine class. A quiet production application can be a strong General Purpose fit. A temporary build runner can justify CPU-Optimized compute if it stays CPU-bound for every run.
General Purpose fits balanced and variable workloads
General Purpose VMs are the default when no single resource clearly dominates the workload.
They fit applications that use CPU in bursts, keep a moderate working set in memory, and do not need reserved compute for long periods. Typical examples include:
- websites and content applications;
- APIs with modest or variable traffic;
- development and staging environments;
- internal tools;
- early SaaS applications;
- small backend services;
- lightweight self-hosted applications;
- mixed workloads where the bottleneck is not yet clear.
The value of General Purpose is not that it works for everything. It is that it is an efficient place to begin when the workload is balanced or still uncertain.
A team can start with the smallest configuration that has enough memory and storage headroom, then observe the workload. If CPU becomes the repeatable constraint, the next move may be more vCPU or a CPU-Optimized class. If memory pressure appears first, a higher-memory shape may be the better change.
Shared CPU also makes sense for many production workloads. Production responsibility means the service matters; it does not automatically mean the service needs dedicated CPU. If latency remains within target and CPU pressure is brief, moving to reserved compute can increase cost without changing the user experience.
The deeper Raff-specific plan ladder is covered in Raff General Purpose VM Plans Explained. That guide should be used for current plan-by-plan specifications rather than treating this connector guide as a permanent pricing table.
CPU-Optimized fits sustained compute and CPU predictability
CPU-Optimized VMs make sense when compute is not merely busy but controls the outcome of the workload.
Good candidates include:
- CI/CD runners with long CPU-bound builds;
- queue workers processing continuously;
- encoding, compression, compilation, or transformation jobs;
- compute-heavy application services;
- game or simulation workloads that depend on CPU timing;
- analytics jobs with sustained processing;
- APIs where tail latency rises with CPU pressure;
- database workloads that have been measured and confirmed as CPU-bound.
The important distinction is sustained demand. Short CPU spikes are normal on many General Purpose workloads. A deployment, package update, cache warm-up, or traffic burst may briefly use every available vCPU without justifying a class change.
CPU-Optimized becomes more defensible when CPU pressure is repeatable under equivalent load and connects to a useful outcome such as:
- slower p95 or p99 response time;
- longer build duration;
- growing queue age;
- reduced worker throughput;
- missed batch deadlines;
- inconsistent completion time.
Raff’s CPU-Optimized family is the dedicated-compute side of this decision. The companion guide Shared vs Dedicated vCPU explains why the real trade-off is cost efficiency versus CPU predictability rather than “basic” versus “powerful” servers.
Dedicated CPU does not fix every performance problem. If a workload is slow because of insufficient RAM, database locks, slow storage, external API calls, or inefficient code, changing CPU allocation may not improve it.
High-memory shapes fit memory pressure without unnecessary CPU
A high-memory VM provides more RAM relative to its vCPU count.
This is useful when application stability depends on the size of the working set rather than on raw compute throughput. Common candidates include:
- PostgreSQL or MySQL databases;
- caches and in-memory services;
- analytics dashboards;
- multi-container applications;
- self-hosted platforms with several services;
- application runtimes with large heaps;
- environments where the app, database, worker, and monitoring stack share one VM.
Memory pressure looks different from CPU pressure. Useful signals include:
- available memory trending toward zero;
- sustained swap activity;
- out-of-memory events;
- container or service restarts;
- database cache pressure;
- application pauses caused by memory management;
- deployment failures because the existing workload leaves too little headroom.
A high-memory shape can be more economical than increasing vCPU just to obtain more RAM. This matters when CPU remains comfortable but the workload needs a larger working set.
Memory should still be sized for the whole machine, not only the main application. A VM running an application server, database, queue, cache, monitoring agent, and reverse proxy has several independent consumers. Each may look modest alone while the combined footprint becomes the real constraint.
The deeper decision is covered in HiMem VMs Explained, which focuses specifically on when more RAM matters more than more CPU.
Storage and service boundaries can outweigh the VM class
A machine-class change is not always the right infrastructure change.
Some workloads appear undersized because unrelated services compete on the same VM. Others are limited by local disk growth, database I/O, or application uploads rather than CPU or memory. In those cases, moving to a larger class can postpone the problem without fixing the architecture.
Consider the storage path separately:
| Symptom | Better question |
|---|---|
| Disk fills because of uploads | Should user files move to object storage? |
| Database files grow rapidly | Does the database need its own storage and recovery boundary? |
| Logs consume local disk | Can retention or centralized logging reduce growth? |
| Backups compete with production I/O | Should backup timing or recovery design change? |
| App and database compete for RAM and CPU | Is it time to separate the database? |
| Workers interfere with web latency | Should workers move to another VM? |
Service boundaries matter because different roles may need different machine classes. A SaaS application can use a balanced General Purpose VM for the web tier and a CPU-Optimized VM for sustained workers. A database may need more memory than either. There is no requirement that every service in one architecture use the same class.
This is often a better growth model than continually enlarging one mixed server. Split only when the independent scaling, deployment, security, or recovery benefit justifies the additional operational complexity.
When the bottleneck is unclear, use Cloud Server Performance Bottlenecks before changing class. If the question is specifically core count, 2 vCPU vs 4 vCPU Cloud VMs is the narrower decision guide.
A practical machine-class framework prevents overbuying
The best machine-class strategy is to make the smallest change supported by evidence.
Start balanced when the workload is uncertain
A new application rarely has enough production data to justify a specialized class. General Purpose keeps the first decision simple while providing a baseline for CPU, memory, and storage behavior.
Specialize only around a visible constraint
Move toward CPU-Optimized when sustained compute is controlling latency or completion time. Move toward high-memory when RAM is controlling stability. Do not specialize because of a workload label alone.
Separate class choice from VM size
Class answers what kind of resource profile the workload needs. Size answers how much of that profile it needs. A workload may need more vCPU without dedicated compute, or more memory without more CPU.
Keep production headroom tied to recovery and traffic behavior
A production VM needs enough capacity for normal variation, deployments, maintenance, and expected peaks. Headroom should come from measured demand and recovery requirements, not a universal utilization percentage.
Revisit the choice after architecture changes
Moving uploads to object storage, separating a database, adding workers, or changing application concurrency can alter the bottleneck. Re-evaluate the class after significant architecture changes instead of assuming the previous choice remains correct.
This framework gives small teams a controlled growth path:
Balanced starting class ↓ Measure CPU, memory, storage, and workload outcomes ↓ Resize within the class if capacity is the issue ↓ Change class if resource shape or CPU predictability is the issue ↓ Split services when independent boundaries become valuable
The purpose is not to predict the final infrastructure at launch. It is to avoid paying for specialization before the workload proves it needs it.
Raff maps the framework to General Purpose, CPU-Optimized, and memory-forward shapes
Raff’s VM lineup uses two primary families and several resource ratios inside them:
- General Purpose: shared compute for balanced and variable workloads;
- CPU-Optimized: dedicated compute for sustained or CPU-sensitive workloads;
- memory-forward configurations: higher RAM-to-vCPU ratios for workloads where memory pressure matters more than additional cores.
As of August 10, 2026, the live Raff pricing page lists the General Purpose entry configuration at 2 vCPU, 2 GB RAM, and 40 GB NVMe for $8.49/month. Because plan tables change, exact pricing should be verified on the live pricing page when selecting a server.
Current VM plans also include a 3 Gbps port, unmetered bandwidth, resize support, IPv4 with optional IPv6, private networking, DDoS protection, monitoring, and full server access.
Raff’s current General Purpose entry is 2 vCPU, 2 GB RAM, and 40 GB NVMe at $8.49/month.
These platform defaults do not remove the need to right-size. They make the decision more focused: choose the CPU allocation model, memory ratio, and storage capacity that match the workload, then resize or change class when measurement shows a different constraint.
For current shared-class sizes and prices, use Raff General Purpose VM Plans Explained together with the live Raff pricing page. For CPU allocation, continue with Shared vs Dedicated vCPU. For memory-focused workloads, use HiMem VMs Explained.
Choose the smallest class that meets the real requirement
Cloud VM machine classes are useful because workloads do not consume infrastructure in the same way.
Choose General Purpose when the workload is balanced, variable, or still uncertain. Choose CPU-Optimized when sustained compute or CPU predictability controls an important outcome. Choose a memory-forward shape when RAM pressure appears before CPU pressure. If storage, database behavior, or service contention is the real constraint, change the architecture rather than only the VM class.
The safest first decision is usually the smallest class that meets current performance, stability, and recovery requirements with reasonable headroom. Then use production evidence to justify the next change.
This guide is the parent for Raff’s VM Machine Classes cluster. Continue with Raff General Purpose VM Plans Explained, HiMem VMs Explained, or Shared vs Dedicated vCPU depending on the resource question you need to answer next.