You can self-host memory for AI agents three ways: build it on your own database, run a memory framework on your own servers, or run a vendor's memory server inside your network. supermemory's is supermemory Local, a single binary you install with npx supermemory local (docs). It isn't open source, and for organizations, self-hosted deployments come with the Scale and Enterprise plans (pricing).

Whichever you pick, self-hosting doesn't make a system offline, compliant or cheaper by itself. Compare the same behavior on both sides (what gets saved, how well it's found again, corrections, deletion and recovery), then price the work it takes. Product details below were checked against our docs and changelog on October 16, 2026.

Should you use a managed memory service or self-host?

Use a managed service when it removes operating work you don't want and meets your requirements. Self-host when control is worth more than that work and your team can run the deployment.

Self-host when	Use a managed service when
Data has to stay in your network, or a contract says where it lives	A vendor's agreements and controls meet your requirements
You need to choose the models and embeddings	You'd rather not run upgrades, backups and capacity planning
You're prototyping locally or working offline	You need connectors, team access and scale from the start

What are the ways to self-host agent memory?

Option	What you run	What you still build	Good fit
Build it yourself	A database with vector search, such as Postgres with pgvector	Fact extraction, updates and contradictions, per-user scoping, deletion and evaluation	Small, well-understood memory needs
A memory framework you host	The framework's server or library on your infrastructure. Letta and Hindsight both offer self-hosted setups (AI SDK memory guide), and Mem0 has an open-source version	Whatever the framework leaves out, plus operating it	Teams that want to read and change the code
A vendor's server in your network	supermemory Local, or a dedicated Enterprise deployment	Integration, monitoring and upgrades	The same API in development and production, without building the memory engine

Storing vectors is the easy part. Running a vector database alone leaves the memory policy to you: what to keep, how a new fact replaces an old one, and what a deletion has to reach. Three ways to build LLMs with long-term memory compares the approaches, and should you build your own AI memory system walks through the build-or-buy decision.

How do you self-host supermemory?

Install and start it with one command. It downloads the server the first time, then runs it:

npx supermemory local

If you'd rather install with curl -fsSL https://supermemory.ai/install | bash, start the server afterwards with supermemory-server.

The installer picks the binary for your machine (macOS on Apple Silicon or Intel, Linux on x64 or arm64) and, when run interactively, asks for an LLM key. First boot sets up the embedded graph engine and local embeddings, prints an API key, and serves the API at http://localhost:6767 (quickstart). Point any supermemory SDK at it with the printed key:

import { Supermemory } from "supermemory"

const client = new Supermemory({
  apiKey: "sm_...", // printed on first boot
  baseUrl: "http://localhost:6767",
})

It's the same API as the hosted platform. The v5 SDKs need server v0.0.9 or later, so run supermemory-server upgrade on an older install first. The coding plugins work with it too: the Claude Code, Codex and OpenCode plugins target it when you set SUPERMEMORY_API_URL to http://localhost:6767, and Muse Code takes baseUrl in .muse/supermemory.json (docs). The Claude Code memory guide covers the Claude Code plugin.

With Docker. The prebuilt image is docker.io/supermemory/supermemory. Download the Compose file from the server v0.0.9 release, put your LLM key in a .env file, and run docker compose up -d. The Compose file binds port 6767 to 127.0.0.1 only, and you read the API key from the container instead of the logs. On Windows, the native build stays at 0.0.8, so use Docker with Linux containers (Docker docs).

Models. Memory extraction runs on the model you point it at: OpenAI, Anthropic, Gemini, Groq, or any OpenAI-compatible endpoint, including local ones such as Ollama, LM Studio, vLLM and llama.cpp.

Embeddings. By default the server embeds locally with Xenova/bge-base-en-v1.5 (768 dimensions; see how it compares with other open-source embedding models), so nothing leaves the machine to be embedded. Since July you can choose OpenAI, Gemini or any OpenAI-compatible endpoint instead, at first boot or with the SUPERMEMORY_EMBEDDING_* variables, and the server locks the choice so stored vectors stay consistent (changelog, embeddings docs). The default model is English-only. For other languages, pick a multilingual model such as Xenova/bge-m3 before a large backfill, because switching later means a fresh data directory or re-ingesting everything.

What still leaves your network?

A localhost endpoint is one boundary, not the location of every downstream call. With supermemory Local, check each of these (docs):

The extraction model. A hosted LLM receives the text it processes. A local model keeps it in.
Embeddings. Local by default. A remote provider receives the text it embeds, and the first run downloads the local model.
Webpages. Ingesting a URL sends it to Firecrawl and needs FIRECRAWL_API_KEY. Use local text inputs for offline work.
Files. PDFs need GEMINI_API_KEY, and images use Gemini or Vertex AI.
Telemetry. It's on by default. Set SUPERMEMORY_DISABLE_TELEMETRY=1 to turn it off, and SUPERMEMORY_NO_UPDATE_CHECK=1 if the server mustn't check for releases.

