Comparison

Microcks vs Gostly

Microcks 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.

Feature comparison

FeatureMicrocksGostly
OSS licenseApache 2.0 (Java)FSL → Apache 2.0 in 2y (Rust)
Single-binary installNoYes
Spec-driven workflow (OpenAPI / AsyncAPI / gRPC / GraphQL)first-class — the wedgeOpenAPI import; AsyncAPI / gRPC roadmap
Records mocks from real upstream trafficNodefault workflow
Async messaging mocks (Kafka, MQTT, AMQP)first-classHTTP-only
gRPC server-side mockingshippingroadmap
Contract testing (consumer-driven)shipping (test runner)No
AI gap-fill grounded by your trafficNoYes
JVM-free runtimeNoYes
CNCF governance / vendor-neutralIncubatingNo
SAML / RBAC / audit logMicrocks Hub Enterpriseroadmap (2026)
Chaos / fault injectionlimited (latency, error code)shipping (latency, status, Markov chains)

Roadmap items are explicitly labelled. Async messaging, gRPC, and contract testing are 2026 roadmap on Gostly’s side, not shipping today.

Choose Microcks when

  • You already maintain a clean OpenAPI / AsyncAPI / gRPC contract and want mocks generated from it.
  • You need async messaging mocks (Kafka, AMQP, MQTT, NATS) alongside REST. This is the strongest reason to pick Microcks today — almost nothing else covers it well.
  • You want contract testing as a first-class workflow — Microcks runs the contract against both consumers and providers.
  • CNCF / vendor-neutral governance is a procurement requirement.

Choose Gostly when

  • You don’t have a clean contract to import — and you’d rather record an hour of real traffic than spend a week authoring one.
  • Operability matters: you want a single Rust binary, not a JVM + Postgres + Keycloak stack to size and tune.
  • You want AI gap-fill that matches your endpoint’s shape from your traffic, not LLM-prompted hallucinations or hand-rolled examples in a spec.
  • Your services span Python, Node, Go, Ruby, Rust — anything not JVM-first.

The clean dividing line

If your team already has the spec: Microcks is the conservative, mature choice. The contract becomes the source of truth, mocks are derivative, and the same artifact drives consumer-side validation. Adding async transports is genuinely best-in-class.

If your team has the upstream but not the spec: Gostly inverts the usual order — the traffic becomes the source of truth, the recorded JSONL becomes the diffable artifact, and the spec (if you still want one) is generated by export from what you already recorded. Faster TTFV when the contract isn’t already documented.

These aren’t contradictions, they’re different orderings of the same tetris pieces. We’ve heard from teams who run both: Microcks for the contract-first services, Gostly for the legacy ones nobody ever specced.

Pricing, side by side

TierMicrocksGostly
Free / OSSOSS (Apache 2.0) — fully featured, self-hostUnlimited services, OSS proxy (FSL)
Pro / SoloNo single-seat tier$10 / mo single user
TeamMicrocks Hub commercial — talk to sales$79 / seat / mo
Self-host / EnterpriseMicrocks Inc. paid support; OSS self-host always free$499 / mo Self-host · $25K+ Enterprise

Microcks OSS is unambiguously the deepest free offering in this space — everything is in the OSS distribution and the only paid surface is enterprise support. Gostly’s OSS proxy ships less than the full Gostly product (no AI, no dashboard, no team features) but everything in the OSS box is uncapped. If price-per-feature on the OSS axis is the only criterion, Microcks wins. If you want AI gap-fill or a dashboard, those live in Gostly’s paid self-hosted tiers.

Try Gostly alongside Microcks

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.

Try Gostly without writing a spec first

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.