> ## Documentation Index
> Fetch the complete documentation index at: https://qodex.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# How do I test staging without risking prod?

> Use separate environments, read-only production rules, auth profiles, and rate limits to keep production safe.

# How do I test staging without risking prod?

Create separate Qodex environments for staging and production.

Then make production read-only, disable destructive tests, and rate-limit it. On the **Environments** page, edit production and tick **Read-only (skip destructive tests)**, then set **Max requests / second**. Qodex reads those constraints before authoring and enforces read-only in chat and during runs.

## Recommended production settings

| Setting | Recommended value | Why |
| - | - | - |
| `read_only` | `true` | Refuses every request except GET, HEAD, and OPTIONS, apart from the configured login. |
| `allow_destructive_tests` | `false` | Skips scenarios tagged `destructive`. |
| `max_requests_per_second` | `5` | Sets a low request-rate ceiling for the target. |

With these settings, production can still receive safe checks such as security headers, TLS, CORS, and read-only authorization probes.

## Recommended staging settings

Use staging for deeper checks that may create, update, or delete test data.

| Setting | Recommended value |
| - | - |
| `read_only` | `false` |
| `allow_destructive_tests` | `true` |
| `max_requests_per_second` | `20` |

This is the right place for write-side IDOR, mass assignment, injection checks, and full regression coverage.

## Keep credentials separate

Auth profiles are environment-specific.

A scenario can ask for the `admin` profile, but Qodex resolves the actual credentials from the environment selected for that run. Keep staging admin credentials and production admin credentials separate.

## If someone targets production by mistake

Production environment constraints still apply.

* In chat, a write request to a read-only host is refused, and so is a browser click that reads as destructive, such as delete.
* In a run, scenarios tagged `destructive` are skipped with the reason `skipped: environment is read-only`, and the run shows **SKIPPED**, not **PASSED**.
* Only a person can turn read-only off, on the **Environments** page. The agent cannot change it for you.

Schedules pick their environment from a dropdown of the project's real environments, so a typo cannot point a nightly run at the wrong target. Check which environment each schedule uses under **Test > Test runs > Schedules**.

## Next steps

> [card] [Auth profiles](https://qodex.ai/docs/api-testing-auth-profiles.md)
>
> Store environment-specific credentials.

> [card] [Sensitive endpoints](https://qodex.ai/docs/security-testing-sensitive-endpoints.md)
>
> Protect risky routes during testing.

> [card] [Inverted semantics](https://qodex.ai/docs/security-testing-inverted-semantics.md)
>
> Understand security test pass/fail behavior.

> [card] [OWASP API Top 10](https://qodex.ai/docs/security-testing-owasp-api-top-10.md)
>
> See common API security checks.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.