Managed Subgraphs

Keep your Subgraph indexed without running the indexing infrastructure yourself. With Managed Subgraphs, you can monitor progress, prepare a new version while the current one serves queries, and choose manual releases or follow versions published on The Graph Network.

Pair a Managed Subgraph with an Endpoint Alias to keep the same application URL across upgrades. If you only need to query an existing deployment, start with Query your first Subgraph. To decide whether you need managed indexing, see Choose your Subgraph setup.

Start indexingCopy Anchor Link

Before you start, check that you have:

• An Owner or Developer role in the organization.
• A monthly plan for the organization. A plan that is set to cancel counts until it ends. See Managed Subgraphs need a monthly plan.
• A positive available credit balance. Support can arrange a credit exception when appropriate.
• Room under your organization's Managed Subgraph limit.
• A deployment with a valid manifest and query schema that uses one supported network across all data sources and templates.

To have the platform recommend a setup and create the Endpoint Alias with it, choose Set up a Subgraph instead; see Choose your Subgraph setup. Otherwise, add the Managed Subgraph directly:

1. Add a Managed Subgraph:

   Create Managed Subgraph(opens in a new tab)

   While you explore a Subgraph, you can instead choose Create Managed Subgraph to start with its identifier.

2. On Target, choose what it follows: Deployment CID for a pinned version that you upgrade manually, or Graph Network Subgraph ID to follow future published versions automatically. A Graph Network Subgraph ID resolves its latest published deployment before indexing begins.

3. Enter the identifier. A Deployment CID starts with Qm and has 46 characters; a Graph Network Subgraph ID has 43 or 44 characters. The wizard reports an incomplete or malformed identifier before checking anything, then checks the manifest and shows the deployment's network and start block. Fix any reported problem, or retry a check that could not complete from the button beside the field.

4. Upgrades states how the target type moves to new versions. Then give the Managed Subgraph a name your team will recognize, review what will be created, and create it.

5. Optionally add an Endpoint Alias that follows this Managed Subgraph, so your application keeps one query URL across upgrades. Name it, then choose which version it serves: Current version, selected for you, moves when you promote a version and suits production; Next version serves each version you prepare while it indexes, so you can test it before you promote it. See Choose a target behavior. Then get its query endpoint. You can skip this step and add an Endpoint Alias later. If the Endpoint Alias can't be created, for example because the name is taken, your Managed Subgraph is still created: retry with another name or skip.

Know when your data is readyCopy Anchor Link

Check indexing progress and health before relying on new data. A Managed Subgraph's Overview leads with its status and one sentence on what serves your queries now and what an upgrade in progress is doing. Below it, the Current and Next versions each show their status, indexing progress, sync lag and Deployment CID, followed by the network, last hour's indexing cost and Target type. Versions shows each version's indexing progress, and Endpoint Aliases lists the Endpoint Aliases linked to it.

• Available means the current version is healthy and serving queries close to the network head. A small lag can remain, and the page always shows how many blocks it is behind. Check that lag when your application needs the most recent block.
• Hover over, select, or tap a status label to read its explanation and open its section in Statuses. A Subgraph error can include the affected block and a source location to help you correct the deployment. Each version has its own status: an upgrade failure does not change the status of a healthy serving version.
• Indexing unavailable means indexing has stopped. Read the status explanation for the cause and the suggested next action.
• Status updated tells you when the status was received, not which block has been indexed. Status delayed means GraphOps hasn't received a new status for several minutes; the page keeps showing the last one. Check again before making a release decision. Promotion waits until a current status arrives.
• Get query endpoint, in the Actions menu, connects through the Managed Subgraph's earliest created linked Endpoint Alias, which follows promotions. Without a linked Endpoint Alias, it connects to the current Deployment CID, which doesn't follow upgrades.

Once you can query the deployment, include _meta to check the block and deployment serving your response. Monitor sync health shows how to detect lag and indexing errors from your application.

StatusesCopy Anchor Link

Each status label links here from its explanation. The Managed Subgraph and its Current version share one status; a Next version has its own while it is prepared for promotion.

Setting upCopy Anchor Link

