Object-storage native graph database with branching and typed ontology.
_{Unified retrieval engine (vector/BM25/graph) · Git-style workflows · Open data format (Lance)}

Quickstart  ·  Docs  ·  Cookbooks  ·  CLI  ·  llms.txt

---

Omnigraph is engineered for the new workload introduced by long-horizon agents: multiple agents sharing a typed world model to continuously retrieve and store context and coordinate work. Agents and UIs can become thin stateless consumers of durable state.

Omnigraph Cloud is Omnigraph as a service: managed storage, servers, releases, backups, compaction and scaling, with access by token through the same CLI, SDKs and MCP server. Private preview; join the waitlist.

Capabilities

Capability	What it gives you
Typed ontology	Agents share one enforceable model of the domain. .pg schemas declare node and edge types, keys and constraints, and the engine enforces them on every write.
Multimodal retrieval	Agents assemble high-precision context in one query: graph traversal + vector ANN + full-text + Reciprocal Rank Fusion in one runtime, with filtering.
Branching	Agents propose reviewable changes instead of writing to main: a branch per agent or task, three-way merge, time travel across the whole graph.
Declared as code	A cluster.yaml declares graphs, schemas, stored queries, embedding providers and policies. cluster plan previews, cluster apply converges, Terraform-style.
Security as code	Cedar policy enforced server-side on every mutation, per graph or server-wide; bearer auth, server-resolved actors, audit tracking.
Object-storage native, open format	Store graphs on local disk or S3-compatible storage: RustFS / MinIO, AWS S3 / R2 / GCS, or Azure preview. Graph data uses open, versioned Lance, including Blob values.

What you can build

Use case	What it's for
Company brain	Org knowledge unified into one graph every agent can query
Agentic memory	Durable, versioned memory: a branch per agent or per task, merged on review
Context graph	Decision traces and codified tribal knowledge for retrieval
Dev graph	Issues & dependency model that coding agents read and write
R&D / ML data layer	Experiments and trials written into branches, versioned for training & eval

Install

curl -fsSL https://raw.githubusercontent.com/ModernRelay/omnigraph/main/scripts/install.sh | bash

This installs omnigraph (CLI) and omnigraph-server into ~/.local/bin from published release binaries. Or with Homebrew:

brew tap ModernRelay/tap
brew install ModernRelay/tap/omnigraph

Set it up with an AI agent

Omnigraph is built to be run by coding agents. Two ways in:

Teach your agent the playbook. The omnigraph binary carries the omnigraph agent skill written for it: the operational playbook covering cluster mode, the two config surfaces, schema evolution, query linting, data writes, branches, Cedar policy, and the common gotchas. Export it where your agent loads skills, so the skill always matches the installed CLI:

omnigraph skill export ~/.claude/skills/omnigraph --force

With an older CLI that has no skill command, or none installed, npx skills add ModernRelay/omnigraph@omnigraph installs the copy on the default branch instead.

Or have an agent set it up from scratch. Paste this into Claude Code, Codex, or any agent that can read a URL and run a shell command:

Help me set up Omnigraph

1. Read the docs at https://github.com/ModernRelay/omnigraph, starting with
   docs/user/clusters/index.md, then docs/user/deployment.md.
2. Skim the starter graphs and seed data in the cookbooks:
   https://github.com/ModernRelay/omnigraph-cookbooks
3. Ask me what I want to build (company brain, agent memory, dev graph,
   research / R&D layer, …). Then stand up a cluster for it, load a little
   data, and run a query so I can see it working.

For ready-to-run graphs with real seed data (company brain, VC operating system, pharma & industry intel), ModernRelay/omnigraph-cookbooks is the fastest way to see Omnigraph shaped to a real domain.

Deploy

A cluster declares graphs, schemas, stored queries, and policies in a configuration bundle. cluster plan previews changes and cluster apply submits them to the selected destination. The cluster-only HTTP server exposes graphs at /graphs/{id}/… and activates applied changes without a restart.

Keep desired configuration separate from its destination:

