Cloud VM machine classes are standardized server categories that group CPU, memory, and storage profiles for different workload patterns.
For developers and small teams, the hard part is rarely finding a cloud server. The harder decision is choosing the right kind of server before you know exactly how your workload will behave. A web app, a database, a CI worker, a self-hosted automation tool, and a game server may all run on virtual machines, but they do not stress the machine in the same way.
Raff Technologies designed its VM plans around this practical decision: some workloads need balanced resources, some need more CPU, and others need more memory per core. Raff’s current visible machine plans include 3 Gbps port speed, unmetered bandwidth, 1 IPv4, and optional IPv6 dual-stack, so the machine-class decision is mainly about matching compute, memory, and storage to the way your application behaves.
This guide is part of the broader Cloud VM Hosting Guide series. It explains the main machine-class patterns, where each one fits, and how to choose a VM class without overpaying too early.
Machine classes exist because workloads fail in different ways
A VM class is not just a pricing label. It is a resource pattern.
One server may fail because the CPU is constantly saturated. Another may fail because the application runs out of memory. A third may have enough CPU and RAM but not enough disk space for logs, databases, files, or containers. Looking only at vCPU count can create the wrong decision because two VMs with the same CPU count can behave very differently if one has twice the memory or storage.
Most cloud VM plans are built around a few recurring workload shapes:
- Balanced workloads that need a reasonable mix of CPU, RAM, and storage
- Compute-heavy workloads that need stronger processing capacity
- Memory-heavy workloads that need more RAM per CPU core
- Storage-sensitive workloads that grow because of databases, logs, uploads, or container images
The goal is not to buy the largest VM you can afford. The goal is to choose the smallest machine class that gives your workload enough headroom to operate reliably.
That distinction matters for small teams. Oversized infrastructure quietly burns budget. Undersized infrastructure creates slow applications, failed deployments, crashed services, and frustrated users. A good VM class sits between those extremes.
General Purpose VMs fit balanced application workloads
General Purpose VMs are the default starting point for many cloud workloads because they provide a balanced mix of CPU, memory, and storage.
They are usually the right first choice when your application does not clearly lean toward heavy compute or heavy memory usage. A typical web application, backend API, admin dashboard, small database-backed app, staging environment, or self-hosted tool often fits this pattern.
Choose a General Purpose VM when your workload looks like this:
- It serves web traffic or API requests
- CPU usage rises and falls with normal user activity
- Memory usage is stable and predictable
- Storage grows gradually rather than aggressively
- You want a practical starting point without over-engineering
For example, a small SaaS dashboard, Laravel app, Node.js API, Django backend, WordPress site, monitoring dashboard, or internal business tool can often begin on a General Purpose plan. These workloads need enough of everything, but they usually do not need extreme specialization on day one.
The main risk with General Purpose VMs is treating them as universal. They are flexible, but not magic. If your workload spends most of its time compiling, rendering, encoding, analyzing, or processing large jobs, a CPU-optimized class may be better. If your workload keeps large datasets in memory, runs heavy databases, or depends on caching, a high-memory configuration may be safer.
CPU-Optimized VMs fit processing-heavy workloads
CPU-Optimized VMs are designed for workloads where processing power is the limiting factor.
These workloads do not simply sit and wait for users. They actively calculate, build, compress, test, render, transform, or process tasks. In those situations, CPU capacity has a direct effect on completion time and responsiveness.
Choose a CPU-Optimized VM when your workload looks like this:
- Build jobs or test suites take too long
- Background workers process queues continuously
- Application performance depends on computation
- You run scraping, parsing, encoding, or transformation jobs
- CPU usage regularly stays high during normal operation
Common examples include CI runners, code compilation environments, automation workers, analytics jobs, video or image processing tasks, game servers, simulation workloads, and backend services with heavy business logic.
A CPU-optimized machine can reduce job duration and improve consistency under load. However, it is not always the right answer. If the application is slow because it is waiting on disk, database queries, external APIs, or memory pressure, adding more CPU may not solve the real bottleneck.
This is why machine-class selection should start with the workload pattern, not the plan name. CPU-optimized plans are valuable when CPU is the constraint. They are wasteful when the constraint is elsewhere.
High-memory configurations fit databases, caches, and memory-sensitive apps
High-memory configurations provide more RAM relative to CPU.
This matters because many applications slow down or fail when they do not have enough memory, even if CPU usage looks normal. Once a server starts relying heavily on swap space or begins killing processes because memory is exhausted, application performance becomes unpredictable.
Choose a high-memory configuration when your workload looks like this:
- The application holds large datasets in memory
- Database queries benefit from larger memory buffers
- Cache hit rates matter for performance
- Containers or services consume significant RAM at idle
- Memory usage grows before CPU becomes the bottleneck
Databases are the clearest example. PostgreSQL, MySQL, Redis, Elasticsearch-style tools, analytics dashboards, and data-heavy applications can often benefit from additional memory. More RAM can allow more data to stay close to the application, reducing repeated disk reads and improving responsiveness.
High-memory plans are also useful for self-hosted platforms that run multiple services on the same VM. Some automation tools, observability stacks, collaboration platforms, and low-code tools may not look CPU-heavy, but they can consume memory quickly as usage grows.
The risk is buying memory without understanding the workload. If memory usage is low and CPU is always saturated, a high-memory configuration will not fix the bottleneck. The right class depends on what the application actually needs to stay stable.
The machine-class decision should follow workload behavior
The simplest way to choose a VM class is to identify what your workload consumes first when it is under pressure.
| Workload pattern | Common examples | Main constraint | Best starting class |
|---|---|---|---|
| Balanced web app | Websites, APIs, dashboards, admin panels | Mixed CPU and memory | General Purpose |
| Compute-heavy service | CI jobs, workers, testing, encoding, parsing | CPU | CPU-Optimized |
| Memory-heavy app | Databases, caches, analytics tools | RAM | High-memory configuration |
| Small experiment | MVPs, side projects, demos, test servers | Budget and simplicity | Entry General Purpose |
| Production backend | SaaS apps, customer-facing APIs | Reliability and headroom | General Purpose or CPU-Optimized |
| Multi-service VM | App + database + queue + monitoring | Memory and storage | General Purpose HiMem |
| Game or real-time workload | Multiplayer servers, simulation services | CPU consistency | CPU-Optimized |
| Data-heavy workload | Logs, uploads, database growth | Storage and memory | High-memory or larger General Purpose |
A useful rule of thumb is this: choose General Purpose when you need balance, CPU-Optimized when job speed depends on processing power, and high-memory when stability depends on keeping more data in RAM.
For early-stage projects, the safest decision is often not the biggest server. It is the most honest server. Pick the smallest class that fits the known workload, then resize when usage data proves the need.
A practical decision framework for choosing the right class
Use this framework before selecting a machine class.
| Decision question | Choose this direction |
|---|---|
| Is this mainly a web app, API, dashboard, or simple backend? | Start with General Purpose |
| Does the workload run heavy builds, workers, or processing jobs? | Consider CPU-Optimized |
| Does the app crash, slow down, or swap because of RAM pressure? | Consider a high-memory configuration |
| Are you hosting a database on the same VM? | Prefer more memory and storage headroom |
| Is this a side project, MVP, or temporary environment? | Start smaller and resize later |
| Is this production infrastructure with paying users? | Leave more CPU, RAM, and storage headroom |
| Is traffic unpredictable? | Choose a balanced class first, then observe usage |
| Is the monthly budget tight? | Avoid oversized plans until metrics justify them |
This framework prevents two common mistakes.
The first mistake is choosing based only on price. The cheapest VM can become expensive if it causes downtime, failed jobs, or slow user experience.
The second mistake is choosing based only on fear. Buying a large VM before the workload needs it can hide performance issues while wasting budget. For many small teams, gradual resizing is better than guessing too high on day one.
A balanced starting point is usually enough when the workload is new. Specialization becomes more valuable when the bottleneck becomes visible.
Machine-class examples for common Raff users
Different Raff users tend to make different infrastructure decisions.
A freelance developer building client websites usually needs simple, reliable hosting with predictable cost. A General Purpose VM is often the right starting class because the workload is balanced and easy to resize later.
A student or beginner learning Linux, Docker, or backend deployment usually needs a low-cost environment rather than a specialized machine. The priority is access, simplicity, and experimentation. An entry-level General Purpose plan is usually enough.
A DevOps engineer running CI workers or automation tasks may care more about job completion time. If builds, tests, or scripts are the bottleneck, CPU-Optimized plans become more attractive.
A startup team hosting a production API should think about headroom. If the API is lightweight but user-facing, a General Purpose plan with enough RAM and storage is a reasonable start. If the backend performs heavy processing, CPU-Optimized may be safer.
A team hosting a database, cache, or self-hosted productivity tool should pay close attention to memory. In those cases, a high-memory configuration can improve stability more than simply adding CPU.
The pattern is simple: the right class follows the pressure point of the workload.
Raff machine classes in context
Raff’s current visible VM lineup is built around two main machine-class families: General Purpose and CPU-Optimized. Within those families, several plans offer higher-memory configurations for workloads that need more RAM per CPU core.
General Purpose plans are designed for balanced workloads such as web applications, APIs, development environments, dashboards, and small production services. They are often the best default when the workload is not clearly specialized.
CPU-Optimized plans are designed for workloads where processing power matters more directly, such as workers, CI tasks, testing, game servers, and compute-heavy backends. These plans are useful when the application spends meaningful time executing CPU-bound work.
High-memory variants are useful when the memory-to-CPU ratio matters. Databases, caches, self-hosted tools, analytics services, and multi-service VMs often benefit from extra memory because they need to keep more data or more processes active at the same time.
Across the visible Raff machine plans, the standard infrastructure characteristics include 3 Gbps port speed, unmetered bandwidth, 1 IPv4, optional IPv6 dual-stack, and resize support. That means the key decision for most users is not whether the server includes basic networking capacity, but which CPU, memory, and storage profile best matches the workload.
The reason Raff structures plans this way is practical: small teams rarely know their final infrastructure shape at the beginning. A startup may begin with one balanced VM, then later separate the database, add workers, or move compute-heavy jobs to a different machine class. Starting with clear classes makes that path easier to understand.
Common mistakes when choosing a VM class
The most common mistake is buying only by vCPU count.
CPU matters, but it is only one part of performance. A 4 vCPU machine with too little memory can still struggle. A memory-heavy VM with underused RAM may not help a CPU-bound job. Storage can become a bottleneck if logs, images, Docker layers, backups, or databases grow faster than expected.
Another mistake is treating development and production the same way. A development VM can be smaller and less redundant because the cost of downtime is low. A production VM should have more headroom, better monitoring, and enough capacity to handle normal traffic spikes.
A third mistake is choosing the largest plan too early. This can make an application feel stable while hiding inefficient code, database queries, or background jobs. Right-sizing forces better decisions. If a smaller machine is consistently saturated, upgrading is justified. If a large machine is mostly idle, the budget is being wasted.
A fourth mistake is ignoring storage growth. Many teams size CPU and RAM carefully but forget that logs, uploads, packages, database files, and container images accumulate. For storage-sensitive workloads, the right class is the one that leaves enough disk headroom for growth, not just enough CPU for today.
Best practices for choosing a machine class
Start with the workload, not the plan table
Define what the server will actually do before comparing prices. A VM for a static website, a PostgreSQL database, and a build worker may all have the same monthly billing model, but they require different resource profiles.
Choose balance unless the bottleneck is obvious
General Purpose is usually the safest first choice when the workload is new or mixed. Specialize only when the application clearly needs more CPU or more memory.
Leave headroom for production workloads
Production servers should not run constantly near their limits. Sustained high CPU or memory usage leaves little room for traffic spikes, background jobs, updates, or unexpected demand.
Treat databases as memory-sensitive by default
Databases often benefit from more memory because caching, buffers, and active connections can affect performance. If a database shares the same VM with the application, memory headroom becomes even more important.
Review usage after launch
The first VM choice is an educated guess. Real usage should confirm or correct that choice. If CPU is consistently high, move toward CPU-Optimized. If memory is tight, move toward high-memory. If both are comfortable, avoid upgrading unnecessarily.
The right VM class is the one your workload can grow from
Choosing a cloud VM class is not about predicting the future perfectly. It is about making a clear first decision and leaving yourself a path to adjust.
General Purpose VMs are the right default for balanced applications. CPU-Optimized VMs are better when processing speed drives performance. High-memory configurations are safer when databases, caches, or multi-service workloads need more RAM. The best choice is the class that matches your current bottleneck without forcing you to overpay for resources you do not use.
For a broader view of cloud server planning, continue with the Cloud VM Hosting Guide. For the next practical decision, read Right-Sizing Cloud Servers or Cloud VM Storage Planning.
If you are choosing a server for a real project, Raff’s Linux and Windows VM plans let you start with a clear machine class, then resize as your workload becomes more predictable.