How your limits work#
Your VPS plan sets the ceiling for CPU, memory, and disk, and your server runs within those limits the whole time it is online. CPU is shared across the underlying hardware, but we balance how plans are placed so total utilization stays low and your server has the headroom its plan promises. Knowing where you sit against each limit tells you when a workload is getting cramped and when you still have room to grow into.
CPU is measured in vCPU cores, memory in gigabytes of RAM, and disk in gigabytes of NVMe storage. The exact figures for your plan are listed on your service page, and they are the numbers the monitoring tools below will report from inside the machine.
Checking usage from inside the server#
Because a VPS is a full Linux machine, you check resource usage with the same tools you would on any server. Connect over SSH first, then reach for whichever tool matches what you want to see.
For a live view of CPU and memory load, run htop. It shows a per-core CPU meter, a memory meter, and a sortable list of processes so you can spot whatever is using the most. To see how much disk space each filesystem has left, run df -h, and to find which directories are eating that space, run du -sh * inside the folder you want to inspect.
# live CPU and memory load, per core
htop
# free disk space per filesystem, human readable
df -h
# disk used by each item in the current directory
du -sh *
# a quick one-shot memory summary
free -hIf htopis not installed yet, add it with your distribution's package manager, for example apt install htop on Debian or Ubuntu. For a snapshot rather than a live view, top is always present, and free -h prints memory use in one line.
When you start running low#
A server that sits near its memory limit will slow down once it starts swapping, and one that fills its disk can fail to write logs or databases. Watch for memory that stays close to the ceiling under normal load and for any filesystem in df -h creeping past roughly 90 percent in use. Both are signs the plan is becoming the bottleneck rather than your application.
Before upgrading, it is worth clearing out what you do not need. Old logs under /var/log, cached package files, and unused container images often reclaim a surprising amount of disk. If memory is the constraint instead, look at which processes htop ranks at the top and whether any of them can be tuned down.
Moving to a larger plan#
When clean-up no longer buys you enough headroom, the next step is a bigger plan. Plan changes, like every other billing action, happen in the billing portal at portal.pyro.host, which uses the same login as the rest of your account. From there you can review your current service and start an upgrade.
If you are not sure which size fits the workload you are running, reach out to support before you switch. We will help you read your current usage, pick the right plan, and walk through what changes once the upgrade takes effect.