EverRoom: a local-first context workspace that keeps sources next to decisions
EverRoom - A workspace that remembers your projects, decisions, and sources.
At a glance
- What is it?
- EverRoom is an Electron and TypeScript workspace that turns files, repositories and conversations into scoped Context Rooms with an evidence ledger and a reviewable Agent. It is early, macOS-first, and the storage schemas are still moving.
- Who is it for?
- Adopt EverRoom if you keep project context in scattered files, repos and meeting notes and you want that material assembled into a bounded room an agent can read, with provenance you can inspect. Do not adopt it if you need Windows or Linux as a first-class target, enterprise administration, or a frozen storage schema, because the README states that APIs, storage schemas and agent contracts may change while the first complete local workflow is being finished.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 16, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap EverRoom targets: context that survives the chat window
Most AI tooling assumes the hard part is generation. EverRoom starts from the opposite claim, stated in its README: agents produce a useful next step when they have the right context, and the difficult work is finding the relevant material, separating facts from guesses, and remembering what has already been decided. The project is aimed at a single person or a small team running several ongoing responsibilities, where the same decision gets re-derived because the meeting note, the repository and the earlier conclusion never sat in one place.
The README is explicit about what it is not: not another chat client, not a thin RAG screen, and not a notebook that accumulates unreviewed summaries. That framing matters because it sets the adoption bar. EverRoom asks you to bring material in and route it, rather than paste a question and accept an answer. If your workflow is one-off questions against a document you already have open, the product model is heavier than the task.
How the loop works: ingest, evidence ledger, Knowledge Room, Agent
The README describes a closed loop with seven stages, and the repository layout backs it up. Sources (local files, repositories, conversations, audio, and optional services such as Feishu, Slack, Notion or Gmail) go through unified ingest, which normalizes, classifies and applies policy. The output is an evidence ledger holding identity, versions and provenance. From there, knowledge and memory are derived: wiki pages, entities, and layered MemoryCore derivations the README labels L0 to L3. A Context Room is the working surface for one project, person, topic or responsibility, and the Agent plus Context Docs operate inside that scope.
The design decision worth noting is reversibility. The README states the loop is deliberately reversible and that a generated summary is useful only when a person can inspect where it came from, correct it, and let the correction flow back into the next task. Concretely, document changes are committed through a document kernel, recorded as operations, and sent back through the same ingest path. That is a different architecture from a pipeline that writes summaries into a store nobody re-reads.
The boundary is enforced at the agent level. An Agent receives only the Room-scoped tools and documents needed for the current request. The stated purpose is a bounded context window instead of a global prompt dump. Whether that holds in practice depends on how aggressively routing decides what belongs to a Room, and the README does not publish the routing heuristics.
Running the desktop from source with pnpm
The repository is a pnpm workspace. The root package.json declares packageManager pnpm@11.15.1 and a dev script that filters to the desktop app. The README notes that the desktop can start with the isolated development runtime, and that some features require optional local services or model credentials.
Start by installing dependencies at the root, then launch the desktop:
pnpm install
pnpm devThe dev script resolves to pnpm --filter @nxcore/desktop dev, so the Electron and React workspace is what opens. Building is split: the build script compiles the gateway first and the desktop second.
pnpm build
pnpm typecheck
pnpm testThe gateway is a Fastify 5 service supervised by Electron, with REST, WebSocket and an OpenAPI boundary plus health and readiness checks. Its defaults come from .env.example, which you can copy to .env. The gateway binds loopback on port 3210 and writes to .data by default:
NXCORE_GATEWAY_HOST=127.0.0.1
NXCORE_GATEWAY_PORT=3210
NXCORE_GATEWAY_DATA_DIR=.data
NXCORE_GATEWAY_LOG_LEVEL=infoOne first-run decision sits in that file. NXCORE_AGENT_RUNTIME defaults to fake, and the comment says to use pi after configuring the AI values. Until you change it, expect the agent path to be a stub rather than a model call. The same file sets NXCORE_DESKTOP_PAGE_MODE to sources by default, with connectors as the alternative, and notes that the desktop exposes exactly one of the duplicate source and connector pages. Packaging targets are macOS and Windows through package:mac and package:win, but the README states macOS is the current development target.
Where EverRoom is the wrong tool
The README lists product boundaries directly: no continuous screen recording, no autonomous multi-agent swarm, no enterprise administration, and no mandatory cloud synchronization. Those are deliberate exclusions in the first release, not missing configuration. If your requirement is fleet management with central policy, or a recorder that captures everything on screen, EverRoom does not attempt it.
The sharper limitation is schema stability. The README states that APIs, storage schemas and agent contracts may change while the first complete local workflow is being finished. A workspace whose value comes from accumulating memory over months is exposed to that: the evidence ledger and MemoryCore layers are exactly the parts most likely to move. The release history reinforces the point. The recent releases are desktop-v0.1.7-nightly builds published on consecutive days, which is a nightly cadence rather than a stabilised line.
There is also a platform constraint. macOS is the development target, and the README does not present Windows or Linux as equally exercised. The packaging scripts exist for Windows, but a package script is not the same as a supported target. If your team is on Linux, treat this as unproven. Finally, the connector layer defaults to a SaaS-hosted mode: per the .env.example comments, the desktop obtains the oo base URL and a per-user runtime token from EverRoomSass and talks to oo directly. A local-first product still has a sign-in path that reaches a hosted service, and the README does not document what happens to that path offline.
How it differs from Obsidian and Notion
Obsidian and Notion both appear in the repository topics, and the comparison is useful because the difference is architectural rather than cosmetic. Obsidian gives you local Markdown files and a link graph; the vault is the source of truth and plugins extend it. Notion gives you hosted, structured pages and databases with a collaborative editing model. EverRoom puts a third layer underneath both: an evidence ledger with content hashes, versions, provenance and policy snapshots, from which wiki pages and entities are derived rather than authored directly.
That changes the unit of work. In Obsidian, you write the note and it is the record. In EverRoom, a source is preserved with stable identity and version history, routing decides whether it becomes a Room wiki page, an entity candidate, a memory document, or only a link, and the Room profile summarizes the current goal, status, people, risks, decisions and timeline from settled material. The README's stated protection for Knowledge is durable project vocabulary without silently ingesting everything.
The cost is that you cannot treat the wiki as the primary artifact. It is a derivation with a lifecycle, and the README does not document how a derivation is rolled back if routing puts a source in the wrong place. That is the trade: provenance and reviewability in exchange for a system you have to operate, not just write into.
Maintenance cost, licence and what to pin
The last push to the repository was on 2026-09-15, and the most recent release is desktop-v0.1.7-nightly.20260915.59 from the same day. The repository is not archived. The README carries an important banner stating the project is under active development, macOS is the current development target, and APIs, storage schemas and agent contracts may change. Take that as the upgrade contract: nightly desktop builds, moving schemas, and no documented migration path for stored data between them.
The licence situation needs care. The README badge reads Apache-2.0, while the repository metadata reports the licence as NOASSERTION, meaning GitHub could not identify a recognised licence from the LICENSE file. Those two signals disagree, and the README does not explain why. If you plan to redistribute the desktop app or embed the gateway, read LICENSE and the package manifests yourself rather than trusting the badge. This is not legal advice, and the discrepancy is exactly the kind of thing to resolve before a release, not after.
On upgrade cost, the workspace layout gives you one lever: the gateway keeps its state under NXCORE_GATEWAY_DATA_DIR, which defaults to .data. Backing that directory up before pulling a new nightly is the concrete step the configuration supports. The README does not document a rollback procedure for schema changes, so the backup is the substitute.
Editorial conclusion
Adopt EverRoom if you keep project context in scattered files, repos and meeting notes and you want that material assembled into a bounded room an agent can read, with provenance you can inspect. Do not adopt it if you need Windows or Linux as a first-class target, enterprise administration, or a frozen storage schema, because the README states that APIs, storage schemas and agent contracts may change while the first complete local workflow is being finished. Before committing, verify three things yourself: that pnpm dev starts the desktop against the bundled gateway, that the Evidence and Knowledge Rooms features listed as available today behave as documented on your own files, and that the licence terms in LICENSE match how you intend to distribute anything built on top of it, since the repository metadata reports the licence as NOASSERTION even though the README badge says Apache-2.0.
Frequently asked questions
What are the benefits of using EverRoom?
The README frames the benefit as keeping information, memory and action connected: sources are preserved with identity and version history, routing decides what becomes a wiki page, entity candidate or memory document, and an Agent receives only the Room-scoped tools and documents needed for the current request. The stated goal is a bounded context window instead of a global prompt dump, with generated summaries traceable back to their sources.
Does EverRoom run on Windows or Linux?
The README states that macOS is the current development target, and the root package.json provides package:mac and package:win scripts. The README does not present Windows or Linux as equally exercised targets, so treat non-macOS support as unproven.
Which port does the EverRoom gateway use?
The .env.example file sets NXCORE_GATEWAY_HOST to 127.0.0.1 and NXCORE_GATEWAY_PORT to 3210, with NXCORE_GATEWAY_DATA_DIR defaulting to .data. The gateway is described in the README as a Fastify 5 service supervised by Electron.
Does EverRoom need model credentials to start?
The README says some features require optional local services or model credentials, but that the desktop can still start with the isolated development runtime. The .env.example file sets NXCORE_AGENT_RUNTIME to fake by default and notes that pi should be used after configuring the AI values.
What licence is EverRoom released under?
The README badge shows Apache-2.0, while the repository metadata reports the licence as NOASSERTION, so the two disagree. The README does not explain the discrepancy, and the LICENSE file is the document to read.
Community notes