Free open-source CLI tools for API mocking

When you mock an API from the command line, the license matters as much as the feature list. A mock server you can inspect, self-host, and run in CI without seat limits is fundamentally different from a hosted SaaS mock behind a login. This guide focuses on open-source tools you can clone, audit, and run for free.

Try Apidog today

Every numbered tool in this list has a permissive MIT or Apache-2.0 license, a public GitHub repository, and a self-hosted workflow with no account required. If you need smaller single-binary options ranked by startup speed and install size, see these lightweight mock server picks. This article prioritizes source availability and self-hosting, so larger container-based platforms are included.

For each tool, you get the license, a command that proves it works, its best use case, and its limitations. For commercial and broader options, see the best API mock tools roundup and the REST API mocking tools overview.

Note: Apidog is not open source. It appears once near the end as a clearly labeled freemium alternative. Every numbered tool below is open source.

What makes a CLI mock tool open source

Use these three checks when evaluating a mock server:

1. Permissive license
   
   The source should be public under a license such as MIT or Apache-2.0. You should be able to inspect, fork, and ship it without license fees or seat limits.

2. Self-hosting support
   
   You should be able to run it locally, in Docker, or on your own infrastructure without a hosted control plane or account gate. This matters for air-gapped CI runners.

3. Open maintenance
   
   Look for a public repository with commit history, issues, and releases. Stars can be useful, but recent commits and tagged releases are stronger maintenance signals.

Startup speed and install size are not the selection criteria here. For that perspective, see the lightweight mock server guide.

1. Prism (Stoplight)

Prism turns an OpenAPI or Postman file into a live mock server. It serves example responses, validates requests against schemas, and can run as a validation proxy in front of a real API.

• License: Apache-2.0
• Repository: stoplightio/prism

Run it

npm install -g @stoplight/prism-cli
prism mock https://raw.githubusercontent.com/stoplightio/prism/master/examples/petstore.oas2.yaml

Prism starts a mock server at http://127.0.0.1:4010.

For example:

curl http://127.0.0.1:4010/pets

The response comes from examples in the OpenAPI document. Invalid request payloads produce schema validation errors.

Use Prism when

• Your OpenAPI file is the source of truth.
• You need contract-driven mocks.
• You want to validate requests against a real API using proxy mode.
• You want to catch implementation drift from the API specification.

Watch out for

• Responses are only as useful as the examples and schemas in your spec.
• It does not provide built-in stateful flows such as creating a resource and reading it back later.
• It requires Node.js.

2. Mockoon CLI

Mockoon is known for its desktop UI, but its CLI runs the same mock engine headlessly for CI and self-hosting. You can load a Mockoon environment file or an OpenAPI document.

• License: MIT
• Repository: mockoon/mockoon

Run it

npm install -g @mockoon/cli
mockoon-cli start --data ./environment.json --port 3000

You can also load an OpenAPI file:

mockoon-cli start --data ./openapi.yaml --port 3000

For local iteration, add file watching and transaction logs:

mockoon-cli start \
  --data ./environment.json \
  --port 3000 \
  --watch \
  --log-transaction

Use Mockoon when

• You need rule-based responses without writing mock server code.
• One endpoint must return different responses based on request data.
• You want response templating, conditional rules, or proxy mode.
• You prefer designing mocks visually and executing them headlessly in CI.

Watch out for

• The desktop app is the easiest way to author environments.
• Hand-editing environment JSON can be cumbersome.
• Its dynamic templating syntax takes time to learn.

3. json-server

json-server is a quick way to create a stateful REST API from a JSON file. It generates CRUD routes and persists changes back to that file.

• License: MIT
• Repository: typicode/json-server

Run it

Create db.json:

{
  "posts": [
    {
      "id": 1,
      "title": "Hello mock API"
    }
  ]
}

Start the server:

npx json-server db.json

You now have CRUD endpoints:

curl http://localhost:3000/posts
curl http://localhost:3000/posts/1

curl -X POST http://localhost:3000/posts \
  -H 'Content-Type: application/json' \
  -d '{"title":"A new post"}'

The new record is written to db.json, so subsequent reads return it.

Use json-server when

• A frontend team needs a working REST API before the backend exists.
• You need stateful CRUD behavior immediately.
• You want filtering, sorting, and pagination through query parameters.
• You want zero configuration and no global install.

Watch out for

• It follows an opinionated REST resource model.
• It does not import OpenAPI specifications.
• Your JSON database becomes the contract.
• It is not intended for load testing or production-like simulation.

4. WireMock

WireMock is a full-featured HTTP mock server for complex integration testing. It supports request matching, response templating, stateful scenarios, fault injection, proxying, and record-and-playback.

• License: Apache-2.0
• Repository: wiremock/wiremock

Run it

Start WireMock in Docker:

docker run -it --rm -p 8080:8080 wiremock/wiremock:latest

Create a mapping through its admin API:

curl -X POST http://localhost:8080/__admin/mappings \
  -H 'Content-Type: application/json' \
  -d '{
    "request": {
      "method": "GET",
      "url": "/hello"
    },
    "response": {
      "status": 200,
      "body": "world"
    }
  }'

Test the mock:

curl http://localhost:8080/hello
# world

For version-controlled stubs, place JSON mapping files in a mappings/ directory and mount that directory into the container.

Use WireMock when

• Your tests need stateful scenarios.
• You need to simulate delays, connection failures, or flaky third parties.
• You want to record real API traffic and replay it later.
• Your mock must behave more like a dependency under realistic failure conditions.

