Compute server means a physical machine built for processing work when a hardware vendor says it, and a virtual instance you rent by the hour when a cloud provider says it - and the difference matters because only one of them is something you can resize on a Tuesday afternoon.
The term shows up in two very different catalogues, which makes searching for it confusing. Once the layers are clear, the more useful question is the practical one: how much compute do you actually need, and how would you know?
Table of contents
- The layers, from metal upward
- What the specifications actually mean
- How to size without guessing
- When you genuinely need to go lower
- The default worth starting from
- How this fits the rest of the stack
- FAQ
The layers, from metal upward
- Physical server. Actual hardware - CPUs, memory, storage, network cards - in a rack. What a hardware vendor sells. Bought or leased, sized in advance, changed with a maintenance window.
- Bare metal instance. The same thing rented by the month from a provider, with no hypervisor between you and the hardware. Full performance, no neighbours, and provisioning measured in minutes to hours rather than seconds.
- Virtual machine. A slice of a physical host, partitioned by a hypervisor. What most people mean by a server now. Resized in minutes, billed by the hour or second, and sharing the underlying hardware with other tenants.
- Container. A process with its own filesystem and namespace, running on a shared kernel. Lighter than a VM, starts in under a second, and what modern application platforms actually run.
- Function. A single unit of code executed on demand with no persistent instance at all.
Each layer down gives more control and more responsibility. Each layer up gives faster iteration and less to operate. Most web applications belong at the container layer and end up lower because the decision was never made explicitly.
What the specifications actually mean
Three numbers get quoted and only one of them is straightforward.
vCPU is a slice of processor time, not a core. Depending on the provider it may be a hardware thread, a full core, or a fraction with a burst allowance. Two vCPUs from different providers are not comparable, and fractional allocations - a tenth of a vCPU on an entry plan - are real and appropriate for low-traffic services but will not run a build.
Memory is the one that behaves as you expect and the one that most often decides everything. Exceeding it does not slow your application down, it kills the process. Most instance sizing is really memory sizing with CPU along for the ride.
Storage varies in the dimension people forget: throughput and IOPS, not just capacity. A database on a volume with low IOPS is slow in a way that no amount of query optimisation fixes, and the symptom looks like a mysterious application problem.
How to size without guessing
- Start smaller than you think and measure. Instances are trivially resizable at the virtual layer, which means over-provisioning up front is a pure cost with no benefit. Deploy, watch, adjust.
- Watch memory first. Peak resident memory under real traffic, plus headroom. If the process is being killed, this is why, and no other number matters until it is fixed.
- Check whether CPU is actually the constraint. It usually is not. Slow applications are usually waiting - on a database query, on an external API, on disk - rather than computing. Adding CPU to a waiting process changes nothing, and this is the most common wasted upgrade.
- Separate the database. If the application and the database share an instance, they compete for memory and I/O, and the resulting performance is worse than either would have alone. Moving the database to its own managed instance frequently resolves what looked like a sizing problem.
- Size for normal, scale for peak. Provisioning permanently for your busiest hour means paying for idle capacity the rest of the time. Autoscaling between a sensible floor and a ceiling you choose is the better shape.
When you genuinely need to go lower
There are real reasons to want a machine rather than a container, and they are specific.
Sustained heavy computation where hypervisor overhead is measurable in your actual benchmarks. Specific hardware - GPUs, unusual accelerators, a particular storage configuration. Software licensed per physical core, where virtualisation makes the licence impossible or ruinous. Workloads that are not web applications: game servers, mail servers, VPN endpoints, build agents. Or a compliance requirement that names the architecture.
What is not a reason: the application feels slow. Before renting hardware, find out what is slow. In the overwhelming majority of cases it is an unindexed query, a chatty ORM issuing hundreds of queries per request, an uncached external call, or oversized assets - all of which cost exactly the same on faster hardware, and none of which are fixed by it.
The default worth starting from
For a web application: containers on a managed platform, sized on measured memory, with autoscaling between a floor and a ceiling, and the database on its own managed instance connected over a private network.
That arrangement removes the contention between application and data, makes resizing a change rather than a migration, and keeps the option of dropping to a lower layer if a specific requirement ever appears. Keep configuration in environment variables and state off local disk, and dropping a layer stays a decision rather than a rewrite.
How this fits the rest of the stack
Sizing is much easier when the plans are published and the line items are separate, because then it is arithmetic rather than negotiation. The RunxBuild hosting calculator shows the service plan, the database, the storage, and the bandwidth so you can size against measured numbers. RunxBuild’s ladder runs from a $4 Dev plan at 0.3 vCPU through Standard at 4 vCPU and 8GB, with autoscaling between plans you choose, and managed MySQL and Postgres on private networking so the database is not competing with the application.
Useful related references:
- Private Compute Service: What the Enterprise Brochure Means and What Builders Actually Want
- What Is an FTP Server, and Should You Run One in 2026?
- How to Set a Static IP on Ubuntu Server with Netplan
- Services on RunxBuild
FAQ
What is a compute server?
It depends who is speaking. Hardware vendors mean a physical machine built for processing workloads. Cloud providers mean a virtual instance you rent, billed by the hour or second. The practical difference is that one is sized in advance and the other is resized in minutes.
What is a vCPU actually?
A slice of processor time, not necessarily a core. Depending on the provider it may be a hardware thread, a full core, or a fraction with burst allowance, so vCPU counts are not comparable across providers. Fractional allocations are real and suit low-traffic services but will not run builds.
How do I size a server for my application?
Start smaller than you expect and measure, since virtual instances resize easily. Watch peak memory first, because exceeding it kills the process rather than slowing it. Check whether CPU is genuinely the constraint - usually the application is waiting on a query or an API, not computing.
Why is my application slow even on a bigger server?
Because the bottleneck is almost never CPU. Unindexed database queries, an ORM issuing hundreds of queries per request, uncached external API calls, and oversized assets all cost the same on faster hardware. Profile before upgrading; the upgrade usually changes nothing.
Should the database run on the same server as the application?
No. They compete for memory and I/O, and the result is worse than either would perform alone. Moving the database to its own managed instance over a private network frequently resolves what appeared to be an application sizing problem.