Self-hosted MCP memory server
One self-hosted memory server for every MCP agent.
Give Claude Code, Codex, Kiro, OpenCode, and other MCP clients one durable place for memory, session state, skills, corpus, coordination, and evidence. Your agents keep their own interfaces. The knowledge stays with you.
- Official MCP Registry
- Loopback by default
- One person or a team
MCP · identity · routing
Your self-hosted Keepone durable operating context
- memory + corpus
- session state
- skills + coordination
- replay + outcomes
The direct answer
Firekeep is a shared MCP memory server you operate.
Install the Client Kit on each machine and connect its local stdio gateway to the same self-hosted Keep. Every client configured through a shipped adapter or the generic local-stdio path can call the same memory, session, skill, corpus, coordination, and evidence tools. Lifecycle automation varies by the hooks each client actually exposes.
Firekeep is published in the Official MCP Registry
as io.github.kapella-hub/firekeep, using the firekeep-client
package and local stdio transport.
Install · one bootstrap command
Start a new Keep or join one already running.
The installer asks for the agent identity attached to its work and where the Firekeep server lives. It then configures Claude Code, Codex, Kiro, and OpenCode together, plus Claude Desktop when the app is present.
- Name the agent.Choose the identity recorded with memories, sessions, and replay events.
- Choose the server.Provision this machine, redeem a single-use join code, enter an existing address, or finish later.
- Render the clients.The shipped adapters are configured together; a generic MCP snippet is available separately.
- Verify the path.Restart open agents, then run
firekeep doctorto check the complete connection.
Follow the complete installation walkthrough for enrollment, server-only setup, source installation, checksums, and troubleshooting.
Architecture · local doorway, self-hosted core
Your agents connect locally. Your Keep runs where you choose.
Firekeep presents one stdio MCP server to the agent on each machine. That gateway attaches identity, combines the shipped tool surfaces, and routes requests to services in the Keep you operate. The server, datastores, embeddings, and default inference run on your infrastructure.
Your existing agents
Claude Code, Codex, Kiro, OpenCode, Claude Desktop, or another client that speaks MCP.
Local stdio MCP
One Client Kit handles identity, routing, adapters, local dexes, and instructions on connect.
Your self-hosted server
Cortex, Bridge, Relay, and Sentinel connect memory, sessions, coordination, and replay.
A stock server binds to 127.0.0.1 and requires authentication on protected
routes. A join code can enroll another machine through the private route you control;
widening network exposure remains an explicit operator decision.
Read the full architecture guide.
What the shared Keep carries
More than persistent memory.
The useful part of a solved problem includes the fact, the state around it, the procedure that worked, and the evidence that lets the next agent trust it.
Keep what the work learned.
Durable reference, procedural, episodic, and transient memories stay connected to project, identity, provenance, and confidence.
Return to where work stands.
Goals, plans, decisions, progress, and file notes survive context compression, machine changes, and cross-agent handoffs.
Reuse how a problem was solved.
Agents can capture verified procedures as skills; document-derived drafts can enter a human review queue before publication.
Bring selected documents into recall.
Ingest internal material into the shared corpus or use Docdex to index chosen local folders with member-private visibility by default.
Give shared work clear ownership.
Tasks, messages, presence, handoffs, and renewable leases help cooperating agents avoid duplicate or overlapping work.
Inspect what passed through Firekeep.
Structured replay, declared outcomes, feedback, and evaluation receipts make Firekeep-mediated work traceable.
Client coverage · tools versus hooks
One MCP tool surface. Automation that matches the client.
Direct calls to the Keep work through every shipped adapter and the generic MCP path. Automatic briefings, capture, and edit mediation are separate: they depend on lifecycle events the client makes available.
| Client | Connection and tools | Current lifecycle boundary |
|---|---|---|
| Claude Code | Managed MCP, Firekeep instructions, and the full direct-call tool surface. | Richest supported hook coverage; its pre-edit hook can hard-block a denied edit, write, or shell action. |
| Kiro CLI | Named agent with managed MCP, steering, and the full direct-call tool surface. | Lifecycle hooks are available; on validated Kiro CLI 2.12.1, pre-edit is advisory and there is no true session-end or pre-compaction event. |
| OpenCode | Native adapter, local plugin, and the full direct-call tool surface. | Supported edits can be blocked, but briefing and inbox output appear in the console rather than model context; no pre-compaction event. |
| Codex | Managed MCP, repository guidance, and the full direct-call tool surface. | No Firekeep hooks. Recall, session updates, inbox polling, and policy calls are explicit MCP actions. |
| Claude Desktop | Auto-detected when installed; its adapter mounts the full MCP tool surface. | No hooks. It receives instructions on connect; lifecycle calls and Docdex sync are explicit. |
| Other MCP clients | firekeep install --runtime generic prints a paste-in local stdio configuration with the same tools and connect instructions. | No hook lifecycle is implied. Presence and heartbeat require the optional sidecar. |
The boundary is simple: MCP provides the shared capabilities; hooks provide convenience and enforcement where the client supports them. See the day-to-day runtime table for the complete current behavior.
Actual requirements
Size the server; connect from the machines where you work.
Client Kit
Runs on Linux, Windows, and macOS. The bootstrap includes its own pinned Python toolchain, so system Python and Node are not prerequisites.
Self-hosted server
- Docker and Docker Compose v2 with
linux/amd64support - 2 x86-64 CPU cores minimum and Git
- 16 GB RAM recommended for the default stack
- x86-64 Linux, or Docker Desktop with amd64 support on Windows or Mac
- No open ports required; the default bind is
127.0.0.1
Review the current requirements and sizing notes before choosing a host.
Cross-runtime handoff
A solution can outlive the agent that found it.
Suppose Claude Code diagnoses a difficult deployment failure. The next Codex or Kiro session needs more than the final file—it needs the cause, the failed approach, the verified recovery, and the current state of the work.
Recall before acting.
The first agent checks the Keep for related decisions, procedures, and work already in flight.
Capture the experience.
It records the goal, decisions, progress, verified fix, and why the earlier attempt failed.
Start another runtime.
A later agent opens a session against the same workspace and recalls the relevant history.
Close the loop.
It reports whether the knowledge held and leaves updated state for the person or agent who follows.
ctx_start_sessionmemory_recallctx_updatememory_learnmemory_feedback
See a complete prompt-level example in the Claude Code to Codex handoff guide.
Personal continuity · organizational knowledge
Start with yourself. Grow into a shared memory for the group.
Carry less context in your head.
Use one Keep across your own projects, agents, sessions, and machines. Decisions, active goals, chosen documents, and hard-won fixes remain available when you switch tools.
Earn context once and carry it forward.
Contributors add memories, reusable procedures, and selected corpus material to the same organizational knowledge layer. Proven experience can reach another role or runtime without a separate handover document.
The Keep improves through use without hiding uncertainty. Recorded session outcomes and explicit feedback can influence which memories surface; unconfirmed conflicts remain contested for human review. On a shared Keep, Docdex folders are member-private by default within the workspace access model.
Published evidence
Measure recall. Show the limits. Use the system daily.
97.7% Evidence Recall@10
For 459 of 470 scored questions, Firekeep returned at least one labeled evidence session in the first ten results.
Read the benchmark and methodologyTracked sessions in the latest month
The dated case-study snapshot also records 45 active operational skills and 12 ingested documents across daily engineering and operations work.
Read the daily-use case study- Retrieval onlyIt measures whether labeled evidence reached the first ten results, not generated-answer accuracy.
- One corrected runThe accepted result is one deterministic run, not a multi-run confidence interval.
- Synthetic historiesLongMemEval-S differs from Firekeep's normal distilled production memories with provenance.
Self-hosting and license
Run the complete Keep on infrastructure you control.
Firekeep is source-available under BUSL-1.1, not open source today. Self-hosted internal production use is free for individuals and teams during early access, with no Firekeep account or license key required. Production use outside that grant requires a commercial license. Each release converts to Apache-2.0 four years after publication.
Frequently asked questions
Self-hosted MCP memory, without the guesswork.
Is Firekeep an MCP memory server?
Yes. Each connected agent talks to a local Firekeep stdio gateway through MCP. That gateway exposes memory, session, skill, corpus, coordination, and evidence tools backed by the self-hosted Keep you operate.
Does every MCP client receive the same automation?
No. Clients configured through a shipped adapter or the generic local-stdio path can use the full shared direct-call tool surface. Automatic briefings, lifecycle capture, and edit mediation depend on the hooks the client exposes. Claude Code has the richest integration; Codex, Claude Desktop, and generic clients use explicit MCP calls.
Does Firekeep replace an agent's native memory?
No. Keep using runtime-native instructions, continuation, and provider context. Firekeep carries the selected knowledge and working state that should survive across agents, sessions, people, and machines.
Can one person use a shared MCP memory server?
Yes. One person can use Firekeep across projects, runtimes, sessions, and machines. Add teammates later when the same context should travel across people.
Where does the document corpus live?
Shared corpus content is stored in the self-hosted Keep. Docdex indexes only folders a member chooses and makes them member-private by default. That is application-level privacy from other members, not encryption from the server operator.
Is Firekeep open source?
Firekeep is source-available under BUSL-1.1. Self-hosted internal use is free for individuals and teams during early access, and each release converts to Apache-2.0 four years after publication.
Go deeper