gRPC Function Invocation
gRPC invocation executes requests against Cloud Functions functions that expose a gRPC service. gRPC functions use the gRPC proxy instead of the HTTP invocation route.
In self-hosted deployments, the gRPC route is exposed on the Gateway TCP listener. See Gateway Routing for listener and DNS configuration.
Metadata
Set these gRPC metadata values when invoking a function:
The data sent to your gRPC function is defined by the Protobuf messages your function implements. gRPC functions do not have an input request size limit.
gRPC connections stay alive for 30 seconds when idle. Close the gRPC client connection after your client is finished so function workers are not held longer than needed.
Python Example
This example uses a plaintext local or test gateway on port 10081. For a
production TLS endpoint, use grpc.secure_channel("grpc.<domain>:443", grpc.ssl_channel_credentials()).
The official gRPC term for authorization handling is
call credentials. The
example above sets the authorization metadata directly for clarity.
Connection Reuse and Streaming
The gRPC proxy pins sessions to the TCP connection to support unmodified gRPC clients that ignore cookie headers. This matters when an intermediary proxy for streaming, such as Kit streaming or Low Latency Streaming (LLS), uses HTTP/2 and reuses connections.


Do not pre-allocate streaming sessions with POST plus X-NVCF-ABSORB when a
shared HTTP/2 client can reuse one TCP connection across multiple users or
flows. Two separate requests sent over the same connection can receive the same
request ID from the proxy, which can bind different users or flows to the same
Kit pod.
Use on-demand binding through the WebSocket instead: establish the WebSocket, obtain the request ID from the proxy, and use that ID for subsequent requests.
For requirements and a sample intermediary proxy implementation, see Intermediary Proxy.