Comparison
Carbon vs WireMock
WireMock is the incumbent in the JVM world — a mature HTTP mock server with stub mappings, request matching, and record/playback. It has scenarios for stateful flows, which is a step above simple response mocking. Carbon takes a different approach: instead of hand-writing stub mappings and scenario transitions, you point it at a spec and get a stateful server for free.
Capability by capability
Rows below are checked against WireMock's public docs. Where support is "partial" we say what's actually there.
| Capability | Carbon | WireMock | Notes |
|---|---|---|---|
| State persistence across requests | Yes via "scenarios" — you define the states and transitions by hand. | ||
| Snapshots / rewind (state journal) | |||
| Chaos / failure injection | Fault injection, fixed delays, and random delays are supported. | ||
| Multi-format ingest (OpenAPI, GraphQL, HAR, Postman, gRPC) | OpenAPI import exists via extensions; gRPC support is separate. Check WireMock docs. | ||
| Local-first (runs on your laptop) | |||
| No hosted-service dependency | Self-hostable; WireMock Cloud is a separate paid option. | ||
| Framework glue (vitest, jest, playwright) | JVM test-framework integrations are first-class; JS glue is thinner. | ||
| Drift detection vs real API |
When to pick WireMock
- You are on the JVM and want JUnit-native lifecycle helpers.
- You already own hand-crafted stub mappings that describe exactly the traffic you want.
- You need WireMock-specific features like request-journal proxying against a real backend.
When to pick Carbon
- You do not want to hand-write scenario transitions to get stateful CRUD.
- Your team is JS/TS-first and would rather not run a JVM in local dev.
- You want snapshots, rewind, and drift detection as primitives, not add-ons.
Try Carbon against your own spec.
One command turns any OpenAPI, GraphQL, HAR, Postman, or gRPC spec into a stateful local server. See how it compares to WireMock on the endpoints you actually ship.