Testing and CI
Use a separate configuration for functional tests when your test tools would trigger runtime defenses. There is no separate testing endpoint or dashboard environment.
Functional test configuration
Derive the testing configuration from your shared settings and apply these overrides after selecting a preset. They disable the VM and basic versions of self-defending, debug protection, and domain lock. Pass explicit values; omitting an option can let a preset enable it.
CI
Run the original code first, then run the obfuscated testing build through the same checks. Record the input, effective options, obfuscator version, and build warnings so failures can be reproduced.
After functional checks pass, generate a separate release artifact from the original production settings. Validate that exact artifact in its intended runtime, on an allowed domain, without automation or debuggers that its defenses are designed to detect. Passing the testing build does not validate the protected release.
UI, CLI, and API builds use the same protection options. API testing uses the usual credentials and endpoint, and normal usage limits apply. In CI, keep test and release outputs in separate paths and deploy only the release artifact.
If execution still fails, see Diagnosing VM Runtime Errors.