What ships in the developer preview.

Seeded traffic profiles

Declare explicit phases, or a spiky, random_bursts or sustained_burst profile that compiles into phases from the seed. inspect with a seed shows the resolved phases before anything runs. Repeat a scenario across consecutive seeds with verify --repeat 3, or hold the seed fixed with --same-seed to measure run-to-run noise; the series summary reports min, max, mean and standard deviation of p95, error rate and throughput.

Budgets, declared up front

An overrun makes the verdict error. Budgets are declared bounds checked before and after the run, not hard containment: only max_seconds is enforced while k6 runs, so keep isolation on the target side too.

Run-owned starting state

• Owned HTTP fixtures. Before k6 starts, the controller sends POST create_path, reads the new ID by JSON Pointer and passes it to the script as LT_FIXTURE_ID. Afterwards it sends DELETE, even when the run stops on an unexpected error.
• Command fixtures. When the app has no create and delete endpoints, setup and teardown argv lists (for example psql -f seed.sql) run on your machine without a shell. Teardown always runs once setup was attempted.
• Fixture pools. A JSON array with one item per journey, such as a session or a cart; the script reads its own item with lt.poolItem().

Final observations

After the journeys finish, a read-only GET checks the state they left behind, compared by JSON Pointer with literals or matchers (eq, gte, lte, len, exists). With until, it re-reads an eventually consistent app until it converges or the deadline passes.

"observation": {
  "path": "/reports/ledger",
  "assertion": "ledger_matches_fixture",
  "expected": {"/total": 1000, "/regions/west": {"gte": 100}},
  "until": {"deadline_seconds": 20, "interval_seconds": 1}
}

Tenant-isolation kit

Describe two identities, the resources each owns and the endpoints that reach them in a small JSON config. init writes a complete scenario, deterministically, so the same config always gives the same digest.

litetraffic init tenant-isolation --config examples/tenant_api/kit.json --out my-isolation
litetraffic verify my-isolation --target http://127.0.0.1:8769

The generated scenario checks own_access, cross_tenant_read_blocked, cross_tenant_write_blocked and victim_unchanged, which catches a server that answers 403 but applies the write anyway. Declare markers, seeded values only one identity's data contains, and it also catches private data returned in a denial body.

Evidence and a report

Each run gets its own directory under .litetraffic/runs/ with run.json, result.json, the sequenced assertion events, raw k6 metrics and console output, and a standalone report.html. artifacts.json is written last and lists every file with its size and sha256. Declared secrets and minted tokens are replaced with [redacted] in everything kept. With verify --capture docker:api,worker, the run also records those containers' logs, CPU and memory peaks and collapsed error signatures, without ever changing the verdict.

A local dashboard

litetraffic dashboard serves your runs on http://127.0.0.1:8780/: an overview, a filterable run list, each run's assertions, observations, metrics and artifacts, per-scenario p95 over time, and a side-by-side comparison of two runs. It is read-only, always binds to 127.0.0.1, uses only the Python standard library at runtime and never contacts a target.

Every option is in the scenario reference; what is not shipped yet is on the roadmap.