company-brain/
├── cluster.yaml
├── people.pg          # schema for the "knowledge" graph
├── queries/           # stored queries: the .gq files ARE the declaration
│   └── people.gq
├── cluster.policy.yaml # deployment permissions
└── graph.policy.yaml   # graph permissions

# cluster.yaml
version: 1
metadata:
  name: company-brain
graphs:
  knowledge:
    schema: people.pg
    queries: queries/                          # every `query <name>` in queries/*.gq registers
policies:
  cluster-access:
    file: cluster.policy.yaml
    applies_to: [cluster]
  graph-access:
    file: graph.policy.yaml
    applies_to: [knowledge]

For first boot, follow the cluster guide, including writer ownership transfer and authentication. The deployment guide covers containers and object stores; Azure writers require its admission wrapper.

The applied cluster policy must grant the authenticated operator config_manage. Schema changes also require read and schema_apply on the affected graphs. With those grants and a server target named production, deploy local edits:

omnigraph cluster validate --config ./company-brain
omnigraph cluster plan --target production --config ./company-brain
omnigraph cluster apply --target production --config ./company-brain

--config names the source bundle; --target names the destination. Omitting storage from the bundle uses the selected destination's root. If present, storage must match that root; it never selects or redirects the target. Apply prints a deployment ID. If delivery is interrupted, inspect that ID before submitting again; see deployment recovery.

Query and mutate

Define a server target with default_graph and set defaults.target once in ~/.omnigraph/config.yaml (configuration), and the everyday commands stay short. Stored queries and mutations run by name:

omnigraph query  search_docs --params '{"q":"AI safety"}'
omnigraph mutate add_person  --params '{"name":"Mina"}'

# Branch, review, merge across the whole graph; agents write in isolation
omnigraph branch create --from main agent/ingest-42
omnigraph branch merge  agent/ingest-42 --into main

An alias is shorter still: bind a target, graph, and stored query to one name, then omnigraph alias triage runs it. Data commands use --target NAME for a configured server or managed resource, plus --graph ID when needed. Use --target ./graph.omni for a standalone local graph. Control-plane login and organization operations use --profile; see operator configuration.

Security & governance

• Engine-wide enforcement: every write path goes through the same Cedar gate, so the HTTP server, the CLI, and the embedded SDK obey identical rules.
• Declared in the cluster: a policy bundle is bound to graphs (or the whole server) via policies: → applies_to.
• Scoped: rules apply per graph, per branch, or server-wide.
• Static server credentials: static bearer tokens are hashed at startup and compared in constant time.
• Forge-proof identity: the actor is resolved server-side from the token; clients can't set it.

See the policy guide.

Clients & SDKs

Client	Use it for	Where
TypeScript SDK	typed access from Node / TS	@modernrelay/omnigraph · source
Built-in MCP	connect an agent to the server's /mcp, directly or through omnigraph mcp --target NAME	MCP guide
HTTP / OpenAPI	use the wire contract from any language	HTTP guide · OpenAPI

Match the client's HTTP contract to the server's. The 0.14 server requires contract 0.14; see client availability before selecting an npm package.

Docs

• 0.14 highlights and upgrade actions · User guide
• Cluster guide · Deployment guide · CLI reference
• Schema · Queries · Search · Policy

Build and test

cargo build --workspace --locked
cargo test --workspace --exclude omnigraph-gqt --exclude omnigraph-gqt-served --exclude omnigraph-dst --locked \
  --features omnigraph-engine/failpoints,omnigraph-cluster/failpoints

Notes:

• Rust stable toolchain, edition 2024
• The GQT corpus (cargo test -p omnigraph-gqt) and the DST suite (cargo test from crates/omnigraph-dst, which supplies its process environment) run separately; a plain cargo test --workspace starts the DST binaries without that environment and they refuse. Commands and CI gates: docs/dev/testing.md
• Full CI and some local test flows require protobuf-compiler
• S3 integration tests expect an S3-compatible endpoint such as RustFS

Contributing

Please open an issue before sending large code changes — a maintainer triages it, and the accepted label is the green light for a PR (see GOVERNANCE.md). Concrete problem statements are the fastest way to collaborate on the roadmap.

Community

Join the Omnigraph Slack community to ask questions, share feedback, and follow development.