Upgrade VPS resources: when to add CPU, RAM or disk

Deciding when to upgrade a VPS is mostly about reading the right signal. A slow site is not always a CPU problem, and adding RAM will not fix a full disk. This guide shows how to tell which resource is actually short, how to resize CPU, RAM or disk on a Cloudj server, what to do inside Linux after the disk grows, and how to plan the change so users barely notice.

Read the signals before you pay for more

Start with the metrics graphs on the server page in the Cloudj console, which show CPU, RAM and network over time. Then confirm from inside the server. Each resource has its own tell.

A few rules of thumb help with interpretation:

• One spike is not a trend. Look at a week of graphs, including your busiest day.
• Memory shown as "used" by the page cache is normal. Watch the "available" column, not "free".
• If the OOM killer has fired even once, you either need more RAM or a memory limit on the process that grew.
• High steal on a shared CPU plan means other tenants compete for the same cores. Moving to general purpose or dedicated CPU often helps more than adding vCPUs; our comparison of shared vs dedicated CPU covers that choice.

For continuous tracking rather than a one-off look, set up the tools in monitoring VPS resources.

Fix the cheap things first

Before upgrading, rule out problems that more hardware only hides:

• A runaway process or memory leak. top sorted by memory (Shift+M) shows it quickly.
• Logs filling the disk. sudo journalctl --vacuum-size=500M trims the journal, and logrotate should handle app logs.
• Old Docker images and build cache. docker system df shows how much space they take.
• A database without the right indexes, which looks like a CPU or I/O shortage.

If those are clean and the graphs still show pressure, it is time to resize.

Upgrade VPS CPU and RAM in the console

Cloudj lets you resize the CPU and RAM of an existing server from its page in the console. You can move to one of the ready-made plans or build your own mix of vCPU and RAM, up to custom sizes of 104 vCPU and 512 GB RAM.

1. Check the price of the target size on the pricing page. On hourly billing the new hourly rate applies after the change; on a prepaid term, check how the change is billed before you confirm.
2. Plan a short maintenance window. Treat a resize as an operation that restarts the server, and tell users if the service matters.
3. Stop write-heavy jobs and take a fresh off-server backup first. See our VPS backup strategy.
4. Run the resize from the server page and wait for the server to come back.
5. Confirm the new size from inside: nproc and free -h.

Most software picks up extra cores and memory automatically after a restart. A few need a config change to use them: database buffer sizes such as PostgreSQL shared_buffers or MySQL innodb_buffer_pool_size, PHP-FPM worker counts, Java heap size (-Xmx), and Node.js cluster worker counts.

Grow the disk, then grow the filesystem

Disk growth is a separate action in the console. In practice it is one-way: plan for disks that grow, never shrink, so add what you need for the next few months rather than everything at once.

After the disk grows, Linux sees a bigger block device, but the partition and filesystem still have the old size. Many cloud images expand the root partition automatically at the next boot. Check first:

lsblk
df -h /

If lsblk shows the disk larger than the partition, expand them by hand. The device is often /dev/vda or /dev/sda; read the name from lsblk and use your own:

sudo apt install -y cloud-guest-utils
sudo growpart /dev/vda 1

Then grow the filesystem. Find its type with df -Th /.

# ext4 (Ubuntu and Debian default)
sudo resize2fs /dev/vda1

# XFS (common on AlmaLinux and Rocky Linux)
sudo xfs_growfs /

On AlmaLinux and Rocky Linux, growpart is in the cloud-utils-growpart package and is installed with dnf. If the root filesystem sits on LVM, grow the physical volume and logical volume instead:

sudo pvresize /dev/vda3
sudo lvextend -r -l +100%FREE /dev/mapper/rl-root

Both growing steps work on a mounted filesystem, so no extra reboot is needed. Run df -h / again to confirm.

When resizing is not the answer

Vertical resizing has limits, and sometimes another move fits better:

• Users are far away. If the server is fine but pages feel slow abroad, the problem is distance. A second server closer to users, chosen with the VPS locations guide and measured with ping and mtr tests, helps more than extra cores.
• One component dominates. If the database uses most of the RAM, moving it to its own server often beats doubling the app server.
• Load is bursty. For short batch jobs, a temporary server on hourly billing that you delete afterwards can cost less than keeping a big server running all month.
• You want a clean start. Building a fresh server and moving the app over is sometimes simpler; see migrating a website to a new VPS.

FAQ

Will I lose data when I resize?

Resizing is not meant to touch your data, but any operation that restarts a server can expose problems such as an unclean shutdown. Take an off-server backup first, every time.

Can I make a server smaller later?

You can resize CPU and RAM as needs change. Disk only grows, so if you need a smaller disk, deploy a new server at the right size and move your data.

Why does my disk still show the old size?

The partition and filesystem were not expanded. Run growpart and then resize2fs or xfs_growfs as shown above.

Is more vCPU always faster?

No. A single-threaded workload uses one core at a time. For that kind of app, a dedicated or general purpose CPU type may matter more than the vCPU count.

Size it to what you measure

Resize when a week of graphs agrees with what you see inside the server, and change one resource at a time so you know what helped. Current sizes and live prices for every location are on the pricing page, and the resize controls are on each server's page in the Cloudj console.