Every distributed load test has the same shape: a burst of intense demand for compute, followed by nothing. You need 20 worker nodes hammering an endpoint for 45 minutes, then you need zero. Renting distributed load testing VPS hourly instead of on a monthly contract is the only pricing model that actually matches that shape — you pay for the window you use, not the idle month around it. This is a walkthrough of how we provision and tear down a disposable k6/Locust/JMeter worker fleet on Noded, billed to the second.
Why monthly VPS billing is the wrong tool for load testing
Monthly billing was built for infrastructure that runs continuously — a web app, a database, a game server. Load-test workers aren't that. They exist for one test window, sometimes recurring weekly, sometimes a one-off before a launch. Paying a full month for a fleet of 20 worker nodes that only run for one hour means paying for roughly 729 hours of idle time per node you never touch.
The numbers make the gap concrete: 20x VPS I nodes (EUR4/mo each) would run about EUR80 for the month whether you use five minutes of it or all of it. The same 20 nodes at the hourly rate (EUR0.0056/hr each) cost about EUR0.11 for the one-hour test in the worked example below. Hourly billing flips the arithmetic — you spin up load test servers hourly, run the campaign, and the meter stops the second you destroy the instance. There's no month-long tail, no "just leave it running so we don't have to reprovision," and no finance conversation about a server nobody remembers ordering.
Building a distributed load testing VPS hourly fleet: a 20-node worked example
Say you're validating a checkout API before a release and want 20 worker nodes generating load against a staging endpoint for a one-hour window, orchestrated from a single controller.
- Controller node: one VPS III (8GB/2vCPU/120GB, EUR10/mo) running the k6 or Locust master, collecting metrics and coordinating workers.
- Worker nodes: 20x VPS I (2GB/1vCPU/40GB, EUR0.0056/hr) — enough per-node headroom for a k6 or JMeter agent generating HTTP load without becoming the bottleneck itself.
- OS: pick a minimal Linux template from the 41 available and bake a cloud-init script that installs k6, pulls your test script from git, and registers with the controller on boot.
Median deploy time across the fleet runs about 47 seconds per node, so 20 nodes provisioned in parallel are generally all reachable within a couple of minutes — you're testing, not waiting on infrastructure. Full spin-up-to-teardown details and current tier specs live on the hourly VPS page.
Sizing workers for k6, Locust, and JMeter
The three tools have different resource appetites, which matters when you're self-hosting the load generators instead of paying a SaaS load-testing vendor by the virtual user:
| Tool | Typical bottleneck | Suggested tier |
|---|---|---|
| k6 (Go runtime) | CPU-bound at high VU counts | VPS I or II per worker — k6 self-hosted VPS setups scale well horizontally rather than needing bigger boxes |
| Locust (Python) | Single-process GIL limits per-worker throughput | VPS I workers, more of them, one Locust worker process per vCPU |
| JMeter (JVM) | Memory-heavy, especially with listeners enabled | VPS II or III — jmeter distributed testing VPS nodes need more RAM headroom than k6/Locust equivalents |
In all three cases the pattern is the same: run distributed to keep any single node from becoming the load generator's own bottleneck, and disable unnecessary listeners/logging on JMeter workers so disk I/O doesn't skew your latency numbers.
Bandwidth and DDoS protection during a load test
A load-test fleet generating sustained outbound HTTP traffic can look, from a network security perspective, uncomfortably similar to an outbound DDoS. Every tier includes 1 Gbps unmetered symmetric bandwidth, so the workers themselves aren't bandwidth-capped mid-test, and free 1 Tbps DDoS protection on every instance means your own traffic patterns are understood as legitimate load rather than misread and throttled. That protection runs on our own network — see the network page for the backbone details — so there's no third-party scrubbing layer introducing latency variance into your results.
Running the test and reading results without noise
Root SSH access on every node means you're not fighting a managed platform's restrictions to install agents, tune kernel network parameters (like net.core.somaxconn or ephemeral port ranges), or pull raw logs off a worker mid-run. For test windows where you also need a stable, high-throughput target environment to test against — not just the workers generating load — a single dedicated box gives you a fixed baseline free of noisy-neighbor variance; details are on the dedicated servers page.
Once the run finishes, pull metrics off the controller node, then destroy the fleet. There's no cleanup debt: no lingering monthly invoice, no forgotten VPS still billing next quarter because someone forgot to cancel it.
What this actually costs
Using the worked example above — one VPS III controller and 20 VPS I workers for a one-hour test — the compute cost for that hour is the controller's hourly-equivalent rate plus 20x EUR0.0056/hr for the workers, rounded to the second of actual runtime. Run it again next sprint, or run it for four hours instead of one, and the bill scales linearly with the clock — never with a monthly minimum you didn't ask for.
How Noded Can Help
We built hourly billing specifically for workloads like this one — infrastructure that exists for a test window and nothing longer. Our VPS hosting lineup runs from EUR0.0056/hr up through six tiers, deploys in a median of 47 seconds, and includes free DDoS protection and root access on every instance, so you can provision a full k6, Locust, or JMeter worker fleet, run the campaign, and tear it down without a second thought about the invoice. If you're testing against infrastructure that needs a stable non-shared baseline too, our dedicated line is built to pair with the same workflow.
FAQ
Can I really bill load-testing VPS by the hour instead of the month?
Yes — Noded's hourly VPS tiers are billed to the second from the moment an instance boots to the moment it's destroyed, starting at EUR0.0056/hr for the entry tier, so a fleet spun up for a one-hour test only costs that hour.
How many worker nodes do I need for a k6 or Locust load test?
It depends on target throughput and virtual user count, but as a rule of thumb, scale horizontally with more small nodes rather than vertically with fewer large ones — k6 and Locust workers are typically CPU-bound per process, so distributing load across nodes (20 is a common starting point) avoids any single worker becoming the bottleneck.
Will my load-test traffic get flagged or throttled as an attack?
Every Noded VPS includes free 1 Tbps DDoS protection running on our own network, which is built to distinguish legitimate high-volume traffic patterns — including load-testing traffic you generate yourself — rather than blanket-throttling anything that looks like a spike.
What's the fastest way to provision a disposable test fleet?
Deploy from one of the 41 available OS templates with a cloud-init script that installs your load-testing tool and registers with a controller on boot. Median deploy time is around 47 seconds per node, so a fleet of 20 nodes is typically ready within a few minutes of ordering.
Do I need a separate controller node for JMeter or k6?
Yes — run one node as the orchestrator/master collecting results and coordinating test start/stop, and size it a tier or two above the workers since it aggregates metrics from the whole fleet; a mid-tier VPS is generally sufficient for coordination duties alone.