Omnigraph Atlas Omnigraph's documentation, bound to its Rust workspace
79 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 Mode in Containers (AWS, Railway)

A cluster-booted deployment has two shapes since the storage: root:

  • Bucket, no volume (preferred for cloud) — the cluster's ledger, catalog, and graph data live under an object-storage root (storage: s3://bucket/prefix in cluster.yaml). The server boots config-free from the bare URI; the container needs no volume at all:

    docker run -d \
      -e OMNIGRAPH_CLUSTER=s3://my-bucket/clusters/company-brain \
      -e AWS_ACCESS_KEY_ID=... -e AWS_SECRET_ACCESS_KEY=... \
      -e OMNIGRAPH_SERVER_BEARER_TOKEN=... \
      -p 8080:8080 <image>
    

    Day-2 runs from any operator checkout of the config repo: omnigraph cluster apply --config ./company-brain (the storage: key routes every stored byte to the bucket), then restart the service. The state lock is genuinely cross-machine on object storage, so CI and operator shells contend safely.

  • Volume (file-rooted) — the original shape: the whole cluster directory on a mounted volume. Still fully supported; the container contract:

docker run -d \
  -v /srv/company-brain:/var/lib/omnigraph/cluster \
  -e OMNIGRAPH_CLUSTER=/var/lib/omnigraph/cluster \
  -e OMNIGRAPH_SERVER_BEARER_TOKEN=... \
  -p 8080:8080 <image>

OMNIGRAPH_CLUSTER is the server's only boot source. The image also ships the omnigraph CLI, so the day-2 loop runs in-container:

docker exec -it <container> sh -c \
  'omnigraph cluster apply --as <you> --config /var/lib/omnigraph/cluster'
# then restart the container to pick up the applied state