WireMock alternatives: pick the one that fits your problem

We build proxymock at Speedscale. It’s a WireMock alternative for dependency mocks built from recorded traffic and replay checks against code changes. Keep the WireMock stubs that already cover useful cases. Choose an additional tool for the workflow your test needs.

WireMock alternatives by task

Other dimensions to compare: proxymock runs as a local CLI and in Kubernetes through the Speedscale operator, and its replay supports virtual users and percentile assertions for load tests. WireMock and MockServer give explicit control over matching and fault simulation. Microcks is Kubernetes-native with a Helm chart and also runs locally. WireMock OSS runs locally; WireMock Cloud is a hosted product. Licensing differs: WireMock OSS and Microcks are Apache 2.0, while proxymock is a proprietary CLI with free-use eligibility and paid plans.

For the recorded-traffic workflow, proxymock captures inbound requests as replayable tests and outbound exchanges as dependency mocks. Replay sends the saved requests to your changed application while mocks supply the downstream responses. The complete-loop tutorial uses the public mock-lab apps to show that boundary, fault injection, and a simulated contract change. A recording supplies a compatibility baseline; review it before treating it as correct behavior.

WireMock’s own recording and playback can be enough for HTTP stubs. The decision is whether you also need the application replay and dependency-mocking workflow. For local proxymock use, follow the activation guide; non-interactive CI requires proxymock Pro or Speedscale Enterprise.

Check the gap in your current tests

Start with the behavior your existing tests cannot exercise. Recording, contract generation, request matching, and fault injection overlap across these tools. Compare the complete workflow, not the feature name.

AI coding agents need evidence about the dependency. An agent working only from an outdated specification can produce stale fixtures. MCP support provides an interface to tools; it does not establish the accuracy of the artifacts those tools expose. Evaluate whether the agent can inspect recorded exchanges and verify the changed application, as well as create explicit edge cases.

Stub drift. A saved response can remain unchanged after the real provider changes a field or error code. That affects recorded fixtures as well as handwritten stubs. Check them against fresh traffic or a live contract test when the dependency changes.

Your dependencies need different protocol support. WireMock has a gRPC extension, so it is not limited to ordinary HTTP stubs. Database wire protocols and event-driven dependencies still need their own evaluation. Test the operations and clients you actually use against each tool.

WireMock Cloud licensing. WireMock OSS and the commercial Cloud product have different deployment and collaboration models. Match the current plans to your request volume, team controls, and hosting model before relying on the free tier for shared CI.

Fixture maintenance. Compare how the tool creates, reviews, refreshes, and shares fixtures. WireMock supports recording; replacing it does not automatically remove that maintenance work.

What to keep WireMock for

Keep the WireMock tests that already establish useful behavior:

• Contract tests where you need to assert on a specific edge case (a malformed payload, a 503 from one endpoint, a timeout on a particular header value). WireMock’s request matchers and fault simulation let you define those cases explicitly.
• APIs that don’t exist yet. If you’re building a client against a spec for an API the other team hasn’t shipped, you don’t have anything real to record. Hand-written WireMock stubs from the spec are the right move until the real API is up.
• HTTP-only services where stub drift is already managed. If your team owns both sides of the contract and the test suite catches mismatches at the boundary, WireMock with hand-written stubs is fine. Adding a recording-based tool is overhead you don’t need.

Add another tool when a specific test needs a different capture, protocol, or replay workflow.

What hand-written stubs look like

Just so we’re calibrated on the starting point. A WireMock stub for one endpoint, in a JUnit 5 test:

@RegisterExtension
static WireMockExtension wm = WireMockExtension.newInstance()
    .options(wireMockConfig().dynamicPort())
    .build();

@Test
void shouldGetPaymentStatus() {
    wm.stubFor(get(urlPathEqualTo("/payments/12345"))
        .willReturn(okJson("""
            {
                "id": "12345",
                "status": "completed",
                "amount": 99.99,
                "currency": "USD"
            }
        """)));

    PaymentStatus result = paymentClient.getStatus("12345");
    assertEquals("completed", result.getStatus());
}

