Mockoon

Last reviewed Aug 26, 2026 · 827 words

Mockoon is a desktop application first and a server second, and getting that order right is what makes it useful in a self-hosted stack. You design a fake REST API in the Electron app on your laptop, save it as one JSON file, commit that file, and then mockoon/cli in Docker serves it anywhere on 128 MB: a CI job, a staging environment, a demo box for a client. It is not a proxy you leave in production and not a collaboration platform; it is a fixture generator with an excellent editor, and 8,378 stars since 2017 say the developers who use it are content with that.

The desktop app is the source of truth

Open Mockoon, create an environment, add routes, define responses with status codes and headers, and it is already serving on localhost:3000 while you edit. Every environment is a single JSON file, and the app can watch a folder so that edits from Git show up live. This matters because the file is the deployable artifact: what your CI serves is byte-for-byte what you clicked together. There is no export step and no second format to drift.

The app is free, MIT-licensed and runs on Windows, macOS and Linux. It is the reason Mockoon replaces Postman's mock servers for many teams: the editor is better, the file is yours, and nothing goes through someone else's cloud. If you are moving off Postman entirely, the Postman alternatives page covers the request-client side; for that half, Hoppscotch or Bruno pair well with Mockoon.

Headless is one command

docker run -d --name payments-mock -p 3000:3000 \
  -v $(pwd)/payments-api.json:/data/payments-api.json:ro \
  mockoon/cli:latest --data /data/payments-api.json --port 3000

That is the whole deployment. The same image runs in a Compose file next to the service under test, in a GitHub Actions or Gitea Actions job as a service container, or on a homelab VM as the stand-in for a third-party API nobody wants to pay for in staging. Several environments run as several containers; there is no multi-tenant server to administer. Logs go to stdout in a format your existing stack already collects.

Templating turns fixtures into a fake backend

Static JSON gets old the second a front end needs pagination. Mockoon responses are Handlebars templates with helpers for the request ({{urlParam 'id'}}, {{queryParam 'page'}}, {{body 'email'}}) and a Faker.js bridge for realistic names, addresses and dates. Data buckets hold state across requests, and CRUD routes on top of a bucket give you a working create, read, update, delete resource with no code:

GET    /users       -> list from bucket, supports ?page= and ?limit=
POST   /users       -> appends to bucket, returns 201
GET    /users/:id   -> finds by id, 404 if missing

That is enough to build a whole front end against before the real service exists, and to run end-to-end tests that create and delete records without touching a database.

Rules, latency and proxy mode for the awkward cases

Each route can have several responses chosen by rules on headers, query, body or a sequence, which is how you simulate "this card is declined" or "rate-limited on the third call". Per-route latency lets you test spinners against a 2,000 ms response. Proxy mode forwards anything you have not mocked to the real API and can record what came back as new routes, which is the fastest way to build a mock of a service you already integrate with: point it at production for 10 minutes, then switch the proxy off.

What it is not, and where the paid line sits

Mockoon is not a production API gateway; there is no auth, no rate limiting, no persistence beyond process memory, and the project says so plainly. The team-collaboration features (shared environments, cloud sync, a hosted deployment) are Mockoon Cloud, a paid product. The self-hosted path to collaboration is the boring one that already works: the environment JSON lives in a Git repository, changes are pull requests, and the CLI serves whatever is on main. For most teams that is better than a sync service anyway. The dev tools category lists the request clients and API tools that sit next to it.

What I'd do

Keep a mocks/ directory in each service repository with one Mockoon environment per upstream dependency, edit them in the desktop app, and run mockoon/cli as a service container in CI and in the staging Compose file. Use data buckets and CRUD routes for anything the front end writes to, and rules for the failure cases the real API makes hard to trigger. Never let a mock outlive the sprint it was built for without an integration test against the real thing. Used like that, Mockoon costs nothing and removes the most tedious part of integration work.