Build your Subgraph with the standard Graph CLI, deploy it to get a Deployment CID, and publish it on The Graph Network if you want a Graph Network Subgraph ID. Either identifier is what you give GraphOps when you choose Set up a Subgraph and My own Subgraph.
Prerequisites
- A Subgraph project with
subgraph.yaml, for example one created withgraph init. - The standard Graph CLI installed for your project.
- A Subgraph in Subgraph Studio, and its deploy key, to deploy to.
- A GraphOps organization with Subgraphs access and an API key that includes Subgraphs.
Deploy
Generate types
CLI · Graph CLI
graph codegen
Build the Subgraph
CLI · Graph CLI
graph build
Deploy a version
Authenticate once with graph auth and your deploy key, then deploy with the Subgraph's slug.
To deploy to another Graph Node instead, add its --node and --ipfs URLs.
Prerequisites
Replace
<SUBGRAPH_SLUG>with your Subgraph's name.
CLI · Graph CLI
graph deploy <SUBGRAPH_SLUG> --version-label v1.0.0
Copy the Deployment CID from the command output and record it with the release. A Deployment CID identifies this exact version. It is all a Managed Subgraph needs: GraphOps can index it whether or not you publish it.
Publish on The Graph Network (optional)
Publish when you want indexers on The Graph Network to serve your Subgraph, or want each version you publish to reach your application automatically:
CLI · Graph CLI
graph publish
Publishing gives the Subgraph a Graph Network Subgraph ID. Every later version you publish belongs to the same ID, so an ID follows your releases while a Deployment CID stays on one version.
Use the identifier in GraphOps
Start Set up a Subgraph and answer My own Subgraph. Paste the identifier that matches how you release:
Set up a Subgraph(opens in a new tab)| You paste | You release new versions | See |
|---|---|---|
| Deployment CID | From GraphOps Platform: stage, test and promote each version | Develop and release a Subgraph |
| Graph Network Subgraph ID | By publishing on The Graph Network | Release by publishing |
The setup then asks whether GraphOps should keep it indexed and creates the Managed Subgraph and Endpoint Alias your answers need. Managed Subgraphs need a monthly plan for your organization.
Check the deployment
Prerequisites
Set GRAPHOPS_API_KEY to your GraphOps API key.
Replace
<DEPLOYMENT_CID>with the Deployment CID to query.
CLI · curl
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": 26285621,Rises as the new deployment indexes "hash": "0x40c3154aaa484a99057c58a6c72c27171ed861d260179db387850027655d0881" }, "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 production clients use it. Then release it as the Next version of a Managed Subgraph, so your production Endpoint Alias moves only once it is indexed; Develop and release a Subgraph walks through that workflow.
- Keep the previous Deployment CID as a rollback target.
- Check
_meta.hasIndexingErrorsafter deploying and after each release.
Next steps
Last updated