This test checks the caller against one explicit response. A separate provider check is needed to establish that the real API still returns that shape.

If my test needs a handwritten HTTP stub, adapt the WireMock payment example to a local server with the exact method, path, request fields, and response shape. Add a meaningful client assertion and a negative case.

The map: which tool fills which gap

For agents using recorded traffic, evaluate proxymock

proxymock exposes recording, mocking, and replay controls through its Model Context Protocol tools. An agent can inspect captured exchanges, run the application against dependency mocks, and replay requests to check a change.

proxymock mcp install

Follow the prompts to choose a detected client. Use proxymock mcp install --help to check the flags supported by your installed build.

MCP support is shared across products. WireMock Cloud exposes mock management and recording to agents. MockServer also documents MCP integration. Microcks exposes supported API mocks as MCP tools, which is a different role from controlling a recording session. Compare the tools and artifacts each integration exposes.

For local proxymock workflows, recordings remain in your workspace by default. Follow the installation guide for activation and the language-specific proxy and TLS setup. Non-interactive CI requires proxymock Pro or Speedscale Enterprise. Review recordings before sharing them.

Install proxymock's MCP integration using the supported command for my coding assistant. Verify the server runs from the application directory and list the available recording and replay tools.

For recorded dependency mocks and application replay, use proxymock

Record a known workflow, serve the captured outbound responses as dependency mocks, and replay the inbound requests against the application. This supplies a compatibility baseline for the interactions you exercised. Refresh it when the dependency changes.

For a Java service on port 8080, first complete the Java proxy and TLS setup and activate the CLI. Then record into a fixed directory:

proxymock record --app-port 8080 --out ./proxymock/recorded -- java -jar myapp.jar

In another terminal, exercise the app through the inbound recording proxy:

curl http://localhost:4143/api/payments/12345

Stop recording, then start the application with its saved dependency mocks:

proxymock mock --in ./proxymock/recorded --no-passthrough -- java -jar myapp.jar

While that application is running, replay the saved inbound requests from another terminal:

proxymock replay --in ./proxymock/recorded \
  --test-against http://localhost:8080 \
  --test-config standard \
  --fail-if 'requests.failed != 0'

This gate fails only when a request fails. A changed status code or response field does not trip it, so add test-config assertions or goals for the responses you care about before treating it as a regression check. Dynamic values such as IDs and timestamps need reviewed assertions or transforms first.

The mock step serves the recorded outbound responses and the replay step sends the recorded inbound requests, both read from the same directory. Re-record into an empty directory so earlier pairs are not mixed in. --no-passthrough makes an unmatched mock fail instead of reaching the live dependency. HTTP and gRPC exchanges can use the readable RRPair Markdown format; protocols without Markdown support use JSON. See the CLI quickstart for a complete demo app and the mock-lab walkthrough for failure scenarios.

When no traffic exists yet, proxymock can generate examples from supported OpenAPI or proto contracts. Treat generated responses as examples until you verify them against a real implementation.

Record my Java payment app on port 8080 into ./proxymock/recorded and request /api/payments/12345 through the recorder listener. Restart with that dependency recording and passthrough disabled, replay the saved inbound requests to the app, and inspect explicit failure gates and result artifacts.

For protocol coverage, verify the actual dependency

proxymock documents workflows for HTTP, gRPC, database, and messaging dependencies. Capture, analysis, and replay support are separate capabilities. Check the technology matrix and your actual driver, TLS configuration, operations, and query sequence. For gRPC, check unary and streaming behavior separately.

For HTTP mocking in a Java test, see WireMock vs MockServer vs proxymock.

For contract-driven mocks, evaluate Microcks

Microcks builds mocks and tests from supported API contracts and examples, including OpenAPI, AsyncAPI, GraphQL, gRPC, Postman collections, and SOAP/WSDL. It runs locally as well as in Kubernetes. Start with its local setup tutorial and OpenAPI mock example.

