vouchfx samples

See vouchfx prove a real system.

Four production-shaped applications in four stacks — clone, run one command, and watch a complete end-to-end suite pass against real containers.

Run your first sample Migrating from Postman, xUnit or SpecFlow? GitHub repository

Samples pinned to the vouchfx engine commit in ENGINE_PIN · current engine release v1.0.0-alpha.7

The sample catalogue

Choose your stack.

Each sample is a real service — its own database, broker, or cache — driving one coherent business transaction through every hop, not four disconnected checks.

Orders

C#/ASP.NET · PostgreSQL, Kafka, webhook · 5 steps

Inventory

Python/FastAPI · MySQL, RabbitMQ, Redis · 5 steps

Payments

Java/Spring Boot · SQL Server, NATS, SMTP email · 4 steps

Ledger

Node.js JSON-RPC · PostgreSQL, Kafka + the Community provider rpc.json-rpc via a custom runner · 10 steps

Find the pattern you need

Every idiom, traced back to a real suite.

Not sure which sample answers your question? Jump straight to the pattern.

ORDERS Webhook listening ORDERS Engine-owned RETRY polling INVENTORY Cache read-through proof PAYMENTS Email capture PAYMENTS JetStream stream ownership LEDGER Community-provider consumption + custom runner

Beyond Core providers

Consume a Community provider today.

The stock vouchfx CLI ships only the 25 frozen Core providers. The ledger-jsonrpc sample is the reference pattern for consuming a hub provider before a provider-loader feature ships — a thin custom runner over the engine's public SDK (Vouchfx.Sdk 1.0.0-alpha.7), consuming Vouchfx.Community.JsonRpc 1.0.0-alpha.1 from NuGet.org.

The custom-runner recipe

The runnable code walkthrough: build and freeze the registry, discover suites, execute, map exit codes.

Using community providers

The hub's guide to compile-time discovery, NuGet pinning, and source builds.

The ledger-jsonrpc sample

See the recipe applied end-to-end: rpc.json-rpc alongside four Core providers, in one suite.

What proven means

Not "it compiled." Proven, live, against real containers.

1 exact engine commit pinned repo-wide in ENGINE_PIN — advancing it is a deliberate, reviewed action

4/4 samples validated live in CI, one matrix job per sample, against real Docker containers — never mocked

1× samples run sequentially, never concurrently, on one machine — each topology owns its own DCP-orchestrated network