Four jobs share one memory API
Supermemory combines 4 related jobs: ingesting documents, extracting memories, maintaining user profiles, and searching both facts and source material. An application assigns content to a container tag, then asks for a profile or query result later. The README says the engine handles changing facts, contradictions, and expiration. That is more useful than a plain vector search when an assistant needs to remember that a user's current employer or location replaced an older value.
The project reaches users through several surfaces. TypeScript and Python clients call the hosted or local API. A managed MCP endpoint supplies memory, recall, and context tools, while separate plugins cover Claude Code, OpenCode, OpenClaw, and Hermes. The hosted side can sync Gmail, Google Drive, Notion, OneDrive, and GitHub. This breadth is attractive, but it makes the boundary between open local code and platform service worth reading carefully.
What happened when we ran it
Our sandbox installed the bun workspace in 75 seconds, adding 3,015 packages and consuming 3,212 MB on disk. The build ran for 98 seconds and exited with code 1. Turbo's summary said all 8 tasks had succeeded. Immediately afterward, postbuild invoked sentry-cli to create a release and upload source maps, then stopped with the plain error that an auth token was required.
There was no test script or target, so our harness skipped tests. The commit 4d8a4eb checkout contained 1,192 files, about 140,914 source lines, and 119.1 MB before the 3,212 MB install. Our scan found 12 CI workflow files, no Dockerfile, no tests directory, and monorepo workspaces. The measurement setup was an unprivileged Debian container with 3 CPUs, 8 GB of RAM, and no secrets.
All 8 build tasks pass before the release hook fails
The failed command is a packaging decision rather than a compiler error in the log we received. The root build runs Turbo, and the automatic postbuild runs sentry:sourcemaps. Open issue 1444 identifies the same coupling and asks that release upload become an explicit deployment step. We cannot call the repository build successful because the command returned exit 1, even though the build-task summary itself reported 8 successful tasks.
That distinction matters to contributors and downstream packagers. A normal checkout should not need a production monitoring credential merely to prove it builds. Workarounds may exist, but the supplied log does not document one, so we will not prescribe an unverified flag. The 75-second install also produced a very large development tree. Anyone changing this monorepo should budget for 3,015 packages and create a separate validation path that never publishes a Sentry release.
The 3,212 MB workspace differs from the local binary
The README's one-binary self-hosting path is a released server, while our lab exercised the repository's bun monorepo. Running npx supermemory local or the install script downloads that server. First boot creates an embedded graph store, prepares the default local embedding model, generates an API bearer token, and listens on port 6767. No external database is required for this local edition.
Memory extraction still needs a language model. Operators can provide OpenAI, Anthropic, Gemini, Groq, Vertex AI, Workers AI, or an OpenAI-compatible endpoint such as Ollama. The default embedding model is Xenova/bge-base-en-v1.5 with 768 dimensions and no API key. The configuration guide says image, video, and higher-fidelity PDF understanding require Gemini or Vertex. Fully offline use therefore needs local model capacity as well as the downloaded server.
Local v0.0.8 has one process and one generated key
The local edition is designed for one organization on one machine. It provides server logs, one generated API key, environment-variable configuration, and disk storage under ./.supermemory by default. The hosted platform adds member roles, scoped keys, a dashboard, managed scaling, connectors, and its managed MCP service. A team evaluating self-hosting should use the local feature table, rather than assuming every README feature runs in the binary.
Set SUPERMEMORY_DATA_DIR to an absolute, persistent location before putting v0.0.8 under a process manager. Open issue 1420 reports that the default relative path follows the current working directory, so a different launch directory can create a fresh empty store and API key. The quickstart also warns operators to back up the data directory before a rollback because older servers may not understand newer schema changes.
Server v0.0.8 repairs a vector-loss upgrade
The latest server release, published August 17, 2026, is an emergency patch. Its notes say stores moved from a 0.0.7 release candidate to 0.0.7 could retain document records while silently losing search vectors. Version 0.0.8 detects affected rows at boot and re-embeds them in the background. The release also adds migration fixtures with real vectors so future upgrade tests can check preservation.
That repair is a good response to a serious failure, and it is evidence that the local server still needs cautious operations. Back up before every version change, record the server version with the data, and verify that old documents remain searchable after restart. The repository had 39 open issues and 73 open pull requests when fetched, so GitHub's combined count of 112 is not a bug count.
September activity supports a trial, with recovery tests attached
GitHub recorded the last push on September 2, 2026, and 29,233 stars. Issue activity continued into September, while the latest server tag remained v0.0.8 from August 17. Those signals describe an active project, though the version number and emergency migration fix argue against hands-off operation. The absence of a root test target in our run leaves another gap between active development and repeatable outside verification.
For a hosted product, Supermemory can remove the work of building connectors, profile extraction, and a cross-client MCP service. For local use, it gives an unusually direct API over one machine, but the operator owns model behavior, storage durability, backups, and upgrade checks. Start with disposable data, replay a fixed set of contradictory and expiring memories, restart the server, then confirm that search and profiles still return the expected history.