Context Source Graph
Millisecond code search and reading at pinned Git revisions — for people, scripts and AI agents.
Live demo · Documentation · Reference docs · Contributing · 简体中文
Context Source Graph is a self-hosted code search service built on Go, Git and Zoekt. It keeps a trigram index of each repository, resolves every request to an exact commit, and exposes the same operations through a web UI, an HTTP API, an MCP server and a CLI.
It is built for the workload AI coding agents generate: many small, precise search → read round trips against code the agent does not have checked out.
Why
- Milliseconds, not seconds. Indexed search typically completes in under 5 ms on the server. Deployed in the same region as its callers, a full request — network included — stays well under 100 ms, which is faster than running
grep or rg over a local checkout.
- Reproducible answers. Branches and tags resolve to a commit before anything is read, so a search result, the file it points to and a later diff all refer to the same snapshot.
- One contract, four surfaces. Browser, HTTP, MCP and CLI share the same operations:
repositories, availability, resolve, search, read, list, diff and prepare. MCP adds read_many for several reads in one call. See interfaces.
- Agent-ready. A stateless Streamable HTTP MCP endpoint works with any MCP client; anonymous access is read-only and limited to public repositories.
- Snapshot retention. Shallow branch-head synchronization, on-demand pinned SHAs and per-repository storage budgets; see snapshot configuration.
- Small footprint. One process manages Git mirrors, the Zoekt child process and background indexing. SQLite by default; PostgreSQL and MongoDB are supported.
- Extensible reads. Repositories can ship Wasm plugins (
<name>.sourcegraph.wasm) that change how read and read_many present files. See repository plugins.
Performance
Measured against the public demo (context4ai/context, 2,359 indexed files) and a local checkout of the same commit:
| Query | Context Source Graph (server) | rg (local) | git grep (local) | grep -r (local) |
|---|
| Literal, 13 matching files | 0.7–0.9 ms | 61 ms | — | — |
| Literal, ~100+ matching files | 3.6–5.2 ms | 61 ms | 39 ms | 3.6 s |
| Regex, no matches | 0.4 ms | 62 ms | — | — |
Server time is Zoekt's reported search duration. Local tools ran on an Apple M4 Pro with a warm page cache; grep -r excluded node_modules, .git and dist. The service returns a bounded first page of results, so very broad queries do not grow without limit. Add the network round trip between caller and server — a few milliseconds within one region — to get end-to-end latency.
The index does the work that grep and rg repeat on every call, so the gap widens as repositories grow. Local tools also require a checkout of every repository at the right revision; the service does not.
Try it
Open the live demo — it indexes context4ai/context and context4ai/sourcegraph and allows anonymous reading.
Connect an MCP client that supports Streamable HTTP:
{
"mcpServers": {
"sourcegraph": { "url": "https://context4ai.org/sourcegraph/mcp" }
}
}
Or call the HTTP API directly:
curl -s -X POST 'https://context4ai.org/sourcegraph/api/search?repo=context4ai/context' \
-H 'content-type: application/json' \
-d '{"Pattern":"TODO","FixedStrings":true}'
The site's Connect page always shows current HTTP and client examples. See interfaces for MCP, HTTP and CLI details.
Run your own
docker build -t context-sourcegraph .
docker volume create sourcegraph-data
docker run --rm -p 8080:8080 -v sourcegraph-data:/data \
-e SOURCEGRAPH_ORIGIN=http://localhost:8080 \
-e SOURCEGRAPH_SEED_DEMO=true \
context-sourcegraph
Open http://localhost:8080/sourcegraph/. Public GitHub repositories need no token; a custom Git host can be added in system settings or a startup file (code sources). Without OAuth credentials the site is an anonymous, read-only instance; add Google or GitHub OAuth to enable administration — the first verified user becomes the administrator (authentication).
All environment variables are listed in DEVELOPMENT.md.
Deployment
Each instance owns its Git mirrors and Zoekt indexes on local disk. Search speed comes from that locality, so plan capacity around disk, not CPU.
Recommended at scale: sharded instances with repository-sticky routing. Run several instances that share one PostgreSQL or MongoDB database, each serving a disjoint set of repositories from its own data volume. Configure the access layer to route every request by its repository key (owner/repository) to the owning instance — for example with consistent hashing or an explicit repository → instance table. Every repository then has one warm index, capacity grows by adding instances, and losing one instance affects only its shard. See deployment for the required settings.
Simple: one instance with a large disk. For a single team or a moderate number of repositories, one instance on a large, fast persistent volume is the easiest option. Size the volume for bare Git repositories plus indexes, and keep headroom above SOURCEGRAPH_MIN_FREE_BYTES.
Either way, place instances in the same region as the agents and services that call them — that is what keeps end-to-end latency below 100 ms.
[!IMPORTANT]
Do not run multiple replicas over the same repositories or the same data directory. Index ownership is per process; scale by sharding repositories, not by cloning instances.
Fly.io configuration, databases, backups and recovery are covered in deployment.
Documentation
The Source Graph documentation on the Context site covers the concepts and day-to-day use:
The reference documents in this repository describe the current implementation:
License
MIT. Context Source Graph uses Zoekt (Apache-2.0) and other open-source components; see NOTICE. The project name does not imply affiliation with the Sourcegraph platform.
Ecosystem and contributing
Source Graph is part of Context for AI. Context reads code evidence through it remotely (Evidence for Context), and Portal serves it at /sourcegraph/.
Read CONTRIBUTING.md before opening a pull request. Ask questions in GitHub Discussions (see SUPPORT.md) and report vulnerabilities through SECURITY.md. Participation is governed by the Code of Conduct.
