rindexer indexes EVM chain events from a YAML file

Indexing without writing an indexer

rindexer is an open source, high-speed indexing toolset developed in Rust, designed for compatibility with any EVM chain. The core pitch is in the second sentence of the README: you can index chain events using a simple YAML file, requiring no additional coding, and for more advanced needs it provides foundations and capabilities to build whatever you want.

That is a good framing for a tool that lives between a no-code tool and a framework. The README calls it highly extendable, enabling you to construct indexing pipelines and focus exclusively on the logic.

The out of the box feature that changes how you use it is the GraphQL API. rindexer gives you a GraphQL endpoint to query the data you have indexed, immediately, without writing a separate API service. For a hackathon team or a data team that needs event tables rather than a product, that combination is the reason to use it at all.

The list of use cases the README gives is a fair description of the audience: hackathons where you spin up an indexer for your dApp with an API and no code, data reporting, building advanced indexers, fast prototyping and MVP work, and quick proof of concept projects.

The project is MIT licensed, the homepage is rindexer.xyz, and the releases are frequent, with v0.43.4 tagged on 2026-10-05 after v0.43.3 and v0.43.2 in September.

Three ways to use it, from YAML to full Rust

The examples directory is the clearest statement of the design, and the README groups the examples into three types.

The no-code type is YAML only with no Rust project at all. The examples include rindexer_demo_cli for basic PostgreSQL indexing of RocketPool ETH transfers, nocode_clickhouse for the same thing against ClickHouse, rindexer_demo_custom_indexing for custom indexing patterns, rindexer_native_transfers for indexing native ETH transfers with trace_block, which the README notes requires specific RPC support, and streams_playground for stream integrations covering Kafka, RabbitMQ, Redis and webhooks.

The table type adds data transformations before storage, and the examples directory carries a large set of them named for what they index: tables_erc20_balances, tables_erc721_ownership, tables_erc1155_balances, tables_dex_pool, tables_governance, tables_token_supply, tables_factory_cron, tables_erc20_allowances, tables_view_calls, tables_registry_delete, tables_cron_chainlink_price and tables_cron_historical_sync among them.

The rust type is full Rust projects with custom handlers, with rindexer_rust_playground covering multi-contract, multi-network work, dual storage of PostgreSQL and CSV, event filtering and global contracts, and rindexer_factory_indexing demonstrating the factory pattern.

The progression matters. You can start with a YAML file, move to tables when you need to reshape data on the way in, and drop to Rust when you need custom handlers, without changing the tool.

The CLI is the interface, and the commands are small

The command list is short enough to learn in a minute, which is part of the appeal. The help output reads:

Blazing fast EVM indexing tool built in rust

Usage: rindexer [COMMAND]

Commands:
  new           Creates a new rindexer no-code project or rust project
  start         Start various services like indexers, GraphQL APIs or both together
  add           Add elements such as contracts to the rindexer.yaml file
  codegen       Generates rust code based on rindexer.yaml or graphql queries
  delete        Delete data from the postgres database or csv files
  phantom       Use phantom events to add your own events to contracts
  help          Print this message or the help of the given subcommand(s)

The names tell the story. new scaffolds a project, either no-code or Rust. add edits the rindexer.yaml file, which is the configuration file the whole no-code path depends on. codegen generates Rust code from that YAML or from GraphQL queries, which is the bridge between the two modes. delete removes data from the Postgres database or from CSV files, and phantom lets you add your own events to contracts for testing without a live chain.

The start command is the one you will run most, and it takes a mode: indexers, the GraphQL API, or both together.

The full documentation lives at rindexer.xyz/docs/introduction/installation, and the README says plainly that it goes into more detail on how to use rindexer and all the commands available.

Any EVM chain, and the HyperSync shortcut for backfills

The network support story is the simplest part of the project to believe. rindexer supports any EVM chain out of the box, and for a custom chain you add the chain's RPC URL to the YAML configuration file and define the chain ID, with no code changes required.

