How we test VPS servers: every script, setting and limit

How we test VPS servers: we rent each server ourselves, run one script on a fresh Ubuntu install, and publish what it measured, including errors. The script, bench.sh, covers CPU, memory, disk, network, CPU steal, Docker, Supabase and Ollama. A second script, n8n_load.sh, load-tests a real n8n workflow. A full bench.sh run took about 10 minutes on the Hetzner CX43 and about 15 on the CX23.

This page lists every setting, so you can judge our numbers and repeat them. It belongs to our VPS benchmarks; the rules for writing about results are in the editorial policy.

Tested in the Lab Hetzner CX23, CX33, CX43, CAX11, CAX21 · Nov 2026

What bench.sh measures

It runs as root on a new server. First it enables ufw with only SSH open, then records the OS, kernel, CPU model, vCPU count (virtual CPU cores the provider assigns) and RAM used before anything is installed.

All four fio runs use a 2G test file, --direct=1 (bypassing the page cache, so we measure the disk, not RAM), the libaio engine and 30 s time-based runs.

Ollama details. Every model gets the same prompt about what a VPS is, with num_predict 256 (a 256-token answer), temperature 0 and seed 42, so runs are as repeatable as possible. We send the request twice. Run 1 gives load time and RAM with the model loaded. Run 2, with the model warm, gives tokens/s, computed from Ollama's own eval_count and eval_duration. A token is the unit a model reads and writes, usually a word or part of a word. Each request may take up to 900 s; the model is then unloaded with keep_alive 0. If a model does not run, we publish the error instead of a number.

Here is what the system tests produced on our five Hetzner servers:

Measured by AI Hosting Lab on 2026-11-05 · 5 servers · method · raw data

What n8n_load.sh measures

It installs n8n 2.46.6 with Postgres 16 using the same images as our production server, creates an owner account and API key through n8n's REST API, and activates one workflow: Webhook → Code node (running in a task runner) → response. After a warm-up of 200 requests at 5 concurrent, ApacheBench (ab) sends POST requests at 1, 10, 25 and 50 concurrent connections: 300 requests at concurrency 1, and 40 per connection above that. We record executions per second, median and 95th-percentile latency (95% of requests were faster), failed and non-2xx responses, and n8n's peak RAM sampled with docker stats.

The test talks to 127.0.0.1 without TLS, so it measures n8n and Postgres, not your network or the proxy. Results are published once all runs are complete:

Measured by AI Hosting Lab on 2026-11-05 · 5 servers · method · raw data

What we pay for

We rent every server on our own Hetzner account at the normal hourly rate, for example 0.0106 € per hour gross for a CX23, from the Hetzner Cloud API price list checked on 2026-11-05. Our production n8n server is a CX23 at 6.64 € per month. We never buy through our own affiliate links, and no provider pays for or reviews a test. See the affiliate disclosure for how links are handled.

Limits you should know

• One run per server. We have not repeated runs across days yet, so a number is one sample, not an average.
• Shared vCPUs vary. All five servers are shared-CPU plans. Steal was 0.0% during our 30 s window on all of them, but a neighbour can change that an hour later.
• One provider, one location. Hetzner, Helsinki (hel1) only, so far. Other providers are marked "not yet tested" until we run them.
• Two Ubuntu versions. Test servers ran Ubuntu 24.04; our production n8n server runs 26.04. We label which is which.
• CPU only, idle Supabase. No GPU tests yet, and Supabase is measured idle, not under load.

How results are published

Each run writes key=value lines and raw tool output (sysbench text, fio JSON, Ollama JSON). We store one JSON file per server and test under lab/results/, named by date, provider, plan and location, and combine them into one lab.json. Every table and chart on this site is rendered from that file at build time, so a number in an article cannot drift from the measurement. When we rerun a server, the page shows the new date.

Next step: see the results side by side in our VPS benchmarks.