AI coding assistants are great at writing code and surprisingly bad at knowing where things are. Ask "what breaks if I change this function?" on a large repository and the assistant starts opening files one by one, burning tokens and context, and often still misses a caller three modules away.
Graphify fixes that by turning a codebase into a knowledge graph: functions, classes, modules and the edges between them, parsed locally with tree-sitter. Your assistant queries the graph through MCP instead of re-reading the code. With over 130k GitHub stars, it clearly hit a nerve.
This post shows how to run Graphify as one shared MCP server that every assistant on your team can use, kept up to date automatically. Everything here is open source.
Local graph vs. shared server
The default Graphify workflow is local: you run it in your repo, it writes graphify-out/graph.json, and your assistant reads it. If you work alone on one machine, that's perfect. Committing graphify-out/ and installing Graphify's git hook even keeps several of your own machines in sync.
It gets clumsier when:
- several people (or several agents) need the same graph,
- you don't want everyone to install and run Graphify locally,
- you want the graph to follow
mainwithout anyone thinking about it.
Graphify already ships an HTTP transport for its MCP server, so the missing piece is just the plumbing: clone, build, serve, refresh, secure. That's what graphify-railway does.
How it works
your Git repo ──clone/pull──▶ graphify extract --code-only ──▶ graph.json (volume)
│ reloaded on change
Claude Code / Cursor ──HTTPS + API key──▶ /mcp ◀── graphify.serve --transport http
-
Clone. On start, the service clones
REPO_URL. Private repos work with a read-only token. -
Build. It runs
graphify extract --code-only: pure local AST parsing, no LLM API key. On a small repo (about 100 nodes) it takes under a second. -
Serve. It starts
graphify.serveover MCP Streamable HTTP on/mcp. Every request must carry the API key. -
Refresh. Every hour (configurable), it pulls the repo. If the commit changed, it rebuilds and swaps
graph.jsonatomically. Graphify's server checks the file on each request and reloads it, so connected clients keep their session: no restart, no downtime.
A few details I cared about:
-
The git token never touches the disk. It's passed to each git command as an HTTP header, not written to
.git/config, and it's redacted from logs. -
The API key isn't on the command line. It goes through the environment, so it doesn't show up in
ps. - The last good graph survives. It lives on a persistent volume: if the repo is briefly unreachable at startup, the previous graph is served; if a refresh fails, the old graph stays online.
- Graphify is pinned to a tested release in the Dockerfile. Graphify ships very often, and you don't want a surprise upgrade on a team server.
The whole wrapper is one Python file and a Dockerfile.
Deploy it
One click on Railway
Deploy on Railway. You get the service and a volume. Fill in one variable, REPO_URL (for example https://github.com/your-org/your-repo); the API key is generated for you. For a private repo, also set GIT_TOKEN. On GitHub, use a fine-grained token limited to that repository with Contents: Read-only.
Anywhere you can run a container
docker build -t graphify-server https://github.com/jean82290/graphify-railway.git
docker run -d -p 8080:8080 \
-v graphify-data:/data \
-e REPO_URL=https://github.com/your-org/your-repo \
-e GRAPHIFY_API_KEY="$(openssl rand -hex 24)" \
graphify-server
Put it behind HTTPS before sharing it with anyone.
| Variable | Required | Default | What it does |
|---|---|---|---|
REPO_URL |
yes | HTTPS URL of the repository to map | |
GRAPHIFY_API_KEY |
yes | Key every MCP client must send | |
GIT_TOKEN |
private repos | Read-only access token | |
REPO_BRANCH |
no | default branch | Branch to map |
REFRESH_MINUTES |
no | 60 |
How often to pull and rebuild (0 disables) |
Connect your assistant
Claude Code:
claude mcp add --transport http graphify https://YOUR-SERVICE.up.railway.app/mcp \
--header "Authorization: Bearer YOUR_GRAPHIFY_API_KEY"
Cursor (.cursor/mcp.json):
{
"mcpServers": {
"graphify": {
"url": "https://YOUR-SERVICE.up.railway.app/mcp",
"headers": { "Authorization": "Bearer YOUR_GRAPHIFY_API_KEY" }
}
}
}
Any MCP client that supports Streamable HTTP with custom headers works the same way.
What your assistant can do with it
Graphify exposes tools such as query_graph, get_node, get_neighbors, get_community, god_nodes, graph_stats and shortest_path, plus PR-oriented tools (list_prs, get_pr_impact, triage_prs).
In practice, this means questions like these get answered from the graph instead of a file-by-file crawl:
- "What calls
buildEvent, directly or indirectly?" - "What's the shortest path between the HTTP handler and the database layer?"
- "Which parts of the code are the most connected, and therefore the riskiest to change?"
When I tested it on a small Node.js project, a query_graph call starting from one function returned its 80 related nodes and 152 edges in a single response. That's the context an assistant would otherwise have to rebuild by opening a dozen files.
Security notes
- The server is reachable on the internet, and the API key is what keeps your code map private. Rotate it by changing
GRAPHIFY_API_KEYand redeploying. - The graph contains names and relationships from your code, not the full source, but treat it as confidential if your code is.
- Use a token with read access to a single repository.
Limitations
- Code only, for now. Graphify can also extract docs, PDFs and images, but that pass needs an LLM backend and an API key. The wrapper sticks to the free, offline AST mode.
- One repository per instance. If you need several, run several instances (or tell me you'd like multi-repo support).
-
Hourly refresh by default. Lower
REFRESH_MINUTESif you need fresher graphs.
Links
- Source (MIT): github.com/jean82290/graphify-railway
- One-click deploy: Railway template
- Graphify itself (Apache-2.0): github.com/Graphify-Labs/graphify
Disclosure: this is an unofficial wrapper, not affiliated with Graphify Labs. If you deploy through the Railway template, I receive a share of Railway's hosting fees. The Docker route above costs me nothing and works just as well.
Questions, ideas or bugs: open an issue on GitHub or leave a comment below. I'm especially curious whether multi-repo support would be useful to you.
Top comments (0)