Mmock serves your mocked HTTP endpoints on two ports and a console

The workflow is six steps and it ends at a real server

Mmock is a testing and fast prototyping tool for developers, and the workflow it describes is short enough to be the whole manual.

Download Mmock, create a mock definition, configure your application endpoints to use Mmock, receive the expected responses, inspect the requests in the web UI, and release it to a real server.

That last step is what separates Mmock from a test fixture. The tool is meant to sit between a developer and a backend that is not ready, and the expectation is that the same mock definitions can later be pointed at a real service, or the real service can be swapped in without touching the application.

The tool is built with Go and runs without installation on multiple platforms, and the feature list repeats the point twice, with no installation required and lightweight and portable. The real-time updates using WebSockets entry is the one that changes how it feels to use, since the console updates as requests arrive rather than needing a refresh.

The rest of the feature list is about what a mock server has to do to be useful in a real workflow. Variables in response, using fake or request data. Route patterns that may include named parameters like /hello/:name. Glob matching. Mock definitions that hot replace, so you can edit your mocks without a restart. A web interface to view request data including method, path, headers, cookies and body. Stateful behaviour with scenarios. Verifying. Proxy mode. Fine grain log info in the web interface. Priority matching. Crazy mode for failure testing. And public interface auto discover.

The project is MIT licensed. The repository is Go despite the topic list mentioning TypeScript, the last push was on 2026-04-10, and the releases are v4.3.12, v4.3.11 and v4.3.10 all on 2026-02-03.

One mock definition drives the whole thing

The example definition is a single JSON object with a request section and a response section, and the simplicity is the point.

{
	"request": {
		"method": "GET",
		"path": "/hello/*"
	},
	"response": {
		"statusCode": 200,
		"headers": {
			"Content-Type":["application/json"]
		},
		"body": "{\"hello\": \"{{request.query.name}}, my name is {{fake.FirstName}}\"}"
	}
}

The same definition in YAML is given as an alternative, with the body as a single-quoted string containing the same template.

The body is where the interesting part is. It contains two template expressions. The first, {{request.query.name}}, pulls the value out of the incoming request's query string, and the second, {{fake.FirstName}}, pulls a generated value. So a mock can echo part of the request and fabricate the rest, which is what you need when the response has to look plausible rather than merely be present.

The request matching fields are documented individually. The host is the request http host without port, and the method allows more than one value separated by pipes, and is mandatory. The path is the resource identifier, allows :value matching, and is mandatory. Query string parameters, headers and cookies each allow more than one value for the same key, and headers are case sensitive. The body is a body string that allows a star pattern and also supports regular expressions for field values within JSON request bodies.

When query string parameters, headers and cookies are used, the request can be matched only if all defined keys in the mock are present with the exact or glob value. That is an all-of rule, not any-of, and it is the sort of detail that changes how you write a matcher.

Matching is layered: exact, glob, regex and priority

The matching model has four levels, and knowing which one applies to a field is most of the work.

Glob matching is available for host, path, headers, cookies, query strings and body. Query strings and headers also support global matches in the header or parameter name, so a definition like this catches any header with a name starting with Custom-Header-:

		"headers": {
			"Custom-Header-*": [
				"partial val*"
			]
		}

Regular expression matching is available for body and for query strings, and the documentation points at the Go regexp syntax reference for the details.

The regular expression option applies to field values within JSON request bodies, so you can match a nested value by pattern rather than by string, which is what you need when the body carries an object.

Priority matching is the mechanism for when several mocks could match. The priority field sets the priority to avoid matching in less restrictive mocks, and higher means more priority. So a specific mock with a narrow path and a priority of 10 wins over a catch-all mock with priority 0, without the catch-all having to be written to exclude anything.

The remaining matching fields are the ones you would not guess. There is a cookie matcher, a body matcher that allows a star pattern, and the host matcher, which is the http host without the port. The request can also be matched on method with pipe-separated alternatives, so one definition can serve GET and POST.

