Subgraphs: Deploy with Graph CLI

Publish a new version of your Subgraph with the standard Graph CLI and query it through GraphOps before your application depends on it. The Deployment CID that Graph CLI prints is the input to every next step: a query endpoint, a Managed Subgraph, or an Endpoint Alias target.

You build and publish with Graph CLI. The Deployment CID it prints is what you query, give to a Managed Subgraph, or set as an Endpoint Alias target.

Prerequisites

A working Subgraph project with subgraph.yaml.
The standard Graph CLI installed for your project.
Access to the Graph Network or publishing destination used by your Subgraph.
A GraphOps organization with Subgraphs access and a Subgraphs API key.

Deploy

Generate types

Graph CLI

graph codegen

Build the Subgraph

Graph CLI

graph build

Publish the Subgraph

Set GRAPH_NODE_URL and IPFS_URL to your publishing target’s Graph Node admin and IPFS API URLs. Use the Subgraph name registered on that target:

Prerequisites

Replace <SUBGRAPH_SLUG> with your Subgraph's name.

Graph CLI

graph deploy <SUBGRAPH_SLUG> \
  --node "$GRAPH_NODE_URL" \
  --ipfs "$IPFS_URL" \
  --version-label v1.0.0

Copy the Deployment CID from the command output and record it with the release.

Choose query access or managed indexing

For a deployment available through The Graph Network, use its CID in the query endpoint:

Reference

https://subgraphs.graphops.xyz/v1/deploymentCID/<DEPLOYMENT_CID>

To have GraphOps run indexing instead, create a Managed Subgraph with the CID and query it through the same endpoint shape once it is indexed.

Check the deployment

Prerequisites

Set GRAPHOPS_API_KEY to your GraphOps API key.
Replace <DEPLOYMENT_CID> with the Deployment CID to query.

curl

Example project

curl --fail-with-body --silent --show-error "https://subgraphs.graphops.xyz/v1/deploymentCID/<DEPLOYMENT_CID>" \
  -H "Authorization: Bearer ${GRAPHOPS_API_KEY}" \
  -H "Content-Type: application/json" \
  --data '{
    "query": "query DeploymentStatus { _meta { deployment block { number hash } hasIndexingErrors } }"
  }'

Output

{  "data": {    "_meta": {      "deployment": "QmTZ8ejXJxRo7vDBS4uwqBeGoxLSWbhaA7oXa1RvxunLy7",Should match the CID from graph deploy      "block": {        "number": 26250897,Rises as the new deployment indexes        "hash": "0x7c2450505fd5a13e82ef63e3177dfb4521f50793653c7c60b85efca1acc25c2f"      },      "hasIndexingErrors": falseMust stay false before you release    }  }}

_meta.block.number rises while the new deployment indexes. Query your application's fields only after it reaches the blocks your application needs.

Release the new version

Test the new deployment through its Deployment CID endpoint before you change a production Endpoint Alias.
Move clients with Manage Endpoint Aliases, or promote it as the Next version of a Managed Subgraph.
Keep the previous Deployment CID as a rollback target.
Check _meta.hasIndexingErrors after publishing and after each Endpoint Alias update.