Credit where due: MockServer may be the most capable open-source mock toolkit there is. After a quiet stretch, the project is very much alive — v7.6.0 shipped August 17, 2026, with commits landing the day we wrote this — and version 7 is a monster in the best sense: mock and proxy on one auto-detecting port (HTTP/1.1, HTTPS, HTTP/2, gRPC, gRPC-Web, WebSockets, raw TCP), record-and-replay proxying, request verification, chaos testing, interactive proxy breakpoints, OIDC/OAuth2/SAML identity-provider mocks, OpenAPI import, Pact support, Testcontainers integration, and a deep matcher DSL (JSON, JSONPath, XPath, regex, OpenAPI). The old JVM requirement is gone too: npx -p mockserver-node mockserver run pulls a self-contained native bundle — we ran it, it started in seconds, no Java installed. If your job is service virtualization inside infrastructure you already operate, MockServer is a superb choice and this page won't talk you out of it.
This page is about a much smaller, very common job: a data-shaped sandbox API for a frontend, a prototype, or an integration test — the "just give me /users that behaves like a real API" job. MockServer 7 added a CRUD data store aimed exactly at this, so we downloaded 7.6.0 and put it through the same drill we use on every tool. It's real — and it has walls.
Setup: mockserver run -p 1080, then PUT /mockserver/crud with {"basePath":"/users", "initialData":[…3 users…]}. Registration works exactly as documented — list/get/create/replace/patch/delete endpoints appear instantly, seeded with our records. Then:
Wall 1: the list endpoint has no query semantics. GET /users?role=user returned all three users, including the admin. ?limit=1&page=2 returned all three. ?sortBy=name&order=desc returned all three, in insertion order. Every query param is silently ignored — the store gives you "all items" or "one item by id", and pagination, filtering, sorting, and search are your frontend's problem (or another layer of hand-written expectations).
Wall 2: it's in-memory — a restart loses everything. We killed the process and started it again: GET /users → 404, empty body. Not just the records — the CRUD registration itself was gone. PUT /mockserver/reset wipes it the same way (that one is documented). MockServer does have opt-in file persistence, but it's for expectations; the CRUD store's documentation says plainly that it is backed by an in-memory store. For a personal sandbox that lives exactly as long as one test run, fine; for a mock your team hits for a week, everything rides on one process never restarting.
Wall 3: small data-API details you'd expect from a real backend aren't there. POST with an explicit {"id":50} got renumbered to the next auto-increment (we got id:2). GET /users/1/posts → 404: no nested routes, no relations between stores. And the store describes itself only in its registration response — there's no generated OpenAPI spec, Postman collection, or TypeScript types for the resource you just created. (One genuinely good detail, credit due: an unknown id is a clean 404, not an error page.)
Wall 4: there is no hosted option — sharing the mock means operating a server. This isn't a defect, it's the deployment model: MockServer runs on your laptop, in Docker, or in Kubernetes via their Helm chart (where surviving pod restarts officially requires configuring PersistentVolumeClaims). The moment a teammate, a phone on another network, a CI job, or a deployed preview needs to hit the mock, you're provisioning, exposing, and babysitting infrastructure. There is no cloud offering to pay for even if you wanted one.
Where you'd run a binary and PUT /mockserver/crud, create a hosted project instead — nothing to run, nothing to keep alive:
curl -X POST https://mockbird.mockbird.workers.dev/api/projects \
-H 'content-type: application/json' -d '{"name":"my-api","preset":"ecommerce"}'
# → {"id":"<PID>","adminKey":"…","baseUrl":"https://mockbird.mockbird.workers.dev/m/<PID>",…}
# 4 resources, realistic seeded records, live at a public URL immediatelyYour initialData has a direct equivalent: import a db.json — {"users":[…your exact records…]} — and your records are hosted verbatim, ids preserved. Or import an OpenAPI spec and get typed seed data generated. Either way the data-API behaviors from Wall 1 are just true, on every resource, with zero authoring:
# the params MockServer's CRUD store ignores (ran on the shared demo before publishing):
curl 'https://mockbird.mockbird.workers.dev/m/demo/products?sortBy=price&order=desc&limit=2&select=name,price'
# → the two most expensive products, only the fields you asked for
curl 'https://mockbird.mockbird.workers.dev/m/demo/products?inStock=true&limit=2&page=2'
# → filtered AND paginated
# writes persist — and survive every restart we don't have:
curl -X POST https://mockbird.mockbird.workers.dev/m/demo/products \
-H 'content-type: application/json' -d '{"name":"my product","price":9.99}'
# → {"name":"my product","price":9.99,"id":31}
curl https://mockbird.mockbird.workers.dev/m/demo/products/31 # → same record, tomorrow too| MockServer | Mockbird | Notes |
|---|---|---|
mockserver run + PUT /mockserver/crud | POST /api/projects | hosted URL instead of localhost:1080; nothing to operate |
initialData seed records | db.json import | records hosted verbatim, ids preserved; or generate typed fakes with ?seed=N |
GET {basePath} (all items, params ignored) | list endpoints with the full toolkit | filter, _gte/_lte/_ne/_like, sort, pagination, search, ?select= — always on |
| in-memory store, wiped on restart/reset | persistent storage by default | records live in a real database; deliberate resets via snapshots |
PUT /mockserver/reset | snapshot save / restore | named states; pin one per request with X-Mockbird-Snapshot for parallel tests |
| expectation with a delay | ?mock_delay=2000 | per-request query param — measured 2.4 s on the demo |
| chaos testing | ?mock_chaos=0.3, ?mock_jitter=800 | honest: theirs is free too, and richer (proxy-level, K8s recipes); ours is one query param |
| fixed error responses | ?mock_status=503, ?mock_seq=502,502,200 | any endpoint, no expectation authored — verified 503 on the demo |
| retrieve recorded requests / verification | request inspector | last 50 with headers + bodies; theirs adds order/count assertions — richer |
| OpenAPI → expectations | OpenAPI → live seeded resources | both import; we also export OpenAPI, Postman, and TS types from the live schema |
| GraphQL mocking (schema you define) | generated GraphQL endpoint | ours is derived from your data automatically — queries, mutations, relations |
| proxy / record-and-replay | no equivalent | honest: MockServer's superpower stays MockServer's |
| gRPC, WebSockets, raw TCP, HTTP/2 | no equivalent (REST + GraphQL + SSE + WS echo) | honest: their protocol breadth is unmatched |
| 10,000 items per store | 1,000 records per resource | honest: their in-memory cap is larger than our per-resource cap |
# everything the CRUD store ignores, working on a shared hosted URL:
curl 'https://mockbird.mockbird.workers.dev/m/demo/products?sortBy=price&order=desc&limit=2'
# failure and latency simulation without an expectation:
curl -i 'https://mockbird.mockbird.workers.dev/m/demo/products?mock_status=503'
curl 'https://mockbird.mockbird.workers.dev/m/demo/products/1?mock_delay=2000'
# create your own — one click, no terminal:
# https://mockbird.mockbird.workers.dev/app#new=ecommerceThe clean split: MockServer for the services you operate and virtualize, Mockbird for the backend that doesn't exist yet. Keep MockServer in CI where its proxy, verification, gRPC support, and chaos tooling earn their keep; point the frontend, the prototype, and the teammate's phone at a Mockbird project — a persistent, data-shaped API that's a URL, not a process.
| MockServer 7 (OSS) | Mockbird | |
|---|---|---|
| Price | free, Apache-2.0 | free while in beta |
| Hosted URL others can hit | no — self-host (Docker/Helm) to share | yes — 10,000 requests/project/day, no signup |
| Stateful CRUD | yes (7.x data store) — in-memory, wiped on restart/reset | yes — persistent database, snapshots, restore |
| Pagination/filter/sort/search on lists | no — all items in insertion order (verified) | always on, every resource |
| Relations / nested routes | no (between CRUD stores) | _expand/_embed + nested routes |
| Generated OpenAPI/Postman/types of your mock | no (imports OpenAPI; doesn't export the store) | yes — all three, from the live schema |
| Proxy, record & replay, verification | excellent — the whole point | none |
| Protocols beyond HTTP/1.1 | HTTP/2, gRPC, WS, TCP, HTTP/3 (exp.) | REST, GraphQL, SSE, WS echo |
| Identity-provider mocks (OIDC/OAuth/SAML) | yes — dedicated mocks | JWT mock auth (simpler: login/register/me) |
| Works offline / no request caps | yes | no |
| Install footprint | one command (native bundle, ~seconds to start) | zero — it's a URL |
| Maintenance | very active — v7.6.0 Aug 2026 | actively developed |
Written by the Mockbird maker — bias disclosed. Where MockServer genuinely wins: proxying and record-and-replay, request verification, protocol breadth (gRPC, WebSockets, raw TCP, HTTP/2/3), chaos tooling with Kubernetes recipes, identity-provider mocks, a matcher DSL we don't approach, Testcontainers integration, offline use with no caps — and it's free and Apache-licensed. Every behavioral claim above was verified by us on August 26, 2026 against MockServer v7.6.0 run via the official mockserver-node launcher (CRUD store registered per their docs; query params, restart wipe, reset wipe, id renumbering, and 404s all observed directly; the in-memory design and reset behavior are also stated in their CRUD documentation). If any of this changes, we'll update the page.
Full API reference in the docs. More guides: stubby4j alternative · WireMock Cloud alternative · Hoverfly alternative · mountebank alternative · Prism alternative · Karate mock server alternative · free mock API tools compared. Create your API →