Yes: Firenook is a direct, open source replacement for the official Firebase Emulator, written in Rust with no Java, that reads your firebase.json and uses the same ports. We installed version 0.2.1 and tested it against Google’s Firebase Local Emulator Suite on the same machine. The big difference isn’t in writes, but in queries and memory as your data grows.
yoDEV Tested · November 6, 2026
We tested Firenook 0.2.1 against firebase-tools 15.35.0 (Firestore Emulator v1.22.0, OpenJDK 21) with Node 22.23.4 on Linux x64, 2 vCPU and 7 GiB of RAM. The results we report as ours come from that test.
What is Firenook and what does it replace from the Firebase Emulator?
Firenook locally emulates Firestore, Authentication, Cloud Storage, Cloud Functions, Pub/Sub, Cloud Tasks, Eventarc and Extensions, on the same default ports as the official suite (Firestore 8080, Auth 9099, Storage 9199, Functions 5001). It maintains the official import and export format, so you can switch back to Google’s emulator whenever you want. The services run as native code within a single npm package, and it downloads nothing else either when installing or starting.
It’s an independent project with an Apache-2.0 license: Google doesn’t make it and it’s not affiliated with or endorsed by Google. It was previously published as Fireside (@fireside-dev/cli); since 0.2.0-next.1, all versions are released as firenook. According to npm, version 0.2.0, which the README presents as the first stable version, was published on October 23, 2026. Neither the website nor npm metadata names a responsible person, only the organization firenook-dev.
How much faster than the official Firebase Emulator, according to the project?
According to its own benchmark, about 40 times faster on writes and with 10 times less memory. The project replayed two hours of traffic from a production application (211,205 Firestore documents and 6.7 GB in Storage) against each emulator in turn, on the same server with a Ryzen 5 3600 and 64 GiB of RAM:
| Metric (median) | Official | Firenook |
|---|---|---|
| Peak memory | 22.6 GiB | 2.11 GiB |
| Write | 208 ms | 5.1 ms |
| Listener update | 209 ms | 11 ms |
| Restart preserving data | 30.8 s | 0.59 s |
| CPU in two hours | 1,586 s | 616 s |
These are self-reported figures. Raw samples are published on GitHub, but the application and its data are private, so nobody can exactly repeat that test.
There’s a detail on that page that matters more than the headline: when the two hours started, the official stack already had 7.7 GB in swap, and paged 3.1 GB more during the test. The project itself acknowledges that on a machine with more memory the official emulator would use less swap. Part of that 40x difference in writes is explained because the official emulator was under memory pressure, not just because its engine is slower.
The project’s most convincing result doesn’t depend on swap. With 2.7 million documents, the official emulator ran out of memory with Java’s default configuration. With a 24 GiB heap it did start, but took between 8 and 27 seconds to respond to queries like orderBy … limit 20. Firenook responded to the same queries in 3 to 6 ms.
What did we measure when comparing it to the Firestore Emulator?
We ran the same Node script with firebase-admin against each emulator, on the same machine: sequential writes of documents and then 50 runs of a query (array-contains + descending orderBy + limit 20).
| Measure | Official | Firenook |
|---|---|---|
| Cold start (Firestore + Auth) | 8.4 s | 0.53 s |
| Write, median, 20,000 docs | 0.89 ms | 0.94 ms |
| Write, p99, 20,000 docs | 4.67 ms | 3.43 ms |
| Query, median, ~2,000 docs | 18–20 ms | 3.8 ms |
| Query, median, ~20,000 docs | 168.7 ms | 3.4 ms |
| Emulator memory, ~4,000 docs | ~500 MiB (Java + Node) | 41 MiB |
| Emulator memory, ~20,000 docs | 658 MiB | 111 MiB |
| Restart with 20,000 docs preserved | — | 0.54 s, all 20,000 intact |
Three takeaways:
- With little data and no memory pressure, writes tie. We didn’t reproduce the 40x figure on writes. Expect it only if your official emulator is using swap.
- Where you notice it is in queries. Going from 2,000 to 20,000 documents, the official emulator became about ten times slower, while Firenook stayed stable. With 20,000 documents, the difference was about 50x.
- Memory is always five to ten times smaller, and Firenook starts in half a second.
How do you install it and how does it replace firebase emulators:start?
You need Node 22, 24 or 26 on macOS, on Linux x64 or arm64 with glibc 2.28 or higher, or on Windows x64. Install it as a dev dependency and keep firebase-tools for deploying, because Firenook has no deploy or login commands:
npm install --save-dev firenook
First review your current project. The simulation doesn’t write anything:
npx firenook init --adopt --dry-run
In our test, the plan skipped the Realtime Database emulator with a warning and offered to create a .mcp.json for Claude Code. Then change the commands in your package.json scripts. The usual flags (--only, --project, --import, --export-on-exit, --inspect-functions) work the same way:
"scripts": {
"emulators": "firenook emulators:start --import ./data --export-on-exit",
"test:integration": "firenook emulators:exec \"npm test\""
}
In our test, init --adopt didn’t rewrite existing scripts, so you make that change yourself. Also add .firenook/ to your .gitignore: that’s where Firenook saves the working files from each run, and it never auto-deletes them.
How do you keep data between emulator runs?
Replace --export-on-exit with --keep-data and keep --import ./data in the command:
npx firenook emulators:start --import ./data --keep-data
In our test, restarting with 20,000 documents took 0.54 seconds, and all the documents were still there.
Watch out for a detail in 0.2.1, which the project lists among its known issues: --keep-data requires having Firestore, Auth and Storage configured. With only Firestore and Auth, our start failed with --resume-state requires the firestore, auth and storage services. We solved it by adding the Storage emulator to firebase.json.
What doesn’t Firenook emulate yet?
In version 0.2.1, as of November 6, 2026:
- Not emulated at all: Realtime Database, Hosting, App Hosting, Data Connect and universal extensions. A
firebase.jsonthat configures them starts fine, with a warning. - Cloud Functions: no Python or Dart functions, nor Secret Manager.
functions:shellis replaced byfirenook functions:invoke. - Auth: no multifactor TOTP, nor reCAPTCHA enforcement, nor real email or SMS sending.
- Pub/Sub and Cloud Tasks: data doesn’t survive a restart.
- Platforms: no support for Alpine/musl (ruling out many Docker base images), Windows on Arm, or 32-bit Windows.
- Console: Google’s Emulator UI is replaced by Firenook’s own console on the same port (
http://127.0.0.1:4000/console).
If your project depends on Realtime Database or Python functions, Firenook can’t replace the official suite today.
Can you use it with Claude Code, Cursor or VS Code?
Yes. npx firenook mcp add configures an MCP server for Claude Code, Cursor or VS Code, and init --adopt offers to write Claude Code’s .mcp.json for you. That way an agent has direct access to local emulators while writing and testing Firebase code.
Is it worth switching Firebase emulators?
Yes, if your Firestore Emulator consumes gigabytes of RAM, takes seconds to respond to queries on a realistic dataset, or forces you to install Java on every CI runner: in that case, Firenook deserves an afternoon of testing. The change is reversible: npx firenook emulators:export ./export exports in the official format, and the official CLI starts from that export. But never run the two on the same ports or in the same working directory.
If your bottleneck is write latency with small datasets, you won’t notice much. And keep in mind it’s a young project, at 0.2.x and with no named maintainer: commit your lockfile and update deliberately, as its own documentation recommends.
What about you? How much memory does the Firebase Emulator consume today on your machine or in your CI?
- With the official Firebase Local Emulator Suite
- I’ve already tried Firenook
- I don’t emulate: I test against a real project
- I prefer another option (tell us which)
Comment below or, if this article reached you by email, reply directly to the email: your reply is published here.
Related: The Firebase crash on iOS: what happened and why disabling Analytics didn’t protect your app