We are excited to release the new Apibara Operator for Kubernetes! This release make it even easier to run Apibara indexers on demand on your self-hosted infrastructure.

A Kubernetes operator is a service you deploy on your cluster to manage Custom Resources (CR), usually defined by a Custom Resource Definition (CRD). This service listen for changes to CR and reconciles the cluster's state with the target state defined by the developer. The operator takes care of the low-level operational details such as scheduling a Pod to run the indexer or restarting the container if it exits because of a transient error.

In practice, here's how to use the Apibara Operator in your cluster.

Start by generating the Apibara CRDs with apibara-operator generate-crd | kubectl apply -f. This will install a new Indexer CRD.

Next you need to run the operator in your cluster. The operator is stateless so you can run it as a deployment. In the future, we will provide an Helm Chart to install the operator in one command.

Now you can run an indexer by pointing to the source code (either clone a GitHub repo or from a mounted volume) and configuring the indexer with environment variables.

apiVersion: apibara.com/v1alpha2
kind: Indexer
metadata:
  namespace: default
  name: console
spec:
  source:
    gitHub:
      repo: dna
      owner: apibara
      branch: main
      subpath: examples/console
  sink:
    custom:
      image: quay.io/apibara/sink-console:latest
      script: starknet_to_console.js
  env:
    - name: AUTH_TOKEN
      valueFrom:
        secretKeyRef:
          name: apibara-api-key
          key: production

Notice: for a real-world production deployment, you should persist the indexer state to an ETCD cluster.

The operator is a step forward in simplifying running Apibara indexers. Next week we will release the new "Runner" API abstraction to provide one API to run Apibara indexers independently of the target platform (for example, locally, Kubernetes, or AWS).

This week we added a new quota service to DNA. This service is used to globally limit how much data a specific client is allowed to use.

The quota service is a simple gRPC service with two methods:

• check: check if the client can stream data. This method is called once before the client starts streaming data.
• updateAndCheck: this method is periodically called by the DNA service while the client is streaming. It's used to update the amount of data consumed by the user and to, at the same time, check if the client can keep streaming data.

The DNA service extracts the team and clients ids from the request metadata (gRPC headers), this gives teams a high degree of control over their quota logic.