Omnigraph Atlas Omnigraph's documentation, bound to its Rust workspace
85 documents

Deploy a cluster as code

How a deployment goes from a folder of declarations to N graphs served behind policy — the Terraform-style declare → plan → apply → serve loop.

Cluster boot (the only boot)

omnigraph-server --cluster <dir | s3://…> --bind 0.0.0.0:8080

omnigraph-server --cluster <dir-or-uri> boots from the cluster catalog's applied revision. The server resolves that revision into per-graph startup configs (id, URI, optional per-graph policy, stored-query registry) plus an optional server-level policy, then opens every configured graph in parallel at startup (bounded concurrency = 4, quarantining graph-specific open failures). Routing is always multi-graph — requests to bare flat protected paths (/read, /snapshot, …) return 404; the served surface is /graphs/{graph_id}/.... See cluster-config.md for what is read and the readiness rules.

Readiness is fail-fast for cluster-global problems: missing or unreadable state, invalid/unattributable recovery sidecars, unreadable shared catalog payloads, cluster policy errors, or zero healthy graphs. Graph-attributed pending recovery sidecars and graph-specific startup failures quarantine that graph instead; the server logs startup diagnostics and serves the remaining healthy graphs. GET /graphs enumerates ready/served graphs only, so quarantined graphs are absent and their routes return 404.

Operators who want the original all-or-nothing boot contract can pass --require-all-graphs or set OMNIGRAPH_REQUIRE_ALL_GRAPHS=1. In that mode, any graph quarantine, graph-open failure, stored-query startup failure, or embedding-provider resolution failure aborts startup.

A scheme-qualified argument (s3://…) reads the ledger straight from the storage root, with no local config directory. --bind, --unauthenticated, and the bearer-token env vars all apply.