A Mirage JS alternative you don't have to maintain

Credit where it's due: Mirage more or less invented the "build the whole frontend before the backend exists" workflow. The ORM, models with belongsTo/hasMany, factories, serializers, route shorthands — it's a genuinely elegant DSL, and a generation of Ember (and later React and Vue) developers shipped features against APIs that didn't exist yet because of it.

But if you're on this page you've probably hit one of the reasons people search for a Mirage JS alternative in 2026:

The release cadence has stopped. The latest miragejs on npm is 0.1.48, published October 2023 — still a 0.x — with 200+ issues open and an open GitHub issue literally titled "Is code still maintained?". The repo isn't archived and still sees occasional commits, but if you're picking a dependency for a new project, that cadence is a real signal.
The Ember integration is churning. ember-cli-mirage doesn't work under Vite/Embroider, and the community answer is a migration to a differently-maintained ember-mirage shim. If you're mid-migration, "do I even want this layer?" is a fair question.
The mock only exists inside your JavaScript bundle. Same hard boundary as MSW: Mirage intercepts requests inside your app's process. curl gets nothing. Postman gets nothing. Your mobile teammate gets nothing. A backend consumer gets nothing. A stakeholder demo needs your dev build running. The mock isn't a URL you can send anyone.
The server definition is code you ship-guard. Models, factories, seeds, serializers, route handlers — it lives in your repo, has to stay in sync with the real API by hand, and needs care to keep out of production bundles.

Mockbird is the hosted other half: a stateful mock REST API on a real URL. Define resources (or pick a preset, or import an OpenAPI spec / db.json / CSV / Postman collection), get realistic seeded data, full CRUD, relations, and error/latency injection — reachable from a browser, curl, Postman, a phone, a backend, CI, or a teammate. Nothing to install, nothing to maintain, no signup.

The 60-second version

# one curl, no signup — a whole seeded e-commerce backend
curl -X POST https://HOST/api/projects \
  -H 'content-type: application/json' -d '{"name":"shop","preset":"ecommerce"}'
# → {"id":"abc123","adminKey":"KEY", ...}   ← save both

curl https://HOST/m/abc123/products?limit=3
# → 3 seeded products, CORS on, writes persist

Prefer clicking? This link creates the same project in your browser — no account. Have an OpenAPI spec of your real API? Paste it at /app#import and mock your actual shapes.

Mirage concepts → Mockbird

Mirage	Mockbird	Notes
`this.resource('products')` shorthand	a `products` resource	list/get/create/update/delete generated, plus filtering, sorting, pagination, search
Factories + `server.createList(…)`	seeded realistic records	typed field types (names, emails, prices, dates, enums) — no factory code; or import your exact records from db.json/CSV
`belongsTo` / `hasMany`	`refId` fields + `?_expand` / `?_embed`	plus nested routes like `/products/1/reviews`
`timing: 400`	`?mock_delay=400`	plus `?mock_jitter` random latency and `?mock_chaos=0.3` random failures
`new Response(500)` in a handler	`?mock_status=500` on any URL	no handler edit, no rebuild — error/loading states guide
Serializers (root keys, envelopes)	`?mock_envelope`	wrap lists as `{"data":[…]}` or any custom template, per request or project-wide
Scenarios / seeds files	snapshots	save named data states; serve any GET from one via `X-Mockbird-Snapshot` — parallel test workers don't race
`server.db.dump()`	`GET /m/:project/db.json`	full dataset out anytime — works verbatim with json-server; no lock-in
Route handlers with JS logic	custom routes with templating	honest: templating is less powerful than arbitrary JS
`this.passthrough()`	not needed	Mockbird is a base URL you point at — real API calls are never intercepted in the first place
GraphQL via `graphql-mirage` addons	generated GraphQL endpoint	typed schema from your resources, GraphiQL included

Try it in 10 seconds (shared demo, no setup)

# seeded data with field projection
curl 'https://HOST/m/demo/products?limit=2&select=name,price'

# relations without factory wiring
curl 'https://HOST/m/demo/reviews?limit=1&_expand=product'

# the states you'd write route handlers for — as query params
curl -i 'https://HOST/m/demo/products?mock_status=503'
curl 'https://HOST/m/demo/products/1?mock_delay=2000'

# stateful: the write persists
curl -X POST https://HOST/m/demo/products \
  -H 'content-type: application/json' -d '{"name":"proof","price":9.99}'
# → returns {"id":31,…} — and GET /m/demo/products/31 now works

All against the shared demo project (resets daily).

Migrating an existing Mirage setup

Point the environment at Mockbird. Set API_BASE_URL to your project URL in dev/preview builds and delete the Mirage server file from those builds. Your components don't change — they were already coded against the API shape.
Recreate your schema in one paste. If the real API has an OpenAPI spec, import it and every model/factory you were maintaining by hand becomes a seeded resource. Got Mirage fixture data? Shape it as a db.json ({"products":[…],"reviews":[…]}) and import your exact records.
Keep Mirage where it still earns its place. If you have a large suite of fast offline unit tests built on Mirage's ORM, they can stay — use a hosted URL for everything Mirage can't reach: e2e against deployed previews, the mobile app, backend consumers, demos, teammates.

Honest comparison

	Mirage JS	Mockbird
What it is	free OSS library (JS)	free hosted service
Maintenance	last npm release Oct 2023 (0.1.48)	actively developed — nothing for you to maintain either way
Reachable from	your JS app's process only	anything with HTTP: browser, curl, Postman, mobile, backend, CI, agents
Setup	install + server file: models, factories, routes, seeds	one curl or one click; no code
Mock data	factories you write	seeded realistic data, or import your own
Relations	excellent ORM (`belongsTo`/`hasMany`)	`_expand`/`_embed` + nested routes; less expressive than a real ORM
Stateful CRUD	yes (in-memory, resets on reload)	yes — persists across reloads, days, and machines
Error/latency simulation	per-route code (`timing`, `Response`)	`?mock_status` / `?mock_delay` / `?mock_chaos` / `?mock_jitter` on any URL
Works offline	yes — no network at all	no — it's a real network call
Mocks the real URL transparently	yes — intercepts your actual API host	no — you point your app at a Mockbird base URL
Dynamic programmable responses	full JS — anything you can code	templated custom routes; less powerful than arbitrary code
Shareable	via your repo + dev build	via URL — nothing to install
Request cap	none	10,000/project/day

Written by the Mockbird maker — bias disclosed. Where Mirage genuinely wins: it runs entirely offline with zero latency, transparently mocks your real API URLs without touching app config, its ORM handles relational test data more expressively than anything URL-based, and route handlers are arbitrary JavaScript. If you have a healthy Mirage setup in fast unit tests, keep it. If you're choosing tooling today — or the thing you need is a URL that a phone, a teammate, CI, or curl can hit — that's us. (Maintenance facts checked July 2026 against npm and the miragejs GitHub repo; if they've shipped since, good — the URL boundary above still stands.)

Full API reference in the docs. More guides: MSW alternative · mock API for React · mock API for Vue · deterministic test data · free mock API tools compared. Create your API →