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.