Choosing a VPS plan and a Linux distribution

The right VPS plan is the smallest one that comfortably holds your peak workload plus a margin, not the biggest one you can afford. For a typical single-site WordPress or small web-app deployment, that usually means 2 vCPU, 4GB of RAM and 40-80GB of disk to start, sized up if you're running a database-heavy application or several sites on one server. For the operating system, AlmaLinux 9 is the stronger choice if you're running cPanel or want a long, predictable support cycle, and Ubuntu 24.04 is the stronger choice if you're comfortable with more frequent updates and prefer apt and a Debian-based toolchain. Both are solid choices on a Hostworld VPS. The decision comes down to how your workload actually behaves, not which distribution sounds more modern.

Before you start

This guide assumes you're deciding what to order, not troubleshooting a VPS you already have. Before you pick numbers, have a rough idea of three things: what the server will run (a single WordPress site, several sites, an e-commerce store, a custom application), roughly how many visitors or concurrent users you expect, and whether email will be hosted on the same server or handled elsewhere. You don't need exact figures. A workload category is enough to start with, and a Hostworld VPS can be resized upward later through Virtualizor without a rebuild, so getting it slightly wrong at the start is not a disaster.

Also decide where you want the server physically. We run our own data centre in Maidenhead, Berkshire for UK traffic, and a New York location for US traffic. Pick whichever is closer to most of your visitors, since that affects latency more than any spec you choose below.

Step 1: Size your RAM to the workload, not to a guess

RAM sizing is arithmetic, not a benchmark you copy from somewhere else. The principle is straightforward to state even if the numbers take some thought: add up what your applications actually need at their busiest (your "working set"), add what the operating system and any maintenance tasks need on top, then add 20-30% headroom so a traffic spike doesn't tip you into trouble. Undershoot this and processes get killed, your database ends up serving from disk instead of memory, or, on a container host, things get throttled. Overshoot it and you're paying for capacity that sits idle.

As a rough starting point across sources we trust:

• A minimal single service can run on around 1GB, though this is tight rather than comfortable.
• A production website or small application commonly needs 2-4GB.
• A database, a Docker host, a control panel like cPanel, or several services running together commonly needs 4-8GB or more.

Once a server is running, don't judge memory pressure by how much RAM shows as "free". Linux uses spare RAM as filesystem cache and hands it back the moment an application needs it, so a server showing very little free memory is not automatically undersized. The figure worth watching is MemAvailable, which estimates what can actually be used without swapping. On the server itself, this command shows both:

free -h

It prints total, used, free, and available memory in a readable format (the -h means "human-readable", so it shows GB rather than raw bytes). If available stays healthy and swap stays close to zero under normal load, your RAM is sized correctly, whatever the "free" column says.

Step 2: Match CPU to how many things happen at once

CPU sizing follows how much work runs concurrently, not how big your site is in isolation. As a general guide:

• 1-2 vCPU suits light workloads: a low-traffic site, a personal project, a development server.
• 2-4 vCPU suits a typical web application or a small database serving normal traffic.
• 4-8 vCPU suits a busy application or several services running on the same VPS.
• 8 or more vCPU suits heavy concurrent processing: large-scale queuing, video encoding, or a busy multi-tenant setup.

The mistake worth avoiding here is reaching for more CPU the moment a site feels slow. A slow database configuration, an oversized table that's never been indexed properly, or a handful of heavy plugins can dominate response time regardless of how many cores you throw at it. If a server is both swapping and running a database that's grown substantially since it was set up, that combination is the most common cause of "everything is slow", and the fix is usually to move up a tier or tune the database, not to add CPU and hope. Check swap activity and database performance before you spend money on extra cores.

Step 3: Size your disk with more than the operating system in mind

Disk requirements creep up in ways that are easy to miss when you're only thinking about the operating system and your application code. Rough bands:

• 20-40GB: the OS plus a typical single website or small application.
• 40-80GB: a WordPress site or e-commerce store with a reasonable amount of media, or a web application with a moderate database.
• 80-160GB: database-heavy applications, or multiple sites and apps sharing one server.

Email storage is the disk consumer people forget. One mailbox that keeps every attachment, order confirmations that pile up for years, and logs that rotate badly can all fill a disk quietly, and when a disk hits 100% the web stack often starts failing in ways that look unrelated to storage at all. If the VPS will handle mail as well as web traffic, size for that separately rather than assuming it's negligible.

It's also worth knowing before you commit: growing a disk upward later is comparatively low-risk when it's done in the right order, but shrinking one is not something to plan around. Shrinking a filesystem and then a logical volume in the wrong order can destroy data, and XFS, which is AlmaLinux's usual default filesystem, cannot be shrunk at all once created. Ubuntu's usual default, ext4, can be shrunk but still carries the same ordering risk. The practical takeaway is the same for both: size disk a little generously rather than tightly, because going bigger later is straightforward and going smaller is not something we'd recommend attempting.

Step 4: Choose between AlmaLinux 9 and Ubuntu 24.04

Both are supported on a Hostworld VPS, both work fine with cPanel and WHM if you're running web hosting rather than a bare server, and both are actively maintained. The honest differences are these:

If you're running cPanel or WHM, or you want a server you can leave alone for long stretches without a distribution upgrade, AlmaLinux 9 is the stronger pick. If you're comfortable applying updates more often and your tooling is built around apt or Docker, Ubuntu 24.04 is a reasonable choice with no real downside for a website workload. Debian is also available on a Hostworld VPS if you specifically need it, but it isn't covered in this comparison.

One detail that catches people out with AlmaLinux specifically: the major version (9) has support until 2032, but each minor version inside it reaches end of life the moment the next minor version ships. A server left unpatched can fall out of security support years before 2032 while still technically "running AlmaLinux 9". Keeping the minor version current is a matter of applying updates regularly, not a one-off install decision:

dnf update

This checks for and installs available package and kernel updates on AlmaLinux. There's no equivalent minor-version trap on Ubuntu 24.04, since its updates apply within the one LTS release rather than moving you between numbered minor versions.

As a floor rather than a working recommendation: AlmaLinux 9 will technically boot on around 1.5GB of RAM. That's not a sizing target, it's the minimum for the OS to start at all, which is exactly why Step 1 above matters more than any distribution's stated minimum.

Step 5: Plan to grow the plan later, not to shrink it

If you size conservatively and later need more room, that's a normal and low-risk change, not a sign you got it wrong. On a Hostworld VPS, resizing happens in two places, and they need to happen in order. First, the increase to the underlying virtual disk is done from Virtualizor, our VPS control panel: this is a platform-side action that enlarges the disk assigned to your VPS. Only after that has taken effect do you go into the operating system itself to extend the partition or LVM volume and then grow the filesystem to actually use the new space (with tools such as growpart, pvresize and lvextend, followed by resize2fs on ext4 or xfs_growfs on XFS). Doing the in-OS steps before the disk has actually been enlarged in Virtualizor achieves nothing, since there's no new space yet to extend into.

The genuine risk in this process isn't the growing itself, it's picking the wrong device or partition when running the in-OS commands, since they operate directly on block devices. If this is your first time resizing a VPS disk and you'd rather not do it unsupervised, open a support ticket and we'll talk you through the in-OS steps for your specific setup.

What next

Once you've settled on a plan and an operating system, the next step in this series is ordering and provisioning the VPS itself, then connecting to it over SSH for the first time. Take a look at our VPS guides for the full set, or go straight to Linux VPS to see current plans if you're ready to order.