ComparisonMicrocks turns specs into mocks: drop in your OpenAPI, AsyncAPI, or gRPC contract and Microcks generates a server you can hit. Gostly starts the other way around — record real upstream traffic and replay it. Both are good products that optimise for fundamentally different starting positions.
Microcks is the spec-driven OSS mocking engine. CNCF Incubating, Apache 2.0, Java/Spring Boot. You write (or import) an OpenAPI, AsyncAPI, gRPC, GraphQL, or SOAP contract and Microcks stands up mocks plus a test runner that validates consumers and providers against that contract. The async-messaging story is its standout wedge — very few open-source mocking tools cover Kafka / AMQP / MQTT alongside REST in one engine.
Gostly is built around a different starting assumption: most teams do not have a clean spec to import. They have a real upstream that already serves traffic, and the fastest path to a usable mock is to record an hour of that traffic and replay it. So Gostly ships as a single Rust binary you put in front of your upstream, runs in LEARN mode for an hour, then flips to MOCK mode and serves recordings. AI fills any gap — but grounded by the recordings, not by a free-text prompt.
Where Microcks expects you to know the contract upfront, Gostly assumes you don’t — and would rather discover it from production behaviour. Where Microcks runs a Spring stack, Gostly is one binary with no JVM. Where Microcks is multi-protocol today (REST + AsyncAPI + gRPC + GraphQL + SOAP), Gostly is HTTP-only with gRPC and async messaging on the roadmap.
We don’t recommend ripping out Microcks if it’s working — especially if you’re using its async transports. The interesting test is the inverse: take a service Microcks doesn’t have a contract for, point Gostly at the real upstream for an hour, and see whether the recorded JSONL gives you a usable mock without hand-authoring a spec.
$ docker run -p 8080:8080 \
-e BACKEND_URL=https://your-staging-upstream.example.com \
ghcr.io/nicrios/gostly-proxy:latest
# 1. Point your client at http://localhost:8080
# 2. Run your test suite (or live traffic) for an hour
# 3. Flip mode to MOCK — replays from recorded library
# Want a spec at the end? Export what you recorded:
$ gostly export --format openapi > generated-spec.yaml
The OpenAPI exporter is the on-ramp back to Microcks if you decide you want spec-driven afterwards: you walked in with no contract, walked out with one generated from real behaviour.
Single binary, language-agnostic, recording-first. Run it against your staging upstream for an hour and see whether it produces a mock you trust without ever touching an OpenAPI file.
Evaluating for a team of 3+? We’d love to talk before you commit.