Free VPS Options Compared: Limits, Real Benchmarks and When to Upgrade

Free VPS offers look generous on a landing page and behave very differently after the first month. Some are genuine long-running free tiers with hard quotas, some are 30-day credits that expire mid-project, and some are container sandboxes dressed up as virtual machines. This article compares the categories rather than the marketing pages, shows what a reproducible benchmark actually reveals on each, and gives concrete thresholds for the moment it makes sense to start paying.

The Three Categories Behind the Word “Free”

Almost every free VPS falls into one of three buckets. The first is a time-boxed trial credit: a fixed amount of money or a 30-to-90 day window, after which the instance either stops or converts to a paid plan. The second is a permanent free tier with usage caps — small instance hours, limited egress, and often the smallest shared-core shape on the provider’s menu. The third is a sandbox: a container, a CI runner, or a preview environment that gives you a shell but not a kernel you control.

The distinction matters because only the second category can host a long-lived service. Trials are for evaluation, not for production. Sandboxes usually cannot run systemd units, load kernel modules, or change sysctl values — which rules out most of the tuning work you would want to do on a real VPS. Check which you have before anything else: uname -r for a shared kernel, systemctl is-system-running for systemd, and cat /proc/1/comm to see whether your PID 1 is an init system or a shell script.

What the Limits Actually Cost You

Free tiers rarely limit the thing people watch — CPU. They limit egress bandwidth, outbound connections, disk operations, and the number of hours the instance may run. The egress quota is usually the binding constraint for anything that serves traffic, because a single image or package repository can consume a meaningful fraction of a monthly allowance in an afternoon.

Constraint	Typical free-tier shape	First symptom in practice
vCPU count	1 shared vCPU	Latency spikes under any concurrent load
RAM	512 MB – 1 GB	OOM kills during package upgrades or builds
Egress	Tens of GB per month	Throttled or metered bandwidth after the cap
Lifetime	30–90 day credit or indefinite small shape	Instance deleted or converted without warning
Control	Often container-only	No custom kernel, no systemd, no sysctl

Measure what you are given rather than relying on the shape description. A one-vCPU instance that reports a sustained baseline of a few percent steals is a different product from one reporting double-digit steal at idle. Both are labelled the same on the pricing page.

A Reproducible Benchmark Before You Trust Any Instance

Run the same three tests on every candidate and record the raw output. Nothing exotic is needed: a CPU-bound loop for consistent throughput, a small memory bandwidth test, and a disk write test with fsync, because free tiers often have the slowest storage in the catalogue. Keep the tests short so you can repeat them at different times of day.

# CPU: fixed work, measures delivered throughput
time -p sh -c 'i=0; while [ $i -lt 300000 ]; do i=$((i+1)); done'

# memory: bandwidth estimate in MiB/s
dd if=/dev/zero of=/dev/null bs=1M count=2048 2>&1 | tail -1

# disk: write with fsync, 64 MiB of 4 KiB blocks
fio --name=w --filename=/tmp/freewrite --size=64M --bs=4k \
    --rw=write --fsync=1 --iodepth=1 --runtime=20 --time_based

# steal, sampled twice 10 s apart
awk '/^cpu /{print $1, "steal="$9, "user="$2, "system="$4, "idle="$5}' /proc/stat

Look for consistency, not peak numbers. A free instance whose throughput varies by more than about 30 percent between runs is sharing a contended host, and no amount of guest-side tuning will fix that. The pattern to reject is a fast first run followed by a slow second run — that is burst credit being exhausted, and it will happen in production at the worst moment. For a deeper treatment of what steal means and how to isolate it from other slowdowns, see our article on measuring CPU steal time accurately.

What Free Tiers Are Genuinely Good For

Free instances are excellent for things that are idle most of the time and tolerate a slow wake-up: a DNS secondary, a monitoring probe, a webhook receiver, a cron runner that executes a few small jobs per hour, or a staging environment for configuration testing. They are also the cheapest way to learn a provider’s control panel, image quality, and network before committing money.

They are a poor fit for anything with a memory-resident dataset, a build pipeline, a database with real write volume, or a public website that must stay responsive. The failure mode is not usually a hard outage; it is gradual degradation as the instance swaps, the egress cap approaches, and the provider’s shared storage queues build up under other tenants’ load.

What You Give Up on a Free Tier

Beyond raw resources, free tiers usually strip the operational features that make a server safe to run: snapshots, private networking, IPv6, backups, and any meaningful support channel. Some also prohibit commercial use or require a payment method on file where a misconfigured cron job can generate a bill far larger than the server itself. Read the egress metering rules specifically — the free allowance often covers inbound traffic only.

The other hidden cost is migration friction. A free instance that you have configured for eight months is still an instance you must rebuild elsewhere when the terms change. Treat anything you deploy on a free tier as disposable: keep provisioning in version control, keep state in a database or object store you control, and assume the machine can vanish.

When a Free Tier Is Enough

A free tier is sufficient when all of the following hold: the workload is idle most of the day, the monthly egress stays comfortably under half the cap, the service tolerates a few hundred milliseconds of added latency, and there is no state you cannot reconstruct. If any of those is false, you are already past the point where the free instance saves money — you are paying in incident time instead. A useful sanity check is to log peak RSS, 95th percentile response time, and monthly egress for two weeks and compare against the caps.

# peak memory of a service over time
systemd-cgtop --iterations=1
# egress since boot, in bytes
awk 'NR>2 && $1!~/lo/ {rx+=$2; tx+=$10} END {print "tx MiB:", tx/1048576}' /proc/net/dev

When to Upgrade, and the Signals That Force It

Upgrade on measurements, not on calendar. The signals that reliably force a move are: sustained steal above a few percent while your own CPU sits idle, swap activity with no memory leak, egress consistently above half the allowance, and response time degrading linearly with concurrency because one vCPU is the ceiling. Any one of those means the free tier is now the bottleneck rather than the budget line.

When you do move, size for the workload you measured plus headroom for the next growth step, and pick a plan with explicit CPU guarantees rather than another shared shape. The differences between plans at the low end are much larger than the price difference suggests, and a comparison of what each price band actually delivers is worth reading before you commit — see our breakdown of VPS plans and what each tier includes.

A Practical Decision Checklist

• Confirm the instance is a VM with its own kernel, not a container sandbox.
• Identify whether the offer is a trial credit or an indefinite capped tier.
• Run the four benchmark commands above at two different times of day and compare variance.
• Log egress and peak RSS for two weeks against the published cap.
• Keep the deployment reproducible so the machine can be replaced in an hour.
• Set a threshold — steal above a few percent, or egress above half the cap — that triggers migration.

Free VPS hosting is a legitimate way to run small, idle services and to evaluate providers. It stops being free the moment your workload needs sustained CPU, predictable latency, or more than a trickle of outbound bandwidth. Measure early, set thresholds, and move on before the instance’s limits become your outage.