GraphOps is preparing the deployment for managed indexing, is waiting for indexing capacity, or hasn't received its first indexing status yet. Indexing starts without any action from you.

SyncingCopy Anchor Link

The deployment is catching up to the network head. Queries succeed but can return older data, so check the sync lag before relying on recent blocks.

AvailableCopy Anchor Link

The deployment is healthy and serving queries close to the network head. A small lag can remain; the page shows how many blocks it is behind. Routine maintenance, such as moving the deployment to different storage, keeps this status while the deployment keeps serving. If indexing reports errors that don't stop it, the status explanation lists them; some data can be incomplete.

Indexing unavailableCopy Anchor Link

Indexing has stopped, usually because of a Subgraph error. The explanation names the cause, the affected block when known, and the suggested next action. See Managed indexing has stopped.

PausedCopy Anchor Link

Managed indexing is paused or being paused. A paused deployment doesn't index new blocks.

Removing and RemovedCopy Anchor Link

The deployment is being removed, or has been removed, for example after a Next version was cancelled or the Managed Subgraph was archived.

Ready to promoteCopy Anchor Link

The Next version is healthy and ready to become the Current version. Promote it, or let automatic promotion move it when its Target type follows The Graph Network.

CancellingCopy Anchor Link

Preparation of the Next version is being cancelled. The Current version keeps serving queries.

Upgrade without changing your application URLCopy Anchor Link

Your Current version continues serving queries while you prepare a Next version. Your Endpoint Alias moves only when you promote:

1. Choose Start upgrade from the page's actions and enter the next Deployment CID. GraphOps checks it as you enter it, and Continue becomes available once the check passes. It must use the same network; see Deploy your own Subgraph to get one.
2. Review the upgrade before you start it: the next version's details, what each linked Endpoint Alias does with it (Current version aliases move to it when you promote it; Next version aliases serve it while it indexes), and the schema comparison. Without a Next version alias, the review offers to create one. If the comparison reports breaking changes, update and test affected clients before proceeding. You can deliberately continue with a breaking change. If GraphOps can't start the upgrade with that version, the review sends you back to enter another; if the start fails for any other reason, start it again from the review.
3. Let the next version index, then test its query results. A compatible schema does not guarantee unchanged data or mapping behavior.
4. In Versions, choose Promote version when the next version is healthy and meets the service's indexing readiness checks. Review its indexing progress against the network head before promoting.

An Endpoint Alias with a Managed Subgraph target and the Current version target behavior follows the version you promote, so your clients keep the same URL. To test the next version through a stable URL before promoting it, create a second Endpoint Alias with the Next version target behavior. It serves the Next version while it's being indexed and falls back to Current when you cancel the upgrade or Next can't serve. An Endpoint Alias with a Deployment CID target stays on that CID. Existing Endpoint Aliases only follow these upgrades after you explicitly target the Managed Subgraph. See Manage Endpoint Aliases.

You can cancel an upgrade before promotion. After promotion, returning to a previous deployment requires another upgrade; it is not an instant rollback. Keep the previous CID and test your recovery plan before a production release. Develop and release a Subgraph uses these upgrades as a release workflow for your own Subgraph.

Follow published upgrades automaticallyCopy Anchor Link

Choose a Graph Network Subgraph ID at creation, or change the target type of an existing Managed Subgraph. Following authorizes indexing and promotion of future published versions, including breaking schema changes. Review the displayed schema comparison and prepare clients for changes published by the Subgraph owner.

You don't stage these upgrades in GraphOps:

• When the owner publishes a new version on The Graph Network, the latest version becomes Next while Current continues serving.
• Next promotes when it is healthy, attached, and ready to serve queries.
• If another release arrives first, the latest valid release replaces Next. Serving Current can therefore be older than the previous published network version.
• Missing or deprecated IDs, lookup failures, invalid releases, and network changes hold the existing versions and Endpoint Alias mappings. Check the last resolution and tracking error in the Managed Subgraph's Versions.

A paused Managed Subgraph that follows a Graph Network Subgraph ID keeps following it and resumes with the latest version.

