How Multi-Project Configuration Works in Code-Graph-RAG to Share a Single Graph

Code-Graph-RAG uses a single Memgraph instance for multiple projects by prefixing all node IDs and edge labels with a project name, creating isolated sub-graphs without database duplication.

The vitali87/code-graph-rag repository implements multi-tenancy through lightweight namespace isolation rather than separate database instances. This design lets teams index dozens of repositories into one shared knowledge graph while maintaining strict logical separation between projects.

The Project Name as Namespace Prefix

Every indexed repository receives a project name that acts as a root namespace. The system derives this automatically from the folder name, or you can override it with --project-name.

In realtime_updater.py, the project name becomes the foundation of all graph operations:

# realtime_updater.py lines 258-265

self.updater.project_name          # stores the active project name

f"{self.updater.project_name}."    # prefix for all node/edge identifiers

This prefixing happens transparently. When you index Python files from my-service, the resulting Cypher queries generate nodes like my-service.ClassName rather than bare identifiers. The same Memgraph instance can safely hold api-gateway.ClassName and billing-service.ClassName without collision.

Adding Projects to the Shared Graph

The CLI command cgr start handles incremental ingestion. Each invocation with --update-graph adds another project slice without disturbing existing data.

# First project: defaults to folder name "legacy-monolith"

cgr start --repo-path ./legacy-monolith --update-graph

# Second project: explicit name for clarity

cgr start --repo-path ./new-api --project-name public-api --update-graph

# Third project: microservice with inferred name "notification-worker"

cgr start --repo-path ./workers/notifications --update-graph

All three projects coexist in Memgraph. Queries can target specific projects or span the entire graph.

Configuration Through AppConfig

No per-project configuration files exist. The codebase_rag/config.py module defines AppConfig, which holds global connection parameters:

# codebase_rag/config.py

MEMGRAPH_HOST = "localhost"
MEMGRAPH_PORT = 7687

# ... other shared settings

Every project connects to the same Memgraph host and port. Isolation happens at the data layer through prefixed identifiers, not at the connection layer through separate databases.

Querying Projects: Scoped and Cross-Project Access

The Python SDK exposes project-scoped loading through GraphLoader:

from codebase_rag.graph_loader import GraphLoader

# Load only the notification-worker sub-graph

loader = GraphLoader(project="notification-worker")
graph = loader.load()

# Load another project for comparison

legacy = GraphLoader(project="legacy-monolith").load()

For ad-hoc exploration, the CLI accepts raw Cypher:

# List all indexed projects

cgr query "MATCH (p:Project) RETURN p.name"

# Find similar classes across projects

cgr query "MATCH (c:Class) WHERE c.name CONTAINS 'Handler' RETURN c.project, c.name"

The --clean Flag: Global Reset Behavior

The --clean flag requires caution. According to the source in README.md (lines 136-141), this operation deletes all projects in the shared graph—not merely the current one.

# WARNING: removes every indexed project

cgr start --clean

# Safer: re-index a single project (overwrites only its namespace)

cgr start --repo-path ./updated-api --project-name public-api --update-graph

The CLI emits a warning before executing --clean because the operation truncates the entire Memgraph database.

Implementation Architecture

Component	Responsibility	Key Source Location
realtime_updater.py	Project-scoped key generation	Lines 258-265
README.md	User-facing multi-project documentation	Lines 136-141
codebase_rag/config.py	Global Memgraph connection settings	AppConfig class
codebase_rag/graph_loader.py	Project-filtered graph loading	GraphLoader(project=...)

Summary

• Single Memgraph instance hosts multiple projects through identifier prefixing.
• Project name (--project-name or folder-derived) isolates all nodes and edges.
• realtime_updater.py implements the prefix injection in generated Cypher.
• GraphLoader enables single-project views for SDK consumers.
• --clean resets everything—use it sparingly across multi-project deployments.

Frequently Asked Questions

What happens if two projects have the same folder name?

Code-Graph-RAG uses the folder name as the default project identifier. If you index /home/user/api and /opt/api separately, both default to api, causing collision. Always use --project-name to disambiguate: --project-name user-api versus --project-name opt-api.

Can I query relationships across projects in Cypher?

Yes. The project prefix lives inside node IDs and labels, but Cypher MATCH clauses can traverse any edge. To restrict scope, filter by the project property: WHERE node.id STARTS WITH "project-name." or use GraphLoader for automatic filtering.

Does each project need its own running Memgraph process?

No. One Memgraph process serves all projects. Connection parameters in codebase_rag/config.py apply globally. The multi-tenancy is logical, not operational—reducing infrastructure overhead.

How do I migrate a project to a fresh Memgraph instance?

Export the project-specific nodes and edges using cgr query with project filters, then import into the new instance. There is no built-in export --project command; use Cypher MATCH ... WHERE ... predicates to extract subsets.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}