When private load generation beats public runners

Public cloud runners are the simplest place to start for internet-facing applications. They scale easily, repeat easily, and reach the service the way many users do.

Private load generation serves a different case. Choose it when the target should not be reachable from the public internet, or when the test must stay inside a specific network boundary.

Common private-location triggers

Teams usually add private runners when one of these is true:

• the target API is only reachable from a private network;
• staging mirrors production but is not internet-exposed;
• compliance rules limit where traffic and test data can travel;
• the team needs to test east-west service paths;
• network latency from a managed region would distort the result.

MaxoPerf supports this pattern with private runner locations that connect back to the control plane. You see the test in the same console, and the traffic starts from the network you choose.

Keep blast radius explicit

Private runners sit close to sensitive systems. Handle them with the same care as any production-adjacent tool:

• test only authorized targets;
• keep load windows visible to the owning team;
• cap virtual users and request rate for the environment;
• record which location generated the run;
• review logs and results before repeating a failed profile.

Combine locations deliberately

A mixed plan often works best. Use managed locations to measure the public user experience across regions. Use private locations to validate internal APIs, partner paths, or systems that should never be public. Whatever you mix, write the location plan down before the run starts.