When you mock an API from the command line, the license matters as much as the feature list. A mock server you can read the source of, self-host, and run in CI without a seat count is a very different thing from a hosted SaaS mock behind a login. This guide covers the open-source side: tools you can clone, inspect, and run for free.
Every tool here is source-available under a permissive license (MIT or Apache-2.0), lives on a public GitHub repo, and can be self-hosted with no account. That’s the filter. If you want the smaller, single-binary picks ranked by startup speed and install size, read the companion lightweight mock server picks instead; this list is about source and self-hosting, so a heavier self-hostable platform can still earn a spot.
For each tool you get the license, the one install-plus-run command that proves it works, what it’s best at, and where it falls short. If you want the broader field including commercial options, the best API mock tools roundup and the REST API mocking tools overview go wider.
A quick, honest note before the list. Apidog isn’t open source; it’s a freemium commercial platform. It shows up once at the end as an integrated alternative to these tools, clearly labeled, not as an open-source entry. Everything in the numbered sections below is genuinely open source.
What makes a CLI mock tool open source
Three things decide whether a tool belongs on this list.
License. The source has to be public under a permissive license. Every pick here is MIT or Apache-2.0, so you can read it, fork it, and ship it inside your own product without a license fee or a seat count.
Self-hostable. You run it on your laptop, in a container, or on your own server. No hosted control plane, no phone-home, no account gate. That’s what keeps a mock usable in an air-gapped CI runner.
Maintained in the open. A public GitHub repo with real commit history, issues, and releases. Stars are a rough signal; recent commits and tagged releases are the better one.
Notice what’s not on the list: raw speed or install size. Those are the lightweight angle. Here a big, container-based, self-hostable platform is fair game as long as the source is open and the license is free.
Prism (Stoplight)
Prism turns an OpenAPI or Postman file into a live mock server. Point it at a spec and it serves example responses, validates incoming requests against the schema, and can run as a validation proxy in front of a real API. License: Apache-2.0. Repo: stoplightio/prism.
npm install -g @stoplight/prism-cli
prism mock https://raw.githubusercontent.com/stoplightio/prism/master/examples/petstore.oas2.yaml
That command boots a mock on http://127.0.0.1:4010 driven entirely by the spec. GET /pets returns the example from your OpenAPI document; send a bad payload and Prism tells you which part of the schema you violated.
Best at: spec-driven contract mocking where the OpenAPI file is the source of truth. The validation proxy mode is the standout; it catches drift between your spec and your real API.
Limits: responses come from your examples and schema, so mocks are only as rich as the spec. There’s no built-in stateful behavior (no “create then read it back”). It’s a Node tool, so you need a Node runtime.
Mockoon CLI
Mockoon is best known for its desktop app, but the CLI ships the same engine with no GUI, built for CI and self-hosting. You design an environment (in the app or by hand) or hand it an OpenAPI file, and it serves that mock. License: MIT. Repo: mockoon/mockoon.
npm install -g @mockoon/cli
mockoon-cli start --data ./environment.json --port 3000
You can also start straight from an OpenAPI file with --data ./openapi.yaml. Add --watch to reload on file changes and --log-transaction to print full request/response logs.
Best at: rich, rule-based responses without writing code. Mockoon supports response templating, conditional rules, and proxy mode, so one endpoint can return different bodies based on the request. Designing visually in the app and running headless via the CLI is a clean split.
Limits: the nicest authoring path is the desktop app, so hand-editing the environment JSON is fiddly. The dynamic templating syntax has a learning curve of its own.
json-server
json-server is the fastest way to fake a REST API. Give it a JSON file and it generates full CRUD routes (GET, POST, PUT, PATCH, DELETE) with real persistence back to that file. License: MIT. Repo: typicode/json-server.
npx json-server db.json
With a db.json that has a top-level "posts" array, you immediately get GET /posts, GET /posts/1, POST /posts, and the rest, plus filtering, sorting, and pagination via query params. POST a new record and it’s written to the file; read it back and it’s there.
Best at: frontend development before the backend exists. It’s stateful out of the box, which Prism and most spec-driven mocks are not. Zero config, and npx means you don’t even install it.
Limits: it’s opinionated about REST shape, so it won’t match an arbitrary custom API. No OpenAPI import; the JSON file is the contract. Not meant for load testing or production-like behavior.
WireMock
WireMock is the heavyweight of open-source HTTP mocking, with millions of downloads a month. It runs as a standalone process configured over a JSON admin API or from JSON stub files, and it handles request matching, response templating, stateful scenarios, fault injection, and record-and-playback. License: Apache-2.0. Repo: wiremock/wiremock.
docker run -it --rm -p 8080:8080 wiremock/wiremock:latest
curl -X POST http://localhost:8080/__admin/mappings \
-H 'Content-Type: application/json' \
-d '{"request":{"method":"GET","url":"/hello"},"response":{"status":200,"body":"world"}}'
The first line starts WireMock; the second registers a stub over its admin API. Now curl http://localhost:8080/hello returns world. You can also drop stub files in a mappings/ directory and mount it into the container.
Best at: complex test scenarios. Stateful behavior, delays and faults to simulate a flaky third party, and proxy-plus-record to capture a real API and replay it later. This is the tool when your mock needs to behave like the real thing under test.
Limits: it’s a JVM tool, so the container or a Java runtime is the price of entry. The configuration surface is large; simple mocks feel like overkill. There’s no single “read a spec and go” command the way Prism has.
MockServer
MockServer is an HTTP(S) mock and proxy on a single port, aimed squarely at integration testing. It mocks APIs, can proxy and record live traffic, and lets you inject failures to test how your client handles them. Recent versions add HTTP/2, gRPC, and WebSocket support. License: Apache-2.0. Repo: mock-server/mockserver.
docker run -d --rm -p 1080:1080 mockserver/mockserver
curl -X PUT 'http://localhost:1080/mockserver/expectation' \
-H 'Content-Type: application/json' \
-d '{"httpRequest":{"path":"/order"},"httpResponse":{"body":"{\"status\":\"ok\"}"}}'
The PUT registers an “expectation”; after it, curl http://localhost:1080/order returns your JSON. MockServer’s clients (Java, JavaScript, Ruby, and others) let you set the same expectations from inside your test code instead of over curl.
Best at: mocking and proxying in the same place, plus failure injection. If you need to verify that a specific request was made a specific number of times, MockServer’s verification API is built for that. Good fit for JVM-heavy stacks. See our MockServer alternatives piece if it’s not quite the right shape.
Limits: like WireMock, it’s JVM-based and the expectation JSON is verbose. The overlap with WireMock is real; pick one based on which client library fits your test stack.
Microcks
Microcks is the platform pick, and it’s a Cloud Native Computing Foundation incubating project. It turns OpenAPI, AsyncAPI, gRPC, GraphQL, Postman collections, and SoapUI projects into live mocks, and it reuses those same contracts to run conformance tests against your real implementation. It covers event-driven and async protocols, not just HTTP. License: Apache-2.0. Repo: microcks/microcks.
docker run -d --name microcks -p 8585:8080 quay.io/microcks/microcks-uber:latest
That runs the all-in-one image; open http://localhost:8585 and import a spec to get mock endpoints. The companion microcks-cli drives a running server from CI:
microcks-cli import 'petstore.yaml:true' \
--microcksURL=http://localhost:8585/api \
--keycloakClientId=... --keycloakClientSecret=...
Best at: teams that want one governed catalog of mocks across many APIs and protocols, with contract testing built in. The async/event-driven mocking (Kafka, MQTT, and friends) is rare in this space.
Limits: this is a server, not a single binary. One important caveat: the microcks-cli triggers tests and imports artifacts against a running Microcks instance; it doesn’t serve mocks by itself. So the CLI is a client, and you still run the platform. For a one-off local mock, that’s heavier than Prism or json-server.
An honest aside: Apidog
Apidog isn’t open source, so it doesn’t get a numbered slot here. But if you’ve noticed that the tools above solve different pieces (spec-driven mocks, stateful CRUD, contract testing) and you’d rather not stitch them together, it’s worth a mention. Apidog is a freemium platform whose free tier includes mocking, and apidog mock in the apidog-cli lets you manage mock expectations from the terminal alongside design, testing, and docs in one project. Smart mock generates realistic field values from your schema automatically, so you’re not hand-writing example bodies.
The trade-off is plain: you get an integrated workflow and a free tier instead of open source and self-hosting. If open source or air-gapped self-hosting is a hard requirement, one of the six tools above is your answer. If an integrated design-to-mock loop matters more, Apidog is the alternative to gluing several tools together.
How to choose
| Tool | Best for | Install | License | Notes |
|---|---|---|---|---|
| Prism | Spec-driven mocks + validation proxy | npm i -g @stoplight/prism-cli |
Apache-2.0 | OpenAPI/Postman in, mock out; stateless |
| Mockoon CLI | Rule-based responses, no code | npm i -g @mockoon/cli |
MIT | Design in the app, run headless |
| json-server | Stateful fake REST for frontend | npx json-server db.json |
MIT | Full CRUD with persistence, zero config |
| WireMock | Complex test scenarios, faults | docker run wiremock/wiremock |
Apache-2.0 | JVM; record-and-playback; stateful |
| MockServer | Mock + proxy + verification | docker run mockserver/mockserver |
Apache-2.0 | JVM; HTTP/2, gRPC, WebSocket |
| Microcks | Governed multi-API/protocol catalog | docker run microcks-uber |
Apache-2.0 | CNCF platform; CLI is a client, not a server |
| Apidog (not OSS) | Integrated design-to-mock | npm i -g apidog-cli |
Freemium | Free tier; apidog mock in one project |
Pick by shape, not popularity. For a mock that reads your OpenAPI file and enforces it, start with Prism. For stateful CRUD before the backend lands, json-server wins on speed. For rich test scenarios with faults and record-and-playback, WireMock or MockServer; choose by client library. For a shared, multi-protocol catalog with contract testing, Microcks. For which shape fits which situation, the API mocking use cases guide maps tools to scenarios.
Wrapping up
Open-source CLI mock tools give you a mock server you can read, self-host, and run in CI for free. Prism and json-server cover the common cases in one command; WireMock and MockServer handle the hard test scenarios; Microcks scales it to a governed catalog across protocols. All six are MIT or Apache-2.0, all self-hostable, all on public GitHub.
If you’d rather manage mocks next to your API design, tests, and docs without wiring separate tools together, Download Apidog and try apidog mock on the free tier. It’s not open source, but it is one place to run the whole loop from the command line into CI.



