Mockoon gives you a local HTTP endpoint before the service you depend on is ready, with a desktop application for visual route design and a CLI for terminal and continuous integration work.
Choose the Linux package that fits your system
Mockoon’s download page provides native Debian and RPM packages, plus AppImage builds for x86_64 and ARM64.
Pick the native package when your distribution supports it because your package tools then track removal and desktop integration.
- Use the Debian package on Debian, Ubuntu, Linux Mint, and related distributions.
- Use the RPM package on Fedora, RHEL-based systems, and openSUSE.
- Use AppImage when you need a portable desktop build without a system package installation.
- Use Snap when snapd is already part of your desktop setup.
Download the matching file from Mockoon’s official download page, then open a DEB or RPM file with your desktop software installer or use your distribution’s package-install flow.
Install Mockoon from Snap
If your system already has snapd, the Mockoon Snap Store page publishes this install command. It installs the desktop application from the Snap channel selected by the store.
sudo snap install mockoon
Launch Mockoon from your application menu after installation and create an environment with a listening port and routes.
Install Mockoon from the Arch User Repository
The upstream repository lists mockoon-bin for Arch users. Use it only when you already use yay and accept the Arch User Repository review model for packages maintained outside Arch’s official repositories.
yay -S mockoon-bin
Create a mock API in the desktop app
Create a new environment, set a port such as 3000, add a GET route such as /pets, then add a JSON response and start the environment.
Keep the mock response deliberately small at first. Once the route works, add status codes, headers, route rules, delays, or proxy mode to match the behavior your client needs to handle.
Run a saved Mockoon environment with the CLI
Mockoon CLI runs an exported environment without the desktop application. It is useful when a test suite, container, or remote development environment needs the same mock API definition.
I imported an OpenAPI document into a Mockoon environment, validated the generated file, started it on localhost, and queried its GET route. The CLI accepted the environment and returned the mock JSON response.
Install the CLI in a Node.js project
The current CLI package requires Node.js 18 or later. Add it as a development dependency when the mock belongs to one project.
npm install --save-dev @mockoon/cli
Import and validate an OpenAPI file
Save an OpenAPI 3 document as pets-api.yaml, then convert it to Mockoon’s environment format. Validation catches a malformed environment before the server starts.
npx mockoon-cli import --input ./pets-api.yaml --output ./pets-environment.json --prettify
npx mockoon-cli validate --data ./pets-environment.json
Start the mock and check the route
Start the environment on a loopback address so the example is available only from the local machine. Disable the admin API when you do not need to control the running mock through its management endpoint.
npx mockoon-cli start --data ./pets-environment.json --port 3100 --hostname 127.0.0.1 --disable-admin-api
Open a second terminal and call the route. Replace /pets with the path from your environment.
curl -fsS http://127.0.0.1:3100/pets
Keep local mocks separate from public services
A mock API can stand in for an unavailable dependency, but it does not test the production service’s authorization, data validation, rate limits, or failure behavior. Use it to make client development predictable, then keep integration tests for the contract with the service that will receive production traffic.
Mockoon can also proxy requests that do not match a declared route. Point proxy mode at a non-production endpoint you control, and avoid exposing credentials or internal responses through a mock that is reachable beyond your development network.