You need a fake API to develop against in the next thirty seconds—not a hosted service, Docker Compose stack, or GUI workflow. Just run a command, point it at a file, and serve responses on localhost.
A lightweight mock server lets your frontend, integration tests, or CI job call realistic endpoints while the real backend is still under construction. The fastest options run as a single binary or an npx package, start in under a second, and require almost no configuration. Heavier JVM-based tools are useful when you need advanced request matching, delays, failures, or stateful test scenarios.
This guide ranks six CLI mock tools by setup friction: first the tools you can run without installing anything, then standalone JVM servers, and finally the integrated Apidog CLI workflow. Every command below is based on each tool's official documentation. For GUI and hosted alternatives, see the best API mock tools.
What makes a CLI mock tool “lightweight”
“Lightweight” is about footprint and friction, not only feature count. Evaluate each tool using four practical criteria:
-
Install size and runtime: An
npx-based Node package usually needs only Node.js. A standalone JVM server is typically a 20MB+ JAR and requires Java. - Startup speed: The server should be ready before you switch back to your editor. Node-based tools generally cold-start in well under a second.
- Time to first response: The ideal flow is one input file plus one command.
- Terminal-first workflow: No account, dashboard, or GUI is required. The server should fit naturally into shell scripts and CI jobs.
Prism, Mockoon CLI, and json-server are the quickest options because you can run them directly with npx.
Prism (Stoplight)
Use Prism when you already have an OpenAPI definition and want a mock that follows the contract.
npx @stoplight/prism-cli mock ./openapi.yaml
Prism starts on http://127.0.0.1:4010 and exposes every operation in your specification.
What Prism does
- Reads OpenAPI
paths, responseexamples, and schemas. - Returns defined response examples when available.
- Generates schema-valid random responses when examples are missing.
- Validates incoming requests against the specification.
- Returns
422for malformed requests instead of silently accepting them.
For a global install:
npm install -g @stoplight/prism-cli
prism mock ./openapi.yaml
Best for: Spec-first teams that need the mock to stay aligned with the API contract. Prism is Apache-2.0 licensed and supports OpenAPI 3.1, 3.0, 2.0, and Postman collections.
Honest limits: Prism is stateless. A POST request does not persist data, so it cannot simulate create-then-read flows without additional tooling. Its generated responses are only as useful as your schemas and examples. For contract-accurate mocking, that is usually the intended trade-off. It also fits well into a REST API mocking tools workflow.
Mockoon CLI
Mockoon CLI runs a mock API from either:
- A Mockoon environment file exported from the free desktop app.
- An OpenAPI JSON or YAML file.
Start an environment file with:
npx @mockoon/cli start --data ./mockoon-env.json --port 3000
The CLI serves the configured routes immediately.
Typical workflow
- Build routes visually in Mockoon Desktop.
- Export or save the environment definition.
- Run the environment headlessly in local development or CI.
You can also point --data directly to an OpenAPI file. If an environment file uses an older Mockoon format, the CLI migrates it in memory without changing the source file.
For a global install:
npm install -g @mockoon/cli
mockoon-cli start --data ./mockoon-env.json --port 3000
Best for: Teams that want to design mocks in a GUI but run them headlessly. Mockoon is MIT-licensed and provides an official Docker image.
Honest limits: The richest route definitions are typically created in the desktop app. Hand-editing a Mockoon JSON environment can be more cumbersome than maintaining a simple OpenAPI or JSON file. If you want a file-first workflow with no companion app, use Prism or json-server.
json-server
Use json-server when you do not have an API specification yet and need a working REST API immediately.
Create a data file:
echo '{ "posts": [{ "id": 1, "title": "hello" }] }' > db.json
Start the server:
npx json-server db.json
You now have a REST endpoint at:
http://localhost:3000/posts
What you get automatically
For a posts collection, json-server generates REST operations including:
GET /postsGET /posts/:idPOST /postsPUT /posts/:idPATCH /posts/:idDELETE /posts/:id
Unlike stateless spec mockers, json-server persists changes back to db.json. A POST /posts adds a record, which makes it useful for basic stateful frontend development.
It also supports filtering, sorting, and pagination through query parameters. The current 1.x line watches the data file and reloads when it changes.
Install globally if needed:
npm install -g json-server
json-server db.json
Best for: Frontend developers who need a working REST backend before the real API exists. It is MIT-licensed and is one of the lightweight mock server options for a RESTful API that requires no specification.
Honest limits: json-server assumes a resource-oriented REST shape. It is not ideal for custom RPC-like routes, strict contract validation, or detailed header and body matching.
MockServer
MockServer is the option to choose when request matching matters more than startup speed.
Instead of serving an entire spec or generating CRUD routes from data, MockServer lets you define explicit expectations:
- Match by HTTP method.
- Match by path.
- Match headers, query parameters, or request bodies.
- Return exact responses.
- Add delays and failures to test timeout and error handling.
Start the standalone server:
java -jar mockserver-netty-5.15.0-no-dependencies.jar -p 1080
MockServer listens on port 1080. Configure expectations through its REST API or programmatically.
For Node.js projects, use the official wrapper:
npm install mockserver-node
const mockserver = require('mockserver-node');
mockserver.start_mockserver({
serverPort: 1080,
});
Best for: Integration tests that need fine-grained assertions about requests and fully controlled responses. MockServer is Apache-2.0 licensed and supports HTTP, HTTPS, and more on a single port.
Honest limits: It is JVM-based, so it is heavier and slower to start than the Node options. Expectation setup is also more verbose than pointing Prism at an OpenAPI file. If you only need to serve a specification, this is usually overkill. See MockServer alternatives for trade-offs.
WireMock (standalone)
WireMock is another established JVM mock server, widely used in Java and JVM testing workflows. Its standalone JAR uses the same engine that can be embedded in JUnit tests, so local mocks can be shared with automated test suites.
Start WireMock:
java -jar wiremock-standalone.jar --port 8080
WireMock listens on port 8080.
Configure stubs
WireMock can load stub mappings from a mappings/ directory or accept them through its JSON API. It can also record real HTTP traffic and replay it as stubs, which is useful when mocking third-party APIs you do not control.
There is also an official wiremock/wiremock Docker image for CI environments.
Best for: JVM teams that want one mock engine for local development and tests, plus record-and-replay support. WireMock is Apache-2.0 licensed.
Honest limits: Like MockServer, WireMock requires Java and starts more slowly than Node-based tools. Its JSON stub mappings are powerful, but they require more setup than a single data file. If you are coming from JavaScript, see this Mock Service Worker (MSW) alternative comparison for browser-first context.
Apidog CLI
The previous tools each solve a specific part of API mocking. Apidog takes an integrated approach: API design, mocks, tests, and documentation live in one project, while the Apidog CLI lets you work with that project from the terminal.
Apidog is not open source. It is a commercial product with a free tier. The free tier and CLI provide an alternative to combining separate tools for specifications, mock servers, test execution, and documentation.
Apidog automatically generates smart mocks from defined endpoints. Responses follow schema field types and naming, so a phone field can return a plausible phone number instead of an arbitrary string. For request-specific behavior, add mock expectations and manage them from the CLI.
npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog mock --help
The mock command group works with project mock expectations from scripts and CI. Apidog also includes command groups for endpoints, schemas, environments, and test runs.
CLI output is structured JSON and includes an agentHints.nextSteps field, making it usable in automated workflows and by AI agents. See the Apidog CLI complete guide for the full command surface.
Best for: Teams that want mocks, API specifications, and tests in one project instead of maintaining separate tools. Download Apidog to try the built-in mock server and CLI with your own project.
Honest limits: Apidog is a platform rather than a single-purpose binary, so it requires a project and login where json-server requires neither. For a throwaway one-file mock, a smaller tool is usually better. If you already design APIs in Apidog, the mock workflow is already part of the project.
How to choose
Choose based on what you already have:
- You have an OpenAPI spec: Use Prism or Mockoon CLI.
- You have no spec and need CRUD quickly: Use json-server.
- You need exact request matching: Use MockServer or WireMock.
- You want mock, design, tests, and docs in one workflow: Use Apidog.
| Tool | Best for | Install | Open source? | Notes |
|---|---|---|---|---|
| Prism | Serving an OpenAPI spec as a mock | npx @stoplight/prism-cli |
Yes (Apache-2.0) | Contract-accurate, stateless, port 4010 |
| Mockoon CLI | GUI-built mocks run headlessly | npx @mockoon/cli |
Yes (MIT) | Reads environment files or OpenAPI, Docker image |
| json-server | Instant REST API from JSON | npx json-server |
Yes (MIT) | Stateful CRUD, no spec needed, port 3000 |
| MockServer | Precise request matching | java -jar mockserver-netty-*.jar |
Yes (Apache-2.0) | JVM, npm wrapper available, port 1080 |
| WireMock | Shared JVM development and test engine | java -jar wiremock-standalone.jar |
Yes (Apache-2.0) | Record-and-replay, Docker image, port 8080 |
| Apidog CLI | Mock, spec, and tests in one project | npm install -g apidog-cli |
No (free tier) | Auto smart mock and managed expectations |
The practical rule is simple: use npx tools for speed, JVM servers for matching depth, and Apidog when you want one workflow instead of several. If you are still deciding whether mocking is worth the effort, review these API mocking use cases.
Wrapping up
Choose the smallest tool that accepts the input you already have:
- Send an OpenAPI spec to Prism or Mockoon CLI.
- Send a blank slate and JSON data to json-server.
- Use MockServer or WireMock for strict matching and controlled failure scenarios.
- Use Apidog when you want mocks next to API design and tests.
All six tools run from the terminal and fit into CI jobs. Start with the lowest-friction option, then add complexity only when your use case requires it. To try the integrated workflow, download Apidog and generate a mock server from an API design.
Top comments (0)