Depending on your use case, there is a way to proxy gRPC to Cloud Run in a slightly hacky way leveraging the fact that outbound gRPC works.

You can run in GCE a gRPC server that whenever it gets a gRPC request, it temporarily stores the gRPC message and associates it with a session ID. It then sends a HTTP request to Cloud Run with that session ID. Then your Cloud Run instance will take that session ID to make a gRPC connection to your gRPC server in GCE. This GCE instance will then take the session ID, retrieve the gRPC request, and forward it to the Cloud Run instance.

This is admittedly hacky, but depending on your use case, may be good enough.

Streaming HTTP and gRPC support is on our roadmap, but it's still a ways out :(

On the comment about how the control plane APIs support gRPC: the serving infrastructure for the data plane is pretty different from the control plane, so it's unfortunately not a direct map to supporting gRPC on the data plane.

Another possible solution is to run an API gateway that does gRPC to JSON conversion and have that invoke your service.

Unary gRPC calls would cover all of my uses cases that would benefit from this product. Is that any closer on the roadmap?

My understanding is that the major issue we have is with streaming (sticky sessions to backends that are autoscaling is tricky), so I assume that unary would be easier. I admit that I haven't dived too deeply in to this though.

EDIT: looks like we could do unary gRPC if gRPC wasn't only supported on HTTP/2. So the current implementation basically requires we solve sticky sessions/streaming.

No gRPC support means no server-side Firebase integration, right?

We don't support inbound gRPC/streaming, but we do support outbound gRPC/streaming, so things like Firestore (or other streaming gRPC products) will work fine.

Oh, nice. Thanks for the clarification.