Start with InfernoSIM

On this page

A free, open-source engine for backend, integration and agent reliability tests. Run it locally or in your own CI.

This entry point targets engine v4.0.1. The Azure extension has its own package versions; its customer-AKS operation is optional.

1. Install the engine#

Use Homebrew on a supported system:

brew install pranaysparihar/infernosim/infernosim

For other platforms, download a platform archive and checksums.txt from GitHub Releases. The Homebrew formula builds tagged source locally. Go 1.26.6 or newer is required for source builds; Docker is needed for the container examples, not for this local fixture check.

2. Inspect a synthetic fixture#

Start in an empty working directory. This public fixture contains one recorded GET /health response on the reserved example.test domain. It contains no customer data and verification makes no live request.

mkdir -p ./fixture
curl -fsS https://tryinferno.space/docs/infernosim-azure/fixtures/v1/incident.json -o ./fixture/incident.json
curl -fsS https://tryinferno.space/docs/infernosim-azure/fixtures/v1/inbound.log -o ./fixture/inbound.log
curl -fsS https://tryinferno.space/docs/infernosim-azure/fixtures/v1/openapi.yaml -o ./fixture/openapi.yaml
infernosim verify ./fixture

Expected result

With engine v4.0.1, this fixture exits 0 with replay readiness 100%, no unsafe requests, missing dependencies or expired tokens. verify is a safety inspection, not full application replay or a production guarantee.

3. Make a contract check#

infernosim contract ./fixture --spec ./fixture/openapi.yaml \
  --report-dir ./contract-report --report-formats junit,sarif,html

Expected result

The fixture exits 0 with PASS_CONTRACT and no violations. Inspect the JUnit, SARIF and HTML reports in ./contract-report. This checks the recorded exchange against its OpenAPI contract; it does not run your application.

Read the fixture’s scope and expected results.

4. Bring your own incident#

Backend incidents and CICapture and sanitize, review matcher proposals, validate contracts, and generate a test harness.API and integration testsSemantic request matching, stateful scenarios, response templates and OpenAPI drift checks.Agent reliabilityRecorded model/tool protocols, ambiguous commits, consequence assertions and CI evidence.Agent safety and recovery in 4.0.1Monitor faults, bound approvals, compensation, recovery and explicit schedules.

The versioned 4.0.1 safety guide extends the earlier baseline/single-fault workflow with optional bounded fault pairs and explicit schedules. Consult it for those capabilities.

Safety defaults#

Use an isolated target and sanitized data.

Replay skips write methods by default. Enable --allow-writes only when the isolated target’s data may be changed. Raw body capture can retain credentials or personal information. Review privacy policies before capture and treat incident bundles and command-output reports as sensitive.

Listeners bind to loopback by default. HTTPS interception and private-destination access require explicit opt-ins. Proxy environment variables alone are not a network sandbox; use OS or container isolation for untrusted applications or agents.

What the test establishes#

Recorded protocol replay makes the configured test repeatable; it does not make arbitrary live LLM behavior deterministic.
The side-effect ledger models the declared simulated effects. It is not an audit of a live payment provider.
Explicit schedules control simulated admission/commit order. They do not exhaust every possible race or control arbitrary OS threads and external databases.
Approval assertions are test predicates, not a production authorization service. A detected bad effect fails the test; it is not silently blocked and called safe.
Evidence hashes identify content. They are not digital signatures or compliance certification.

Next steps#

Read the complete engine reference, engine release notes and security guidance. For customer-AKS jobs, identity and retained evidence, see Azure editions and the Azure installation guide.