No, this is separate from the task-execution broker. The rate limiter backend only stores short-lived counters for the limiter itself, not the task queue or other Airflow internals.

It does not handle metrics. It is just shared storage for rate-limit state.

On Valkey vs Redis: Valkey is a Redis fork and is generally used as a Redis-compatible replacement for common use cases. If you already have Redis, that is the safest default. If your setup already uses Valkey, it should usually work too, but I would still test it in your exact deployment.

And yes, having multiple webserver/API processes is normal in production. The important part is that they share the same limiter backend, otherwise each process would track limits independently.

Yes, that matches what I found.

This is not an airflow.cfg setting. RATELIMIT_STORAGE_URI belongs in webserver_config.py, for example:

RATELIMIT_STORAGE_URI = "redis://redis_host:6379/0"

For the Helm chart, the usual hook is to provide a custom webserver_config.py via webserver.webserverConfig / webserver.webserverConfigConfigMapName. For Airflow 3 API server setups, there is also an apiServer.apiServerConfig equivalent.

So the production path is:

1. use Redis or Valkey as shared rate-limit storage
2. set RATELIMIT_STORAGE_URI in webserver_config.py
3. mount that file through the Helm chart values

The docs could definitely make this clearer for Airflow users.