Choosing safe test environments

import { Aside } from ‘@astrojs/starlight/components’;

Load testing is intentionally stressful. That is the point. But “intentionally stressful” in the wrong environment — or without proper authorization — can cause real outages, corrupt production data, send unwanted emails to real users, or trigger rate limits on third-party APIs you did not intend to hit. Choosing the right environment and getting proper authorization are the first decisions in every load test design.

Staging vs production

The choice between staging and production depends on what you are trying to learn and what you can afford to risk.

Factor	Staging	Production
Risk to real users	None (no real traffic)	High — load test traffic competes with real users
Data integrity	Safe — test data can be reset	Risky — test data may pollute real records
External APIs	Usually mocked or sandboxed	Real — may trigger costs, emails, notifications
Realism	Lower — caches colder, data smaller	Higher — real traffic patterns, full data volume
Authorization needed	Simpler — usually just your team	Requires cross-team coordination and change control

When staging is right

Staging is the default environment for performance testing and is where MaxoPerf is designed to shine. Use staging when:

You are developing and iterating on test scripts.
You are running regression tests in CI.
You have not yet established a production performance baseline.
Any risk of service degradation is unacceptable.

The trade-off: staging results may not perfectly predict production behavior, especially when staging databases are much smaller (fewer cache misses, different query plans) or when staging hardware is significantly under-provisioned.

When production is appropriate

Production load testing is sometimes the only way to get accurate results — especially for systems where staging is too different from production to be predictive. Before testing in production:

Notify all stakeholders — including on-call teams and the business (marketing, support).
Schedule during a low-traffic window — nights or weekends.
Start with a fraction of the target load — ramp slowly and monitor.
Have an abort plan — know exactly how you will stop the MaxoPerf run if real users are affected.
Isolate traffic if possible — use a separate subdomain, a canary target, or a shadow traffic pattern to avoid mixing test traffic with real user traffic in your logs and analytics.

Managed cloud locations vs private locations

MaxoPerf offers two types of runner locations:

Managed cloud locations — MaxoPerf’s own runner infrastructure in AWS/GCP regions. Traffic originates from known MaxoPerf IP ranges. Use for external-facing services. See the Private locations concept page for the full list of managed regions.
Private locations (Outpost) — your own runners, deployed in your infrastructure, behind your firewall. Traffic originates from inside your network. Use for internal services, behind-firewall targets, and VPN-only endpoints. See Private datacenter Outpost test for the setup recipe.

For internal APIs (accessible only from inside the corporate network or VPC), managed cloud locations cannot reach the target. You need private locations.

Blast radius: third-party APIs and email

A subtle source of incidents: your application under load may call third-party APIs, send emails, charge payment methods, or trigger webhooks — and load testing amplifies all of these.

Before running a load test in any environment, audit your scenario for:

External API calls: payment processors, email providers, SMS gateways, analytics SDKs. These may have rate limits, per-request costs, or real-world side effects. Replace them with mocks or sandbox accounts in staging.
Email and notifications: a 1 000-VU test that each triggers a welcome email will attempt to send 1 000 emails. Make sure staging email senders are sandboxed.
Database writes: writes to a shared database can corrupt test data or affect other teams’ tests. Use isolated schemas or test-data namespaces.
Webhooks to external systems: if your system sends webhooks to CRM, ticketing, or ERP systems, your load test will trigger them in bulk.

Authorizing a load test

Every MaxoPerf load test should be authorized at two levels:

Technical authorization: you have confirmed that the target host (IP, domain, or internal endpoint) is one you are permitted to test. If the target is behind a WAF or a DDoS-protection service, allowlist MaxoPerf’s IP ranges for the test window to avoid false positives.
Organizational authorization: you have notified the target team, your on-call rotation, and any stakeholders who would be paged or affected. A brief Slack message and a calendar invite is usually enough for a staging test; a formal change ticket is standard for production.

Do / don’t

Do	Don’t
Use staging as the default environment for all development-phase and CI performance tests.	Assume staging results perfectly predict production — document the known differences.
Get explicit authorization from the system owner before running any load test.	Run load tests at “low enough” VU counts without authorization, assuming small tests are harmless.
Audit the scenario for third-party calls, email sends, and payment events before running at scale.	Run a load test that exercises payment flows without confirming sandbox mode is active.
Use private locations (Outpost) for internal or behind-firewall targets.	Attempt to reach internal services from managed cloud locations — they will not be reachable.
Have an abort plan: know how to stop the MaxoPerf run quickly if something goes wrong.	Start a 2-hour soak test in production without a monitoring dashboard and an on-call engineer watching.

Where to go next

Private locations — deploying Outpost runners for internal targets.
Private datacenter Outpost test — step-by-step setup for private-location load tests.
What is performance testing? — the lifecycle and goals of a MaxoPerf run.
Safe and ethical load testing — a deeper treatment of the ethical and legal dimensions.