The response side is simpler, as it should be, since it does not have to select anything. The status code, the headers, the cookies and the body, and each of the header, cookie and body values allows variables, so the response can be built from request and fake data the same way the request matcher can be.

The control block is where a mock becomes a state machine

The optional control block is the part that takes Mmock beyond a static response table, and it has five fields.

A scenario is essentially a state machine whose states can be arbitrarily assigned. The definition names the scenario, lists the required states it can be reached from, with not_started as the default state, and gives the new state it moves to. So a mock can refuse to answer until a previous call has happened, which is how you model a login-then-call sequence without writing a server.

The proxyBaseURL field makes a mock a pass-through. If this parameter is present, it sends the request data to the BaseURL and resends the response to the client, which is useful if you do not want to mock the whole service. The documentation notes it is not necessary to fill the response field in that case.

The delay field delays the response, to simulate a bad connection or bad server performance, and the same idea appears in the callback block where there is a delay before making the callback request.

The crazy field returns random server errors, that is 5xx, in some request, to simulate server problems. Combined with the delay and the priority, you have the ingredients for a chaos test: some requests fail randomly, some are slow, and the mock server still answers the ones you need.

The webhookURL fires after any request, which is the hook for a test harness that wants to know what was called rather than only inspecting the console.

The callback block is the mirror image. It is used to have Mmock make an API request after receiving the mocked request, with a delay before the call, a URL, a method, headers, a body and a timeout of 10 seconds by default for the callback to respond. That is the piece for a test that needs the mock to poke another service, such as recording what a downstream dependency saw.

Three ports, and the console is a separate server

The command line flags show that Mmock runs three listeners rather than one, and the defaults are worth knowing before you try to reach it.

The mock server listens on 8083 by default, the console server on 8082, and there is a separate TLS port at 8084 with a TLS config folder expected to contain server.crt and server.key. The server IP defaults to public_ip and the console IP to public_ip as well, and the mock server sends anonymous statistics by default, which can be turned off with the server-statistics flag.

The request storage capacity defaults to 100, with 0 meaning infinite, and the results per page default to 25. The console can be disabled entirely with the console flag, and the config path defaults to execution_pathconfig, which is a path joined with a config directory, and the TLS path to execution_path/tls.

The Docker run line shows the same thing in practice:

docker image pull jordimartin/mmock
docker run -v YOUR_ABS_PATH:/config -p 8082:8082 -p 8083:8083 jordimartin/mmock

Two ports are published, 8082 and 8083, which are the console and the mock server, and the config directory is mounted from an absolute path on the host. The Dockerfile exposes all three, 8082, 8083 and 8084, and the entrypoint points the config and TLS paths at the container locations, with the server and console IPs set to 0.0.0.0 so they are reachable from outside the container.

The image is built on alpine:3.20 with ca-certificates and curl added, and it has a healthcheck that curls the console on port 8082 every 30 seconds. The TLS certificate and key are baked into the image at build time, which is a detail to keep in mind if you use the image for anything involving real traffic.

The Docker image is pulled from Docker Hub as jordimartin/mmock, and the project can also be run locally, which requires Go 1.8 at least, with a go get of the module and the mmock binary.

Editorial conclusion

Adopt Mmock if you need a mock server that a colleague or a CI job can start with no install step, since it ships as a single binary and as a Docker image with the config directory mounted. Skip it if your mocking needs are limited to a few static responses, because a stub library inside your test suite is less machinery, and if you need to match responses on anything other than the documented fields, because the matching layer has a specific shape. Verify first that your test harness can point at a fixed host and port, that the response you need can be produced from the request data and the fake data providers, and that you understand the difference between the mock port, the console port and the TLS port, which are three separate listeners.

Frequently asked questions

Official sources

1. Issues
2. jmartin82/mmock on GitHub
3. License: MIT
4. README
5. Releases