That is a real advantage over indexers that hardcode a chain list or need a fork to add a network, and for a chain that launched last week it is the difference between a config change and a build.

The performance angle is HyperSync. For faster historical backfills, a network can fetch event logs from HyperSync by adding hypersync: true to the configuration, and the README is clear that the RPC URL is still used for everything else.

So there are two paths through the same config. Live and recent data comes over the RPC as usual, and the historical sweep can be pointed at a service that returns logs in bulk. The cost of that is one more setting, and a dependency on a service being reachable.

The Rust dependencies explain the rest of the shape of the tool. alloy 2 with the full feature set is the EVM client library, alloy-chains carries the chain definitions, tokio with the full feature set is the runtime, tokio-postgres is the Postgres driver, reqwest with json is the HTTP client, rustls with the ring backend handles TLS, and serde with serde_json and serde_yaml does the serialisation that the YAML config depends on. The csv crate is there for the CSV storage mode.

Container and Kubernetes deployment

The Docker image is published as ghcr.io/joshstevens19/rindexer, and creating a new no-code project in the current directory is one command:

docker run -it -v $PWD:/app/project_path ghcr.io/joshstevens19/rindexer new -p /app/project_path no-code

For an existing project with a running Postgres, the compose path needs two environment variables and a compose file:

export PROJECT_PATH=/path/to/your/project
export DATABASE_URL="postgresql://user:pass@postgres/db"

docker-compose up -d

That starts the local indexing, and if the GraphQL endpoint is enabled it becomes exposed under http://localhost:3001.

The compose file in the repository is minimal and shows the shape: the rindexer service uses the published image on the linux/amd64 platform with the command start -p /app/project_path all, passes PROJECT_PATH and DATABASE_URL through the environment, bind mounts the project directory, publishes port 3001, and restarts always. The port 3001 is the GraphQL endpoint, and the compose network is named explicitly.

For Kubernetes there is a Helm chart, in the helm/rindexer directory of the repository, with its own README explaining the deployment. The README describes the chart as simplifying the deployment and allowing easy customisation of the deployment parameters.

The Dockerfile explains the native binary story. The builder is rust:1.88.0-bookworm with pkg-config, libssl-dev, clang, libclang-dev and nodejs installed, and it builds with the jemalloc and reth features and the target-cpu set to x86-64-v2. The runtime image is debian:bookworm-slim with libssl3, ca-certificates, curl and git, plus Foundry installed, and the entrypoint is the rindexer binary copied out of the builder.

Windows is the rough edge

The install section has a warning that is easy to skim past. The install script is a pipe to bash:

curl -L https://rindexer.xyz/install.sh | bash

and on Windows you need Git BASH or WSL, because rindexer installation does not support Powershell or Cmd.

There is a second and more specific Windows caveat. Native Windows release binaries are built without Reth and ExEx support, and if you need Reth mode you have to use Linux, macOS, Docker or WSL/Linux instead of the native Windows artifact.

That is the kind of limitation that decides a project. A team that develops on Windows with WSL is fine, since the Docker and WSL paths both work. A team that has a Windows native build pipeline for its indexer is not, and needs to build from source with the Reth feature, or move the indexer to a container.

The rest of the platform story is friendlier. The published Docker image is linux/amd64, and the compose file pins that platform explicitly. The Rust project is also on crates.io, though the README says the git repository is strongly recommended instead.

Editorial conclusion

rindexer suits a team that needs a working event indexer for a dApp today and would rather not write Rust to get one, since the YAML path produces a real indexer and a GraphQL API, and the Rust path is there when you outgrow it. It is the wrong tool if you need a chain the YAML configuration cannot express, or if the volume of data exceeds what a single Postgres instance and a polling RPC can handle. Before adopting it, install it, point it at one contract in a test chain, and check the backfill path, since historical indexing through HyperSync versus a plain RPC is where the operational difference shows up.

Frequently asked questions

Official sources

1. joshstevens19/rindexer on GitHub
2. License: MIT
3. Project website
4. README
5. Releases