The WireMock alternative — no JVM, no hand-written stubs
WireMock gives you 15 years of JVM stub DSL and, now, an MCP server that generates stubs from a prompt or spec — a plausible guess at what the API returns. Gostly is a self-hosted platform in your own perimeter — a Rust proxy plus control plane and dashboard — that records your real upstream and replays it byte-for-byte. No JVM to size, no Kubernetes, and an empty library on day one is solved by seeding from HAR, Postman, or OpenAPI.
WireMock OSS has been mocking HTTP since 2011 and has earned its mindshare honestly. The stub-matching DSL is one of the most expressive in the field, the JUnit story (@WireMockTest) is genuinely best-in-class for Java teams, and WireMock Cloud layers collaboration, OpenAPI bidirectional sync, and a chaos UI on top. If your service is a Spring Boot app and your developers already think in builders, WireMock is the conservative choice and often the right one.
Gostly is built around a different starting assumption: most teams do not want to author stubs at all. They want the mock to come from the traffic their service is already serving. So Gostly puts a Rust proxy in front of your upstream and runs as a self-hosted stack in your perimeter (Docker Compose); in LEARN mode it records for an hour or so, then flips to MOCK mode and replays it byte-for-byte — including HTTPS. There is no JVM to size and tune, and no Kubernetes to operate.
Both products now have an AI story, but the two answers are not the same. WireMock ships an MCP server, so an AI coding agent in your IDE (Cursor, Copilot, Claude) can generate stubs from a prompt, your source, or an OpenAPI spec — a fast, plausible synthesis of what the API might return. Gostly starts from the opposite end: its mocks are recorded from your real upstream, byte-for-byte, and AI only fills the gaps the recordings did not cover, mimicking the patterns it already saw. Generated-from-a-spec is a great way to scaffold quickly; recorded-from-reality is the one you reach for when the response has to match what production actually sends.
The pain WireMock teams describe most is drift. A stub someone wrote six months ago keeps returning 200 OKlong after the real API changed — the tests stay green, and production breaks. Gostly re-records the upstream and diffs it against what you captured, so it flags a stale mock before an incident does. Worth knowing, too: WireMock OSS hasn’t shipped a stable feature release since 3.12.0 in February 2025 — v4 has been in breaking-change beta for over a year, so the recording loop you’d rely on is effectively in maintenance mode.
And because it runs as your own single-tenant deployment, the controls a security review asks for are built in: SSO via SAML or OIDC, role-based access control, and an append-only audit log on Team. The deployment is single-tenant with per-tenant RLS policies, and your recorded traffic never leaves your perimeter — none of it on someone else’s cloud. The trade-off is real, too: WireMock’s stub DSL is deeper, its matchers are sharper, and its JUnit ecosystem is mature in ways Gostly is not yet.
WireMock’s MCP server writes your stubs from a prompt or a spec it has never actually called. An AI guessing the response shape is still a guess. Gostly’s mock is the recording: the same bytes your real upstream sent, replayed byte-for-byte.
payments-api · upstream OFFLINE
UPSTREAM OFFLINE✓ 29 / 29 GREEN
$ docker stop upstream-api # kill the real API
upstream-api stopped
$ pytest tests/ -v # replayed from Gostly
tests/payments::test_list_customers PASSED
tests/payments::test_get_customer PASSED
· · · · · · · · · · · · · · · · · · · ·
========= 29 passed in 0.85s =========
↳ 0 live calls — served byte-for-byte
take the upstream offline — the recorded library still serves, 0 live calls
Feature comparison
Feature
WireMock
Gostly
OSS core
Apache 2.0 (Java)
FSL (Rust)
No JVM, no Kubernetes (Docker Compose)
No
Yes
Stub authoring DSL (programmatic)
deep, mature
basic; record-first
Records mocks from real upstream traffic
via proxy mode
default workflow, byte-for-byte
Captures real HTTPS / TLS traffic
proxy mode (own cert)
records HTTPS, fingerprint-matched outbound
JUnit / pytest / Jest helpers
JUnit excellent
pytest + Jest planned
OpenAPI bidirectional sync
Cloud only
import shipping
gRPC
Cloud + OSS extension
roadmap
Library on day one (no recordings yet)
Author every stub by hand first
Seed from a HAR / Postman / OpenAPI file — full library before you record
AI-assisted stub creation
MCP: your IDE agent generates stubs from a prompt or spec
AI gap-fill grounded by your recorded traffic
Mocks are ground truth (recorded, not generated)
proxy-mode recording is
default — recorded byte-for-byte
Stateful flows
Scenarios — one stub per state, in-process only
Recorded statechart — POST then GET-by-id just works
SAML + OIDC SSO, RBAC, append-only audit log on Team
Roadmap items are labelled explicitly. Statecharts (stateful flows), live drift detection, Markov chaos, and SSO / RBAC / audit log ship today; gRPC stays 2026 roadmap on Gostly’s side. AI gap-fill on Gostly is opt-in and grounded by your recordings, not a free-text prompt.
Choose WireMock when
→Your services are JVM and you want @WireMockTest JUnit integration.
→You compose stubs programmatically and want a deep, expressive matcher DSL — 15 years of it.
→Advanced request matching (regex, JSONPath, XPath, custom Java matchers) is part of your test design.
→You need gRPC today and the WireMock gRPC extension fits your toolchain.
→You want your IDE’s AI agent to scaffold stubs from a prompt or spec without leaving the editor — WireMock’s MCP server is built for exactly that.
Choose Gostly when
→You want a self-hosted stack you run with Docker Compose — no JVM to size and tune, no Kubernetes to operate.
→You’d rather record an hour of real traffic than hand-author a week of stubs.
→You need deterministic, byte-for-byte replay in CI — the same bytes every run, with no model in the path.
→You want mocks recorded from your real upstream — ground truth — and AI only to fill recorded gaps by mimicking patterns it saw, not to generate responses from a prompt and hope they match.
→You need SSO (SAML/OIDC), role-based access, and an append-only audit log on Team — single-tenant, in your own perimeter, with data that never leaves it.
WireMock Cloud’s Team plan meters per request, so the right shape depends on traffic volume: at low request counts the metered plan is the value choice, while at the request volumes most CI fleets land on, the per-request meter compounds and Gostly’s flat seat price wins. WireMock OSS self-hosts free, as does the Gostly OSS proxy; both ship a paid self-host tier for support and gated features.
No empty library on day one
The objection that kills most WireMock switches is “I have a whole mappings/directory and no Gostly recordings yet, so I’d be starting from zero.” You aren’t. Drop a HAR capture, a Postman collection, or an OpenAPI spec into the dashboard and Gostly seeds a working mock library before you proxy a single request — the same library your recorded traffic lands in. Then real traffic sharpens it to ground truth. A hand-authored stub is only ever as right as what you remembered to type.
gostly.internal / cold-start seeding
cold-start seeding 47 MOCKS · SERVING
⤓
drop a HAR · Postman · OpenAPI file
payments.har — 47 entries · 312 KiB
HARPostmanOpenAPI
✓ GET /customers/:id — seeded
✓ POST /charges — seeded
✓ GET /invoices — seeded
· flip to MOCK — a full library on day one
no empty library — seeded before you record a single call
In the dashboard, open Cold-start seeding, drag in the file, pick the service, and commit. The mocks land in the same library your recorded traffic does — flip the proxy to MOCK and they serve immediately. Then run your real test suite through the containerized proxy in LEARN mode to sharpen it to ground truth. No JVM, no DSL, no host CLI — the whole flow lives in the dashboard and the proxy.
Try Gostly without the JVM
Self-hosted, language-agnostic, recording-first. Run it against your staging upstream for an hour and see whether it produces a mock you trust.