What Is Firenook? The Beginner's Guide to Running Firebase Emulators Without Java

CodexFuse Team · 2026-11-05T23:44:16.629Z · 24 min read min read

What Is Firenook? The Beginner's Guide to Running Firebase Emulators Without Java

So what is Firenook? Firenook is a free, open-source drop-in replacement for the Firebase Local Emulator Suite that runs your local Firebase emulators as native Rust services from one npm package, with no Java to install. It reads the project files you already have — the same firebase.json, the same security rules, the same Functions code, the same client and Admin SDKs — and serves them on the same ports the official emulators use.

If you build with Firebase and you are tired of waiting on a Java-based emulator that eats memory and forgets your data at every stop, this guide explains what Firenook is, what it covers, what it skips, and how to start it.

The current release is Firenook 0.2.1, published on 4 November 2026, two days before this article was written. It is a young project with a short public history, and this guide treats it that way: every speed figure comes from Firenook's own measurements and is labelled as such, every gap is stated plainly, and nothing here promises more than the docs deliver. A SHA-256 hash generator is the kind of small, instant tool that shows what a local-first workflow feels like, and Firenook brings the same idea to your Firebase backend: your data stays on your machine, your tests run against a local copy, and nothing leaves the laptop.

If your backend lives on a server you rent rather than on Firebase, our guide to VPS hosting explains that side of local-versus-remote development.

What Is Firenook?

Firenook is a drop-in replacement for the Firebase Local Emulator Suite. The Firebase Local Emulator Suite is Google's official set of local tools for building and testing Firebase apps without touching production data, covering Cloud Firestore, Realtime Database, Cloud Storage, Authentication, Hosting, Cloud Functions, Pub/Sub, and Extensions. Firenook replaces the local half of that setup: it serves eight of those emulators from a single npm package, written in native Rust, so you never install Java and never download emulator archives.

The drop-in part matters more than the speed part. Firenook runs your project from the files you already have, so switching does not mean rewriting anything. Your firebase.json stays as it is, your rules stay as they are, your Functions code stays as it is, and your app connects exactly as it did before.

The docs put it plainly: the same firebase.json, rules and Functions code, the same client and Admin SDKs, and the same ports. That is the whole pitch in one sentence.

Firenook is an independent open-source project under the Apache License 2.0, and it is not affiliated with or endorsed by Google. Firebase and Cloud Firestore are trademarks of Google LLC. There is no pricing page and no paid tier anywhere on the site; the homepage FAQ answers "Is it free?" with a plain yes.

Firenook also sends no telemetry, and the site sets no cookies and shows no ads, according to its privacy page, last changed 2 November 2026.

The project lives at github.com/firenook-dev/firenook, in the firenook-dev organisation. At the time this article was researched, the repository showed 5 stars, 1 fork, and 1,197 commits, with the repo created on 9 September 2026. Those counts are a snapshot and will have moved since.

The small star count is honest context: this is a new project, not an established one, and the rest of this guide weighs it accordingly.

How the Drop-In Replacement Works

Switching from the official Firebase emulators to Firenook means changing one word in your scripts. The command firebase emulators:start becomes firenook emulators:start, and firebase emulators:exec becomes firenook emulators:exec. The docs describe the switch as three steps: check your project, swap the command, and keep working.

Your app needs no change, because every emulator listens on the port your firebase.json gives it.

The compatibility runs deeper than the command name. Firenook reads and writes the official export format, so --import takes the data you already have, and it accepts the same flags you already use, including --only, --project, --import, --export-on-exit, --inspect-functions, and --ui for emulators:exec. Your app connects the same way it always has: connectFirestoreEmulator(db, '127.0.0.1', 8080), the FIRESTORE_EMULATOR_HOST environment variable, and the rest all work as before.

One thing does not change, and it is worth stating early: Firenook has no deploy or login command. Keep firebase-tools installed for deploying, because Firenook only replaces the local emulators, not the Firebase CLI. That split is deliberate, and it is also the reason the switch is safe to try: your deployment path never moves.

npm install --save-dev firenook
npx firenook emulators:start
npx firenook emulators:start --keep-data
npx firenook emulators:exec "npm test"

