​

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

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. 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