Watch out for

• It requires Docker or a Java runtime.
• Its configuration surface is large for simple mocks.
• It does not provide a single OpenAPI-to-mock command like Prism.

5. MockServer

MockServer combines HTTP(S) mocking and proxying on one port. It is designed for integration testing, request verification, traffic recording, and failure injection.

• License: Apache-2.0
• Repository: mock-server/mockserver

Run it

Start the container:

docker run -d --rm -p 1080:1080 mockserver/mockserver

Register an expectation:

curl -X PUT 'http://localhost:1080/mockserver/expectation' \
  -H 'Content-Type: application/json' \
  -d '{
    "httpRequest": {
      "path": "/order"
    },
    "httpResponse": {
      "body": "{\"status\":\"ok\"}"
    }
  }'

Call the endpoint:

curl http://localhost:1080/order
# {"status":"ok"}

MockServer also provides Java, JavaScript, Ruby, and other client libraries, so you can define expectations directly from test code.

Use MockServer when

• You need both mocking and proxying.
• Tests must verify whether a request was made a specific number of times.
• You need failure injection for client resilience tests.
• Your stack already benefits from its available client libraries.
• You need support for HTTP/2, gRPC, or WebSocket workflows.

For alternatives, see MockServer alternatives.

Watch out for

• It requires Docker or a JVM runtime.
• Expectation JSON can become verbose.
• It overlaps substantially with WireMock, so choose based on the client libraries and workflow that fit your test stack.

6. Microcks

Microcks is a platform for managing mocks and contract tests across multiple API styles. It supports OpenAPI, AsyncAPI, gRPC, GraphQL, Postman collections, and SoapUI projects.

• License: Apache-2.0
• Repository: microcks/microcks
• Project status: CNCF incubating project

Run it

Start the all-in-one image:

docker run -d --name microcks -p 8585:8080 quay.io/microcks/microcks-uber:latest

Open http://localhost:8585, then import a contract to create mock endpoints.

For CI automation, use the companion microcks-cli against a running Microcks instance:

microcks-cli import 'petstore.yaml:true' \
  --microcksURL=http://localhost:8585/api \
  --keycloakClientId=... \
  --keycloakClientSecret=...

Use Microcks when

• Your team manages many APIs and needs a shared mock catalog.
• You need contract testing alongside API mocking.
• You work with async or event-driven protocols such as Kafka or MQTT.
• You need more than HTTP mocking in a single platform.

Watch out for

• Microcks is a server platform, not a small standalone binary.
• microcks-cli imports artifacts and triggers tests; it does not serve mocks itself.
• It is heavier than Prism or json-server for a one-off local mock.

An honest aside: Apidog

Apidog is not open source, so it is not a numbered entry in this list. However, if you need an integrated workflow instead of combining separate tools for API design, mocking, testing, and documentation, it is worth considering.

Apidog is a freemium platform with mocking in its free tier. The apidog mock workflow in apidog-cli lets you manage mock expectations from the terminal alongside API design, testing, and documentation in one project. Smart mock can generate field values from your schema, reducing the need to hand-write every example body.

The trade-off is straightforward:

• Choose one of the six open-source tools above when open source or air-gapped self-hosting is mandatory.
• Choose Apidog when an integrated design-to-mock workflow matters more than self-hosting and source availability.

How to choose

Tool	Best for	Install	License	Notes
Prism	Spec-driven mocks and validation proxy	npm i -g @stoplight/prism-cli	Apache-2.0	OpenAPI/Postman in, mock out; stateless
Mockoon CLI	Rule-based responses without code	npm i -g @mockoon/cli	MIT	Design in the app, run headlessly
json-server	Stateful REST APIs for frontend development	npx json-server db.json	MIT	Full CRUD with persistence and zero config
WireMock	Complex test scenarios and fault injection	docker run wiremock/wiremock	Apache-2.0	JVM-based; record-and-playback; stateful
MockServer	Mocking, proxying, and request verification	docker run mockserver/mockserver	Apache-2.0	JVM-based; HTTP/2, gRPC, and WebSocket support
Microcks	Governed multi-API and multi-protocol catalogs	docker run microcks-uber	Apache-2.0	CNCF platform; CLI is a client, not a server
Apidog (not OSS)	Integrated design-to-mock workflow	npm i -g apidog-cli	Freemium	Free tier; apidog mock in one project

Pick based on the shape of the problem:

• OpenAPI-first mock with validation: Start with Prism.
• Stateful CRUD before the backend exists: Use json-server.
• Conditional, rule-based responses without writing code: Use Mockoon CLI.
• Fault injection, replay, and complex stateful tests: Use WireMock or MockServer.
• Request verification plus proxying: Use MockServer.
• Shared contract testing and multi-protocol mocks: Use Microcks.

For scenario-based guidance, see the API mocking use cases guide.

Wrapping up

Open-source CLI mock tools give you mock servers you can inspect, self-host, and run in CI without license fees. Prism and json-server cover common local workflows in one command. WireMock and MockServer handle advanced integration-test behavior. Microcks scales mocking and contract testing across APIs and protocols.

All six open-source options are MIT or Apache-2.0, self-hostable, and maintained in public GitHub repositories.

If you prefer managing mocks next to API design, tests, and documentation without wiring together separate tools, download Apidog and try apidog mock on the free tier. It is not open source, but it provides an integrated command-line-to-CI workflow.