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 by the hour.
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 each started hour they run — about EUR0.22 for the one-hour test in the worked example below, since deploy and teardown push the fleet into a second started hour. Hourly billing flips the arithmetic — you spin up load test servers hourly, run the campaign, and the meter stops at the end of the hour you destroy it in. 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/60GB, EUR10/mo) running the k6 or Locust master, collecting metrics and coordinating workers.
- Worker nodes: 20x VPS I (2GB/1vCPU/20GB, 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 distribution from the 26 Linux and FreeBSD images and bake a cloud-init script that installs k6, pulls your test script from git, and registers with the controller on boot.
Deploy takes about a minute per node, so 20 nodes provisioned in parallel are generally all reachable within a few minutes — you're testing, not waiting on infrastructure. Full spin-up-to-teardown details and current tier specs live on the KVM 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 unmetered traffic, so there's no transfer quota to blow through mid-test — but each worker's port is shaped by plan (100 Mbps on VPS I up to 300 Mbps on VPS VI), so size the fleet to keep per-node bandwidth from becoming your bottleneck. Every instance also includes 100 Gbps of Layer 3/4 DDoS protection against inbound attacks — see the network page for how our network is connected. Because that outbound load can still trip the target's own defenses, only test systems you own or are authorized to test, and warn the target's hosting provider or CDN before the run.
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 is the controller's EUR0.0139/hr plus 20x EUR0.0056/hr for the workers — about EUR0.13 per started hour, or about EUR0.25 for the one-hour test once deploy and teardown push it into a second started hour, since every started hour of runtime is billed as a full hour. 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 about a minute, and includes 100 Gbps 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 bills monthly from EUR209, so keep it as the fixed target while the hourly worker fleet comes and goes.
FAQ
Can I really bill load-testing VPS by the hour instead of the month?
Yes — Noded's hourly VPS tiers bill by the hour until the instance is destroyed, starting at EUR0.0056/hr for the entry tier. Every started hour counts as a full hour and a month is capped at 720 hours, so a fleet that is up for less than an hour costs one hour per node.
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?
Your outbound test traffic is unmetered and limited by each plan's port shape (100–300 Mbps per VPS); the 100 Gbps Layer 3/4 DDoS protection included on every Noded VPS covers attacks against your instances. Only load-test systems you own or have permission to test, and warn the target's hosting provider or CDN so their own protection doesn't block your workers.
What's the fastest way to provision a disposable test fleet?
Deploy from one of the 26 Linux and FreeBSD images with a cloud-init script that installs your load-testing tool and registers with a controller on boot. Deploy time is about a minute 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.