REA is light by itself and heavy through the engines it drives. This page lists what a local installation needs for each kind of target, then explains why hosting it is a different project.

Baseline

  • Node.js 22.x from 22.19, 24.x from 24.11, or 26 and later, with npm. Bun is supported as an alternative runner.
  • A desktop MCP client that launches local servers: Claude Code, Codex, Cursor, Gemini CLI or another agent listed in the upstream installation guide.
  • Disk and memory for the server itself are small. The idle MCP process stays well under 100 MB of memory. Everything significant comes from the providers below.

Run npx rea-agents setup to register the server with your agents and rea doctor to confirm what is ready.

Per-target requirements

Install only what your targets require.

  • JavaScript and Electron applications: nothing beyond Node.js. On Linux, a procps-compatible ps must be on the path because REA checks process ownership before launching helpers.
  • Native binaries (pseudocode, assembly, references): one of Ghidra, Hopper or IDA. Ghidra is free and the one we recommend; the current release is verified with Ghidra 12.1.4 and a Java 21 runtime. Ghidra's headless analyser starts with a 2 GB Java heap by default, and the installation guide documents heap and CPU controls. Large binaries may need a longer startup deadline through REA_GHIDRA_STARTUP_TIMEOUT_MS.
  • Android APKs: headless JADX and a full JDK on Linux, macOS or Windows x64. Apktool for decoded resources. adb for devices and emulators.
  • Apple applications, .NET assemblies, Go, Rust and Flutter metadata: built in, no extra tool.
  • Firmware images: Binwalk or Unblob on Linux for extraction, then a native provider for the code.
  • Network captures: HAR and SAZ files need nothing. Live or raw captures need mitmproxy or TShark on Linux.
  • Websites: a Chrome-family browser.
  • Runtime capture and instrumentation: Linux or macOS with a native pseudo-terminal; Frida for instrumentation; your user permissions apply to whatever runs.

Windows support for Ghidra is documented upstream as experimental. macOS on Apple silicon needs the native decompiler steps from the Ghidra section of the installation guide.

Operating system notes

  • macOS is the most exercised platform for Apple targets and works for Ghidra, JADX and JavaScript analysis.
  • Linux covers the widest set of targets, including firmware, packet and signal recordings, EVM bytecode and offline ELF diagnostics, several of which are Linux-only.
  • Windows works for JavaScript, Android and built-in static formats; native analysis through Ghidra is experimental there.

What changes in the cloud

Running REA for other people is not a matter of starting rea mcp on a server. Five things change.

  1. Transport. REA speaks MCP over stdio only. Hosted clients such as ChatGPT or Claude's remote connectors need a Streamable HTTP endpoint with authentication. Something must sit in front of REA, accept HTTP, authenticate the caller, start a REA process for that caller and bridge the two.
  2. Targets become uploads. REA reads absolute paths on its own filesystem. A hosted service needs an upload step, a per-user storage area, retention rules and deletion on request.
  3. Isolation. Analysis engines parse hostile input by design. Each user session should run in its own sandboxed container with no outbound network, and runtime tools that execute, attach to or instrument programs should not be exposed at all. REA has no built-in tool allowlist, so the gateway has to filter.
  4. Licences. Ghidra, JADX, Apktool and Kuna are open source and can be offered as a service. Hopper and IDA are licensed per user and their terms do not cover a hosted, multi-tenant deployment, so a hosted REA is Ghidra-based for native code.
  5. Sizing. The REA process is small, but each native analysis holds a multi-gigabyte Java heap for its duration. A machine with 32 GB of memory comfortably serves a handful of concurrent Ghidra analyses alongside many light JavaScript or Android sessions. Costs are dominated by that machine and by storage for uploads, not by the MCP traffic.

A managed image also needs the engines preinstalled and verified with rea doctor at build time, so users never see a missing-JDK error.

Our hosted endpoint

We are building exactly this: an authenticated remote REA MCP endpoint with the open-source engines installed, restricted to static analysis of files you upload, with isolated sessions. It is in early access. Request your dedicated REA MCP and we will get in touch with connection details. For the local route, our REA project page walks through the client configuration.