daric93 opened a new issue, #13738: URL: https://github.com/apache/apisix/issues/13738
### Description Hi! I'd like to propose adding official documentation (and CI coverage) for using [Valkey](https://valkey.io/) as the backend for APISIX's redis-backed plugins. **Context** Valkey is a Linux Foundation, BSD-licensed fork of Redis that is protocol (RESP) compatible. Since the plugins that support `policy: redis` / `redis-cluster` (`limit-count`, `limit-req`, `limit-conn`, `ai-rate-limiting`, `ai-cache`, `openid-connect` session storage) speak the Redis protocol, they already work against Valkey unmodified. Users are in fact already running this in production — for example #13584 and #12282 both describe deployments using Valkey / AWS ElastiCache for Valkey with the limit plugins. However, the repository currently has no mention of Valkey in docs, tests, or CI, so users have no official signal that this is a supported and tested combination. **Proposal** 1. **Docs**: add short notes to the relevant plugin docs (or a single shared page) stating Valkey compatibility, with a connection example. This helps users on Valkey-based infrastructure (increasingly common since the Redis license change, e.g. ElastiCache for Valkey) adopt APISIX with confidence. 2. **CI**: since the redis-backed plugins are already tested in CI (the `apisix_redis` service in `ci/pod/docker-compose.common.yml` and tests such as `t/plugin/limit-count-redis*.t`), add a `valkey/valkey` service and run a small set of the existing redis plugin tests against it. This turns "should work because RESP-compatible" into "verified in CI" at low cost. I'm happy to keep this minimal — e.g. a single test file against the Valkey service — if CI time is a concern. **Why it's worth it** - Zero changes to plugin code — this is documentation + test infrastructure only. - Serves existing users who already run this combination but currently have no official guidance. - Other gateways (e.g. Kong) already document and test Valkey as a supported data store, so this keeps APISIX's compatibility story on par. I'm happy to implement both parts and submit the PR(s) myself if the maintainers agree this is useful. Would welcome any guidance on preferred scope (per-plugin doc notes vs. one shared page, and how much CI coverage is appropriate). Thank you! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
