Skip to main content
A TOML configuration file enables more complex Graph Node configurations than those exposed through CLI options. The configuration file location is specified with the --config command line flag.
When using a configuration file, you cannot use the --postgres-url, --postgres-secondary-hosts, and --postgres-host-weights CLI options.

Configuration Structure

The TOML configuration file consists of four main sections:

[chains]

Sets endpoints to blockchain clients

[store]

Describes available databases and shards

[ingestor]

Sets the node responsible for block ingestion

[deployment]

Describes how to place newly deployed subgraphs
Many configuration sections support environment variable expansion, especially Postgres connection strings. The official graph-node Docker image includes envsubst for complex use cases.

Basic Configuration

The simplest configuration is equivalent to using the --postgres-url command line option:

Store Configuration

The [store] section defines database connections and sharding setup. At minimum, you must configure a primary shard.

Single Database Setup

Connection String Format

The connection string must be a valid libpq connection string. Environment variables embedded in the string are expanded before passing to Postgres.

Connection Pool Size

Each shard must specify how many database connections each graph-node instance maintains in its connection pool.
Set a single value for all nodes:
Use different pool sizes for different node types based on node_id patterns:
Rules are checked in order, and the first matching rule is used. If no rule matches, configuration loading fails.
Always run graphman config pools $all_nodes after changing pool configuration to verify the expected connection counts. Replace $all_nodes with a space-separated list of all node names using this configuration.

Chain Configuration

The [chains] section controls blockchain provider connections and metadata storage.

Chain Structure

Configure a chain named mainnet in the [chains.mainnet] section:

Chain Parameters

  • shard: Database shard where chain data is stored
  • protocol: Protocol type (ethereum, near, cosmos, arweave, starknet). Default: ethereum
  • polling_interval: Block ingestor polling interval in milliseconds. Default: 500
  • amp: Network name used by AMP for this chain. Defaults to chain name. Set when AMP uses different naming (e.g., amp = "ethereum-mainnet" for chain named mainnet)
  • provider: List of providers for this chain

Provider Configuration

Each provider has:
  • label: Provider name appearing in logs
  • details: Provider connection details

Provider Details

  • type: web3 (default), firehose, or web3call
  • transport: rpc (default), ws, or ipc
  • url: Provider endpoint URL
  • features: Array of supported features:
    • traces: Supports debug_traceBlockByNumber for call tracing
    • archive: Archive node with full historical state
    • no_eip1898: Doesn’t support EIP-1898 (block parameter by hash/number object)
    • no_eip2718: Doesn’t return type field in receipts (pre-EIP-2718 chains)
    • compression/<method>: Supports compression (gzip, brotli, or deflate)
    • For Firehose: compression and filters
  • headers: HTTP headers for every request. Default: none
  • limit: Maximum subgraphs using this provider. Default: unlimited
  • token: Bearer token for Firehose providers
  • key: API key for Firehose providers

Provider Limits (Experimental)

This feature is experimental and may be removed in future releases.
Limit the number of subgraphs per provider using node name patterns:
Nodes named some_node_.* use mainnet-1 for at most 10 subgraphs, then fall back to mainnet-0. Nodes named other_node_.* never use mainnet-1.
At least one provider should be unlimited. If a node’s name doesn’t match any rule, that provider is disabled for that node.

Deployment Configuration

The [deployment] section controls where new subgraph deployments are placed, determining both the storage shard and indexing node.

Deployment Rules

Rules are evaluated in order. The first matching rule determines placement.

Rule Matching

The match element can contain:
  • name: Regular expression matched against subgraph name
  • network: String or list of strings compared to deployment’s network
The last rule must not have a match statement to ensure all deployments have a valid placement.

Rule Actions

  • shard: Storage shard name (default: primary)
  • shards: List of shards (system chooses the one with fewest active deployments)
  • indexers: List of indexing nodes (deployment spreads evenly across listed nodes)
Indexer names must match the --node-id values used when starting index nodes.

Query Nodes

Configure nodes as query-only (no indexing) by adding to [general]:
Nodes with --node-id matching the regex will:
  • Only respond to queries
  • Not connect to configured blockchain providers
  • Not perform any indexing

Configuration Validation

Validate configuration file syntax and consistency:
This checks for:
  • Syntax errors
  • Internal inconsistencies
  • Undeclared shards referenced in deployment rules
  • Invalid configuration combinations

Simulating Deployment Placement

Test where a subgraph would be deployed without making changes:
Output shows:
  • Database shard for subgraph data
  • List of potential indexing nodes
  • Selection logic (node with fewest current subgraphs)

Complete Example