Logs, backups and connector calls are more paths to inspect, whatever you run. Make an inventory of what each component receives, where it runs and who can access it. For an offline requirement, block or watch network egress in a test with synthetic content: configuration names alone aren't evidence that the whole workflow stays local.

Compliance doesn't follow from the hosting label

HHS guidance permits HIPAA-covered use of cloud services when the required business associate agreement and other safeguards are in place. HIPAA isn't a blanket ban on cloud processing or shared infrastructure.

The European Commission's guidance on international transfers describes the mechanisms for moving personal data outside the European Economic Area. GDPR shouldn't be reduced to a rule that all personal data must stay on an EU server.

Evaluate the actual data flows, processing terms, access controls, retention and agreements for the deployment you intend. A "HIPAA certified" or "GDPR certified" label isn't proof that every requirement is met, and self-hosting leaves the same questions for you to answer.

What does self-hosting cost?

For supermemory, Local is free within its lite license limit and is meant for individual developers (Local vs Enterprise). Self-hosted deployments for organizations come with the Scale plan, and Enterprise adds air-gapped deployments (pricing).

For your own comparison, estimate cost from query complexity, record size, concurrency and model usage. User count alone is a weak proxy. An illustrative comparison might use:

Monthly component	Managed option	Self-hosted option
Service or infrastructure	$1,500	$800
Engineering operations	10 hours × $100 = $1,000	30 hours × $100 = $3,000
Total before other differences	$2,500	$3,800

These are made-up planning inputs, not market averages or vendor prices. With them, self-hosting costs $1,300 more a month before setup, migrations, model calls and incidents. With an existing platform team and less extra operations work, the result could reverse. Self-hosted costs aren't flat either: capacity, storage, backups and operations grow with load. The hidden cost of building LLM memory in-house goes further into the engineering time.

Local vs Enterprise: what's the difference?

Both run the same memory engine and speak the same API, so code moves between them by changing the base URL and key. Data doesn't move with it (docs).

	supermemory Local	supermemory Enterprise
Built for	Individual developers, prototypes, privacy-sensitive side projects	Organizations
Models	Bring your own key for any provider, including fully offline	supermemory's own models, tuned for long-horizon memory
Access	One auto-generated API key	Members, roles and scoped API keys
Connectors	None	Google Drive, Notion, Gmail and OneDrive, with background sync
Scale	One machine, one process	Managed infrastructure, or dedicated deployments for compliance
Support	Community, on GitHub	Dedicated support, onboarding and SLAs

The server binary isn't open source. It's built from a separate, non-public codebase, while the SDKs and other components in the public repository are open source.

Who operates what

List upgrades, capacity planning, credential rotation, backup restores, index migrations and retrieval-quality checks, and write down for each one whether the software, a vendor or your team handles it.

Upgrades. Back up the whole data directory before replacing a server version, and don't point an older version at a store a newer one has migrated. The Docker docs walk through the backup.
Embedding changes. A different model or dimension means re-embedding. That doesn't have to mean downtime if you build a parallel store and cut reads over, but test the migration and the rollback with the actual software.
Concurrent writes. Test simultaneous corrections, late events and retries. Last write wins may be right for one field and wrong for another, so write the policy down.

Choose with a recovery-sized pilot

Test saving, retrieval and correction, then restart the service, restore a backup and replay pending work. Check that deleted or revoked material doesn't come back through a stale copy, and measure response time and quality under realistic concurrent load. Then compare the result with a managed setup run against the same data. supermemory's hosted platform and Local take the same calls, which makes that comparison cheap to run (docs).

Common questions

Is supermemory Local open source?

No. The self-hosted server is built from a separate, non-public codebase. The SDKs and other components in the public repository are open source.

Does self-hosting mean data never leaves your infrastructure?

No. Model calls, embedding providers, webpage fetching, telemetry, logs and backups can all send data out. Check every component and its configuration.

Can supermemory run fully offline?

Text memory processing can stay on your machine with a local model and the default local embeddings, after the embedding model's first download. Webpage ingestion needs Firecrawl, so use local text inputs, and turn off telemetry and update checks.

Does HIPAA prohibit cloud memory services?

No. HHS permits cloud use when the required agreements and other HIPAA obligations are met.

Is there a fixed traffic level where self-hosting gets cheaper?

No. Compare service charges, capacity and operating effort for your actual workload. Existing infrastructure and maintenance effort can change which option costs less.

Self-hosted memory for AI agents: options and trade-offs