An Endpoint Alias with a Graph Network Subgraph ID target follows the same publications through indexers on The Graph Network, independently of this Managed Subgraph's indexing. Use a Managed Subgraph target when the Endpoint Alias should follow this Managed Subgraph's serving Current version. Manage Endpoint Aliases shows when each target moves.

Change the target typeCopy Anchor Link

A Managed Subgraph's Target type decides how it moves to new versions. A Deployment CID target stays on the currently indexing deployment until you upgrade it. A Graph Network Subgraph ID target follows published upgrades. The name, version history, and linked Endpoint Aliases stay with the Managed Subgraph either way.

1. Choose Change target type from the Managed Subgraph's actions.
2. Choose what it should follow. For a Graph Network Subgraph ID, enter the ID and wait for it to resolve.
3. Review the target type, Current CID, and Next CID now and after saving, and what each linked Endpoint Alias serves.
4. Select Save target type. The change takes effect immediately, and the currently indexing deployment stays the Current version.

To follow a Graph Network Subgraph ID, the Managed Subgraph must be active with no staged manual upgrade, and the ID must use the same blockchain network. The currently indexing deployment must also be one of the versions published to that ID; if it isn't, publish it first. Promote or cancel a staged upgrade before you change the target type. To follow a different Subgraph ID, change the target type to a Deployment CID first.

Changing to a Deployment CID stops following and retires a staged Next version: its indexing stops, and Next version Endpoint Aliases serve the Current version. Current version Endpoint Aliases are unchanged. Start upgrade becomes available again, so you stage each new version yourself.

Plan indexing costsCopy Anchor Link

Managed indexing charges depend on how long each version receives indexing service, its entity count, and its stored data. Charges can accrue during setup and syncing, not only when you send queries. Each Managed Subgraph shows an estimate of its managed indexing credits per month: the credits charged for its last full hour of indexing, multiplied by 730 hours in an average month. The info icon beside the estimate shows the calculation. The estimate appears after the first full hour has been charged and changes as entity count and stored data change. If two of your Managed Subgraphs use the same Deployment CID, each shows that CID's total.

The managed query rate applies when your organization's request resolves to its managed deployment, whether you use a Deployment CID, Endpoint Alias, or Graph Network Subgraph ID.

During upgrades, both Current and Next can accrue indexing charges. The previous version can continue accruing charges until its indexing service is removed. Your organization limit counts the Managed Subgraph once, even while two versions are active. Separate Managed Subgraphs sharing a CID each count toward the limit, and their attached registrations are charged separately.

If credits run out while your organization has a monthly plan, existing indexing can continue accruing charges until the grace period ends and disconnection is confirmed. Without a monthly plan, or while a plan payment needs attention, there is no grace period and indexing stops as soon as the balance reaches zero. Automatic top-ups add credits before that happens. See Managed Subgraphs during a pause for stopping and recovery after adding credits.

Check your organization's limitCopy Anchor Link

Each organization can have up to 10 Managed Subgraphs by default, whatever its plan size. Contact GraphOps support to raise the limit for your organization.

If you add a Managed Subgraph without a monthly plan, the platform asks an owner or billing admin to choose one. If your organization has reached its limit, the platform points you to support.

Paused Subgraphs and those being removed still count toward the limit. Room becomes available after removal finishes.

Stop indexing a SubgraphCopy Anchor Link

Removal is irreversible and stops managed indexing. Check that your applications no longer depend on that service before proceeding.

1. If it follows a Graph Network Subgraph ID and has a Next version, use Change target type to change it to a Deployment CID, which retires the Next version. Otherwise, cancel a staged manual upgrade.
2. Delete the Endpoint Aliases that target this Managed Subgraph, or change them to Deployment CID targets. The delete dialog lists each one that still follows it, with links to change its target or delete it, and stays disabled until none remain.
3. Select Delete and confirm deletion of the Managed Subgraph.
4. Check that removal finishes before its place in your limit or its name becomes available again.

The record remains under Archived, with its version history. Once removal finishes, you can reuse the name for a new Managed Subgraph; the archived record remains available. You can create another resource with the same CID while a peer is still active.

Next stepsCopy Anchor Link