Those four commands are the whole working set for most developers. Install the package, start the emulators, add --keep-data when you want your data to survive a restart, and run your test suite through emulators:exec when you want a clean one-shot run. The package also works with pnpm, Yarn, and Bun, and npx firenook, pnpm exec firenook, yarn firenook, and bunx firenook all start the same emulators.

The Eight Emulators Firenook Runs

Firenook serves eight emulators, all on the ports you already use. The homepage states it plainly: "Eight emulators, on the ports you already use." Every Firenook Firebase emulator is a native Rust service inside the single npm package, and the console, hub, and logging services sit on the official suite's ports too: the console on 4000, the hub on 4400, and logging on 4500.

A few details inside those rows deserve a closer look. Firestore runs in Standard edition, Native mode, and it supports realtime listeners, queries with filters, or queries, ordering, cursors, limits, collection-group queries, count() aggregations, and vector search with findNearest(). It also serves every database a client names, and each database listed in firebase.json gets its own rules — something the official emulator refuses to do, since it reports that it does not support multiple databases yet and then loads no rules at all.

Authentication is the most complete of the eight. The docs say it covers all 61 operations of the official Auth emulator, including password sign-in, email links, phone auth, multi-factor auth, passkeys, multi-tenancy, and blocking functions. Cloud Functions covers every trigger type — Firestore, Storage, Auth, Pub/Sub, Eventarc, schedules, and task queues — and your code reloads when you save.

Pub/Sub covers every RPC, including dead-letter topics and snapshots, and Cloud Tasks reproduces the official retry and rate-limit behaviour.

What Firenook Does Not Emulate

Firenook does not emulate four Firebase services, and the docs state the gap identically on the homepage, in the docs, in the README, and in the switch guide: Realtime Database, Hosting, App Hosting and Data Connect are not emulated. A firebase.json that configures them still starts, with a warning, so a project that uses one of them is not blocked from starting — it simply does not get a local copy of that service.

The gap matters most for Realtime Database, because it is the service many older Firebase projects still rely on. If your app reads and writes the Realtime Database, Firenook alone cannot run your full local stack, and you would keep the official emulator for that service. The same applies to Hosting: if your workflow leans on the Hosting emulator's preview URLs, Firenook does not replace that step.

There are also smaller gaps inside the services Firenook does emulate. Firestore runs Standard edition, so Enterprise edition pipeline queries fail with the same error they would hit on a Standard database. Authentication does not do the things the official emulator answers with a 501 — identity provider, SAML and OIDC configuration, initializeAuth, IAM on tenants, Game Center, reCAPTCHA enforcement, and TOTP second factors.

It also sends no real email or SMS, and its ID tokens are unsigned, exactly as the official emulator's are.

Firenook vs Firebase Emulators: The Honest Comparison

Firenook vs Firebase emulators is not a contest between equals, because the two are not the same kind of product. The official Firebase Local Emulator Suite is Google's own tooling, and it covers more services. As a Firebase Local Emulator alternative, Firenook is an independent, newer, narrower replacement that trades breadth for speed and for a simpler install.

The table below compares them on the points that decide a switch.

The Java requirement is the difference most developers feel first. Google's own docs require Node.js version 16.0 or higher and Java JDK version 11 or higher before installing the official suite, and the Realtime Database, Cloud Firestore, and part of the Cloud Storage emulators are Java-based, with their JAR files cached under ~/.cache/firebase/emulators/. Firenook removes that whole layer: the emulators run on Node 22, 24, or 26, and your Functions run on the same Node, as they run on Node in production.

Other Firenook commands, such as init and --version, run on any Node from 20 up, and Node 23 or 27 starts with a warning rather than failing.

The console difference is the second real gap in Firenook's favour. The official Emulator UI has no pages for Functions, Pub/Sub, Cloud Tasks, or Eventarc — only a log — while Firenook's console covers every service it runs, with every function call listed alongside its trigger, outcome, duration, and logs. If you spend your debugging time watching function calls, that is a genuine quality-of-life difference.

The choice between the two is ultimately a choice between Google's breadth and an independent project's speed, and Firebase itself is only one way to run a backend: if you want the wider picture of hosted backends and servers, our guide to cloud computing explains how the pieces fit together.

How Fast Is Firenook, Really?

Firenook's headline claim is speed, and it comes with numbers that look dramatic: 40 times faster writes and 10 times less memory. Those figures are Firenook's own measurements, not independent benchmarks, and the honest version of the story includes the qualifier the author states himself. On an idle emulator, a single write is only about 1.5 times faster; the 40 times figure is under load.