The CNCF lists Microcks as an Incubating project. That is governance context, not evidence that a particular simulation matches your provider. Review examples, dispatch rules, and conformance checks against your own service.

For automation, use the current Microcks CLI import documentation. The command needs an existing instance and endpoint configuration; authentication depends on the deployment. Follow the installed CLI’s syntax and the instance’s access settings.

WireMock Cloud also documents agent skills and MCP recording tools. Confirm current availability of each AI feature with the vendor.

Other WireMock alternatives

These tools differ in how mocks are authored, where they run, and what the test can observe. The links below point to their current documentation.

MockServer. It supports recording HTTP traffic as replayable expectations, alongside matching and verification. Its current docs also cover MCP and gRPC. Check those capabilities against the version you deploy.

Mockoon. It offers a desktop editor, HTTP proxy recording, and a CLI with Docker and CI support. Evaluate how recorded routes represent the response variations your tests need.

Beeceptor. It offers hosted API mocks and documents CI/CD and private deployment options. See the pricing page for plan limits and the documentation for supported API formats.

Prism. The standalone open-source project provides local mock-server and validation-proxy workflows from API descriptions. SmartBear acquired Stoplight, but Prism remains a separately usable CLI. Evaluate it when an OpenAPI-driven HTTP mock or validation proxy fits the test.

Postman. Its current mock workflows include hosted mocks and code-based mocks that run locally. The CLI documents postman mock run for CI/CD. Check which workflow your Postman version and account support.

Apidog. It supports local, cloud, and self-hosted Runner mocks. Local mocks depend on the desktop app remaining open; Runner deployments provide a different automation path. Check current plan terms for the deployment and team size you need.

MSW (Mock Service Worker). Its Node integration supports intercepting requests in a Node process, including backend integration tests. It also supports browser workflows. Evaluate whether process-level request handlers fit your test boundary or whether your application needs a separate network service.

LocalStack. It emulates AWS services locally, which makes it relevant when the dependency is an AWS API. Current AWS-image licensing requirements include an account, auth token, and applicable license. Confirm commercial-use and CI eligibility before relying on it.

Hoverfly. It documents HTTP(S) capture and simulation, with exportable recordings. Captured fixtures still need review and refresh. Community size is not a substitute for checking whether its current behavior meets your test.

Mountebank. Its official project supports service virtualization and proxy recording modes, as well as explicit stubs. Check the built-in protocol or extension required by your dependency.

What I’d actually do

Keep useful WireMock tests. Add proxymock when you need captured dependency responses together with a replay baseline for application changes. Compare Microcks or Prism when API descriptions should drive the mock, and check local execution, CI setup, and licensing for the deployment you intend to use.

Try one representative request with the actual client and dependency behavior. Verify matching, failures, dynamic values, and expected responses before moving a larger suite. The WireMock export example is one way to retain existing WireMock workflows while creating mappings from recorded traffic.

Try proxymock

Install with brew install speedscale/tap/proxymock, then run proxymock init for activation. Follow the CLI quickstart for runtime, proxy, and TLS setup. To expose tools to a supported coding agent, run proxymock mcp install and follow its prompts. Check the activation guide for CI requirements.

For a runnable recording and regression example, use the complete loop with mock-lab. The WireMock vs MockServer vs proxymock comparison covers the HTTP test boundary.

Use an LLM for a scoped task

Use this prompt to work through the relevant example in your project. Choose the applicable tool or environment before making changes.

Read https://speedscale.com/blog/wiremock-alternatives/ and inspect my project instructions first. Choose the mocking boundary required by my backend test. For recorded-dependency testing, record a local Java payment workflow, run the app from that recording without passthrough, and replay the same inbound requests with explicit gates. Preserve the recording and report coverage limits. Check installed tool help before adapting commands. Report the checks actually run, their results, and anything you could not verify.