Zep stopped actively maintaining Zep Community Edition in April 2025, redirecting its open-source effort to Graphiti, the graph engine underneath it, and steering self-hosters toward Zep Cloud instead. If you built on the self-hosted Community Edition, the repository still exists, but nothing new is landing in it, and that is worth treating as a real decision point rather than something to quietly ignore.
What actually happened, and when
In its own announcement, Zep described the difficulty of maintaining two different products at once, a fully open-source, community-supported edition and a feature-rich commercial multi-tenant service, and said design choices in one kept limiting the other. The resolution was to stop investing in Zep Community Edition specifically and put open-source effort behind Graphiti instead, the temporal knowledge graph engine that powered it. The Community Edition code moved into a legacy/ folder in the repository: still there under Apache 2.0, but no longer receiving updates or active support.
That leaves two real options if you want to keep running something yourself rather than moving to Zep Cloud: run Graphiti directly, which means provisioning and operating your own Neo4j, FalkorDB or Kuzu instance and building the session and retrieval layer above it, or move to a different self-hosted memory system entirely.
Is zep community edition still available at all?
Technically yes, the code is public. Practically, you are on your own for fixes, security patches and anything the ecosystem around it moves past. Treating "the repo still exists" as equivalent to "this is supported" is the mistake worth avoiding here.
What genuinely does not port across
Be honest about this before you migrate anything, because overpromising here just moves the disappointment later. Graphiti and Zep Community Edition represent memory as a temporal knowledge graph: entities, relationships, and how a fact changes or gets superseded across specific points in time. That is a specific, fairly sophisticated way of modelling memory, and a different system, one built around condensed summaries and lexical retrieval rather than graph traversal, is not going to reproduce that internal structure. It can reproduce the underlying facts. It will represent the relationships between them differently.
| What you are moving | Ports cleanly | Needs rethinking |
|---|---|---|
| The underlying facts and content | Yes, as source records to be re-condensed | N/A |
| Citations back to where a fact came from | Yes, as a reference field on the resulting record | N/A |
| Temporal graph reasoning (how a fact changed over time) | No | Represented differently, or not represented at all, depending on the target system |
| Session and user management | Depends on the target system's own model | Usually needs remapping rather than a direct import |
Table 1: what actually survives a migration off a temporal knowledge graph, and what has to be rebuilt or accepted as gone.
"The Zep team decided to stop maintaining and releasing Zep Community Edition... while the existing repository will remain open under the Apache 2.0 license, they will no longer provide updates or active support."
Summarising Zep's own announcement of its open-source strategy change, April 2025
What each remaining option actually requires
Before picking a direction, it is worth pricing out what each remaining path actually needs, because "self-hosted" and "managed" mean different levels of commitment depending which one you pick.
Running Graphiti yourself means provisioning Neo4j 5.26 or newer, FalkorDB 1.1.2 or newer, or an Amazon Neptune cluster, none of which is a small addition to a stack that previously just ran Zep's own container. It also needs Python 3.10 or newer and its own LLM key for inference and embedding, OpenAI by default, though Anthropic, Gemini, Groq and OpenAI-compatible endpoints are all supported. That is a real, separate operational commitment on top of whatever else you run, not a drop-in replacement for the Community Edition container you are used to.
Zep Cloud, the managed path Zep itself now points self-hosters toward, starts at $125 a month on its Flex plan, or $104 a month billed annually, for 50,000 credits a month with auto-topup and a 600 requests-per-minute ceiling. That removes the operational question entirely, at the cost of moving from self-hosted to managed, which for a lot of the teams who chose Community Edition in the first place was the point they were trying to avoid.
The actual migration steps
The mechanical part of this is more ordinary than it sounds, at least for the content itself, because a self-hosted memory layer built around reading from an existing system of record does not need a bespoke import API. It needs your exported data to look like any other source it already knows how to read.
- Export what you have. Pull the underlying facts and their source references out of your existing Zep or Graphiti instance, in whatever form is easiest for you to query, typically a flat table of records.
- Land it in a Postgres table you control, shaped with the columns a source connector expects: a reference id, a title, the content itself, and a link back to the original if you have one. A Postgres-backed source preset reads exactly this shape.
- Connect that table as a source. No custom integration code required if the columns match; this is precisely what the read-only SQL connector is for.
- Trigger a sync. The connector reads each record and condenses it, the same as it would for any other system of record, producing a memory object with its own citation and its own freshness contract rather than a raw copy of the row.
- Verify with a real query before you decommission the old system. Ask the kind of question you actually asked Zep, and confirm the answer, the citation and the freshness label all look right.
Do I need to migrate everything at once?
No, and doing it incrementally is usually the safer path. Point a source at a subset of your exported data first, verify retrieval quality and citations against real questions your team actually asks, and only then migrate the rest. Running the two systems in parallel for a short window costs little and catches a shape mismatch before it affects everyone.
What to check before you commit to any replacement
- Does your actual usage depend on temporal graph reasoning specifically, or on retrieving and citing a fact, which is a narrower requirement most teams genuinely have?
- Does the replacement track freshness per record, or does content go stale silently once it is imported?
- Does the replacement check who is allowed to see a given record before returning it, or does everyone with access to the system see everything?
- Is self-hosting actually still self-hosting, with no phone-home and no feature gating, or is it a trial period for a hosted product?
If a condensed, permission-aware memory store answers your actual usage pattern, rather than the graph-reasoning capability you may never have used directly, self-hosting walks through running one against your own Postgres, the docs cover the source connector shape referenced above in full, and our llm memory database comparison sets this approach against the wider field rather than against Zep specifically.