This section gives you the full numbers, the method behind them, and the arithmetic to check them yourself.

The benchmark ran Firenook against firebase-tools 15.22.0 on Java 26, measured on 21–22 October 2026 on one server: an AMD Ryzen 5 3600 with 64 GiB of memory, NVMe storage, Ubuntu 24.04, and Node 24.20.0. The workload was one real production application — 211,205 Firestore documents, 33,352 Storage objects totalling 6.7 GB, and one Auth user — with two hours of its traffic replayed against each emulator in turn. Every operation was timed by the client, and every multiple is rounded down.

The arithmetic checks out against the rounded claims. Dividing 208.2 by 5.1 gives 40.8, which rounds down to the claimed 40 times; 22.57 divided by 2.11 gives 10.7, rounding down to 10 times; 30.8 divided by 0.59 gives 52.2, rounding down to 52 times; and 616 divided by 1,586 is 38.8 percent of the official figure, which is 61.2 percent less. In plain terms, each write under load saves 203.1 milliseconds, and the peak memory bill drops by 20.46 GiB.

The Show HN post by the builder puts the same story in words: a heap that grew past 22 GiB on their app, out-of-memory crashes, and data gone at every stop unless exported.

Two details keep the picture honest. First, 25 of 26 query shapes were faster and one tied, and inside the Storage cycle downloads were the one step where Firenook was not faster — 2.30 ms against 2.12 ms for the official emulator. Second, the benchmarks page itself says the run covered one server and one application, and tells readers to measure their own workload before relying on the numbers.

Firenook also says an independent audit recomputed every figure from raw samples and verified 95 checksummed evidence files, but the application and its data are private, so the run cannot be repeated as it stands. Treat the figures as a strong signal from the maker, not as a third-party verdict.

How to Install Firenook and Start Your Emulators

To run Firebase emulators without Java, install Firenook, check your machine, and start the suite. The whole setup is five steps, and the only real prerequisite is the right Node version.

1. Check your Node version. Firenook needs Node 22, 24, or 26 for the emulators, so run node --version first. Pick the version your Functions target, since your Functions run on the same Node the emulators use.
2. Install Firenook in your project. Run npm install --save-dev firenook next to firebase-tools, which you keep for deploying. The package is a small launcher, and your package manager installs only the engine that matches your machine.
3. Run the doctor check. In a project with a firebase.json, run npx firenook doctor. It runs the checks that emulators:start runs, starts nothing, and prints what it found as JSON.
4. Start the emulators. Run npx firenook emulators:start. You get a live terminal screen with the start-up summary and a line for every function call, plus the web console on port 4000.
5. Keep your data, or run your tests. Add --keep-data when you want your data to survive restarts, or run npx firenook emulators:exec "npm test" to run your suite once the emulators are ready.

Platform support covers macOS on Apple silicon and Intel, Linux x64 and arm64 with glibc 2.28 or newer, and Windows x64. Each platform has its own engine package, and your package manager installs only the one that matches your machine. Alpine Linux with musl is not supported, so container-based setups built on Alpine need a glibc image instead.

Working data lives in a .firenook/ directory in your project, and firenook init adds it to your .gitignore for you.

One practical note from the docs: if your functions/package.json asks for Node 24 in engines.node but you start the emulators with Node 22, your Functions run on Node 22, not 24. Start the emulators with the Node your Functions target, and the mismatch goes away. The --version output at research time read 0.2.1 with an engine source hash, which is how you confirm the exact build you are running.

The Console, the Terminal Screen, and the MCP Server

Firenook ships three ways to watch and drive your emulators, and the console is the one you will live in. The web console replaces Google's Emulator UI on the same UI port, at http://127.0.0.1:4000/console, and it covers every service Firenook runs. Each function call appears with its trigger, outcome, duration, and logs, the Auth section holds an inbox of sign-in codes and links, and the security rules sit beside each decision they made.

It works in light and dark mode, works offline, and sends nothing anywhere.

The terminal screen is the second view. Starting the emulators shows a start-up card, then one line per function call with its outcome and a stack trace on failure. Press o for the console, r to reload, and q to quit, which saves your data first.

In CI the same start prints plain lines instead, so your logs stay readable in a pipeline.

