About & methodology
Who writes this
I'm Gigi, a backend and infrastructure developer. I've spent the better part of a decade shipping web applications, APIs and background workers onto Linux servers — bare metal, VPS, and the big clouds — and keeping them running. Choosing where to host a project always came down to the same frustrating search: marketing pages full of adjectives, benchmarks that never disclosed their setup, and "top 10" listicles ranked by affiliate payout.
Host or Die is my attempt at the resource I wanted: every provider put through the same deployment and the same measurements, with the method written down so you can reproduce it or poke holes in it. If a number here looks wrong, tell me and I'll re-run it.
How each provider is tested
Every review starts from a clean account and a fresh server in the provider's default configuration. Unless a review says otherwise, the test box is the cheapest plan with at least 1 vCPU and 1 GB RAM, running Ubuntu 24.04 LTS, in the region geographically closest to me. I provision it twice, on different days, and average the results.
The workload
A representative deployment goes on first: a Dockerised Node.js API in front of PostgreSQL, plus an Nginx reverse proxy with a Let's Encrypt certificate. This shakes out real-world friction — image pull speed, build time, whether the control panel fights you — before any synthetic numbers are collected. My step-by-step guide to deploying a Node.js app with Docker on a Hetzner VPS walks through the same deployment shape.
The measurements
| Metric | Tool | What it tells you |
|---|---|---|
| CPU, single & multi-core | sysbench cpu, stress-ng, 7z b | Sustained compute for build steps, request handling and background jobs; whether a "shared" vCPU throttles under load. |
| Disk I/O | fio (4K random read/write, 1M sequential) | Database performance, log-heavy workloads, and how honest the "NVMe" label is. |
| Network throughput | iperf3 to third-party endpoints, speedtest-cli | Real egress to other regions, not just the provider's own speed-test mirror. |
| Boot & provision time | systemd-analyze, API timestamps, wall clock | How fast you can scale out or replace a failed node. |
| Latency | ping, mtr, TTFB from three continents | Route quality and peering, not just distance on a map. |
Also noted, not scored
- Time from signup to a usable SSH session.
- Whether IPv6, private networking, snapshots and firewalls are included or billed as extras.
- Egress/bandwidth allowance and the overage price per GB.
- Support: a real ticket is opened during each review and the response time and usefulness recorded.
- Billing behaviour — hourly caps, minimums, and how hard it is to fully destroy a resource so it stops charging.
Ground rules
- No sponsored reviews. No provider is given copy approval, an embargo, or advance sight of a score.
- Affiliate links never move the ranking. Where a referral link exists it's used; where one doesn't, the provider is still covered. See the disclosure page.
- Numbers include their setup. Plan, region, date, kernel and tool versions are published with every result so you can re-run them.
- Reviews get revisited. Providers change hardware and pricing; dated updates are appended rather than quietly edited.
You can see the method applied end to end in the DigitalOcean vs Vultr comparison. Spotted a mistake or want a provider tested? Mail gigikakauridze1302@gmail.com.