does Pants' REAPI/Remote-Caching implementation have any support for HTTP mode instead of GRPC? For reasons beyond my comprehension or control, we can't use HTTP2 at my organisation. Which puts a spanner in the works on the whole GRPC thing. But

bazel-remote

does expose a HTTP1.1 API

The short answer is no, see https://github.com/pantsbuild/pants/issues/11149 The slightly longer answer if you trace the opendal related bits of code you will see experimental support for cacheing via github actions and file://. I don't think these have successfully been used at scale but you could possible glue something together. If you are looking for reapi specifically in a CI context you can run bazel-remote as a sidecar or additional local daemon. So the grpc is all local host and bazel-remote talks to S3 or whatnot the regular blob storage way. My impression is that this is a common pattern.

+1 for running bazel-remote as a sidecar. My current setup has all my hosted CI runners sharing a volume, so I configured bazel-remote to use the local filesystem on that shared volume.

In the end, we deployed bazel-remote to a k8s cluster, and then wrote a proxy that translates the Grpc calls to https calls that we run as a sidecar on the client side