The third tool is the MCP server, and it is the one that matters most if you build with an AI coding assistant. Running firenook mcp gives a coding agent 54 tools over the running suite, and npx firenook mcp add sets it up for Claude Code, Cursor, and VS Code. Nothing leaves the machine.

If the idea of an agent driving your tools is new, our guide to the Model Context Protocol explains how that connection works, and our guide on how to use Claude Code shows the assistant side of the same workflow.

Keeping Your Data Between Runs

Data persistence is the quietest big difference between Firenook and the official emulators. With the official suite, your data is lost when the emulators stop unless you export it first, using --import, --export-on-exit, or emulators:export. Firenook keeps your data by default in a different way: it saves first when you stop it, and --keep-data restores Firestore, Auth, and Storage from .firenook/state in about 0.5 seconds on the next start.

The restart numbers make the difference concrete. Firenook's own benchmark measured a restart with data kept at 0.59 seconds, against 30.8 seconds for the official emulator — 52 times sooner, or 30.21 seconds saved on every restart. Over a day of stopping and starting emulators between tasks, that adds up to minutes of waiting removed.

The changelog's release-by-release figures tell the same story at a larger scale: opening saved data for 2.7 million documents fell from 146 seconds to 67 milliseconds between preview releases, which is 2,179 times sooner, and an ordered query over the same 2.7 million documents fell from 5,128 milliseconds to 4.3 milliseconds, which is 1,192 times faster.

Going back is just as straightforward, because Firenook reads and writes the official format both ways. Stop Firenook, which saves first, then export with npx firenook emulators:export ./export and start the official CLI on that export. Nothing is locked in, and 0.2.1 opens what 0.2.0 saved, and vice versa, because no emulator protocol, port, or data format changed between those two releases.

That two-way compatibility is what makes trying Firenook a low-risk experiment rather than a migration.

Firenook 0.2.1 and the Fireside Story

Firenook 0.2.1 is the latest release, published on 4 November 2026, and it arrived two days before this article was written. The version before it, 0.2.0, published on 23 October 2026, was the first stable release — the changelog entry calls it the first release for public use, and the README says the same. That is the safe way to describe the history: 0.2.0 was the first stable, public release, and 0.2.1 is the current release.

The changelog's own wording is slightly tangled on this point, calling 0.2.1 the first release for public use in its introduction, so this guide follows the README and the 0.2.0 entry instead.

The project is older than its public release date suggests. It began as Fireside, with ten 0.1 preview releases published as @fireside-dev/cli between 7 and 19 September 2026 — 12 days, ten releases, roughly one a day. The 0.2 line then added ten more releases between 19 September and 4 November, for twenty releases in total across 58 days from the first preview to 0.2.1.

The repository itself was created on 9 September 2026, which is 56 days before the 0.2.1 release. Presenting Firenook as brand-new from 4 November would skip that preview history, and the history matters: two months of daily releases is a very different signal from a project that appeared overnight.

The 0.2.1 release itself is a small one. Its changes are popup sign-in from a LAN address or a container name, saved rules tests from such an address, a sign-in page in the console's look with provider test accounts and a filter once there are eight or more, "New random user" and "Fill in random" helpers on the sign-in form, and small things such as init suggesting npm i -D firenook without the exact-version flag. The Show HN post followed one day later, on 5 November 2026, posted by HN user sanjevirau with 2 points and 1 comment at the snapshot taken that evening.

Those counts are a snapshot and will have moved since.

Problems You May Hit — and the Fix

Most Firenook problems come from the Node version, and the docs warn about them directly. If you start the emulators on Node 20, Firenook tells you the emulators need Node 22, 24, or 26, and suggests switching to Node 24. If your Functions target Node 24 but you start on Node 22, your Functions run on Node 22, and the fix is to start the emulators with Node 24.

Run npx firenook doctor before you start, and it prints what it found as JSON without starting anything.

Platform problems are the second category. Alpine Linux with musl is not supported, because the engine packages are built for glibc 2.28 or newer, so a Docker setup on an Alpine base image needs a glibc image instead. On macOS, Linux, and Windows x64 the install works as documented.

If a firebase.json configures one of the four services Firenook does not emulate, the project still starts, with a warning — that warning is expected behaviour, not an error to chase.

Two behaviour differences are worth knowing before they surprise you. Firestore runs Standard edition, so an Enterprise pipeline query fails with a 9 FAILED_PRECONDITION error about pipeline operations needing an Enterprise database. Authentication answers some operations with a 501, exactly as the official emulator does, for identity provider, SAML and OIDC configuration, initializeAuth, IAM on tenants, Game Center, reCAPTCHA enforcement, and TOTP second factors.

Neither is a bug; both are documented limits, and both are reasons to keep the official emulator nearby for the services and operations Firenook does not cover.

Is Firenook Right for Your Project?

Firenook fits a specific kind of Firebase project, and the fit decision is simple once you check the four gaps. If your app uses only the eight emulated services, you run Node 22, 24, or 26, and you are tired of Java installs, slow starts, and lost data, Firenook is worth trying this week. If your app leans on one of the four services it does not emulate, keep the official emulators for that service and use Firenook for the rest, or wait for a later release.

A related project is worth one mention for Firestore-only work. Hidane is a different project by different people: a single Rust binary that replaces only the Cloud Firestore emulator, at version 0.5.1, with no Java and starts in milliseconds. It is not Firenook, and it does not cover the other seven services, but if your project is Firestore-only it is another option in the same no-Java direction.

CodexFuse does not offer a Firenook tool, and this article does not promise one; it is a guide to a third-party project, not a product announcement.

The strongest reason to try Firenook now is that trying costs almost nothing. The switch is one word in a script, your data exports back to the official format, and 0.2.1 opens what 0.2.0 saved. The strongest reason to wait is equally plain: the project is two days past its current release, five stars on GitHub, and still missing four services.

Both facts are true at once, and the table above is the honest way to hold them.

Sources

Every fact in this article comes from a source fetched on 6 November 2026. Firenook's own pages are the primary source for what the project does; Google's Firebase docs are the primary source for the official suite; the Show HN post is the only third-party coverage found, and no independent Firenook explainer, how-to, or review existed at the time of writing.

• Firenook homepage — https://firenook.dev/
• Firenook docs — https://firenook.dev/docs
• Firenook install guide — https://firenook.dev/docs/get-started/install
• Firenook switch guide — https://firenook.dev/docs/get-started/switch
• Firenook changelog — https://firenook.dev/changelog
• Firenook 0.2.1 release notes — https://firenook.dev/changelog/0.2.1
• Firenook benchmarks — https://firenook.dev/benchmarks
• Firenook privacy page — https://firenook.dev/privacy
• Firenook on GitHub — https://github.com/firenook-dev/firenook
• Firenook 0.2.1 release tag — https://github.com/firenook-dev/firenook/releases/tag/npm-v0.2.1
• Show HN post, via the Algolia Hacker News API — https://hn.algolia.com/api/v1/search?query=firenook&tags=show_hn
• Firebase Local Emulator Suite introduction — https://firebase.google.com/docs/emulator-suite
• Firebase emulator install and configuration — https://firebase.google.com/docs/emulator-suite/install_and_configure
• Hidane, a separate Firestore-only emulator project — https://hidane.dev/

Frequently Asked Questions

Is Firenook free?

Yes. Firenook is open source under the Apache License 2.0, and there is no pricing page and no paid tier anywhere on the site. The homepage FAQ answers "Is it free?" with a plain yes.

It also sends no telemetry, and the site sets no cookies and shows no ads.

Does Firenook need Java?

No. Firenook runs its emulators as native Rust services in one npm package, and the only requirement is Node 22, 24, or 26. The official Firebase emulators need Java JDK 11 or higher, which is the install step Firenook removes entirely.

Other Firenook commands, such as init and --version, run on any Node from 20 up.

Does Firenook replace firebase-tools?

No. Firenook replaces only the local emulators; it has no deploy or login command, so you keep firebase-tools installed for deploying. The switch is safe to try precisely because your deployment path never moves, and your data exports back to the official format whenever you want to go back.

Can I switch back to the official emulators?

Yes. Stop Firenook, which saves your data first, export with npx firenook emulators:export ./export, and start the official CLI on that export. Firenook reads and writes the official format both ways, so the round trip loses nothing.

Does Firenook emulate Realtime Database?

No. Realtime Database is one of the four services Firenook does not emulate, and a firebase.json that configures it still starts, with a warning. If your app depends on Realtime Database, keep the official emulator for that service while you use Firenook for the rest.