Zitadel cloud grpc client recommended keepalive parameters

Hi,

We are on a zitadel cloud pro plan, we use the zitadel-go pkg to communicate with our zitadel instance, when we create a new client (https://github.com/zitadel/zitadel-go/blob/45e1206d57a1e78fea9afcdca37c6bda1463a10c/pkg/client/client.go#L123) what are the recommended keepalive parameters for the client? (https://pkg.go.dev/google.golang.org/grpc/keepalive) I'm getting responses like "rpc error: code = Unavailable desc = error reading from server: read tcp xx.xx.xx.xx:56690->xx.xx.xx.xx:443: read: connection reset by peer" after sometime if I create the client without any grpc options, so my guess is that we should be passing the keepalive option ( https://pkg.go.dev/google.golang.org/grpc#WithKeepaliveParams)

Best,
Jorge

GitHub

zitadel-go/pkg/client/client.go at 45e1206d57a1e78fea9afcdca37c6bda...

ZITADEL Go - The official client library of ZITADEL for an easy integration into your Go project. - zitadel/zitadel-go

Ask Inkeep•10/8/25, 12:36 AM

Hi @jorar, I'm an AI assistant for ZITADEL. While a team member reviews this question, I'll see if I can find relevant sources for your question.

Ask Inkeep•10/8/25, 12:36 AM

Answer

I wasn't able to find a direct answer about recommended gRPC keepalive parameters for the ZITADEL Go client, here are some relevant sources:

Integrating Your Application with ZITADEL using RFC 8628 OAuth 2.0 Device Authorization Flow : Contains information about Go client libraries and mentions that the ZITADEL OIDC repository includes device authorization in the rprp package, which may provide insights into client configuration patterns.
Terraform access credentials : Shows a user experiencing gRPC-related issues with their reverse proxy configuration, suggesting that gRPC connectivity can be affected by infrastructure setup.

For specific keepalive parameter recommendations for ZITADEL Cloud Pro, I'd suggest clicking the "Ask for help" button to have a team member review your question, as this requires configuration guidance specific to your cloud environment.

Ask Inkeep•10/8/25, 12:36 AM

Feel free to tag @Ask Inkeep with additional questions.

AAsk Inkeep Empty message

Ask InkeepAPP•10/8/25, 12:37 AM

Got it. Tagging @Rajat for additional help.

Rajat•10/8/25, 8:34 AM

hey @jorar will take a look and get back to you on it.

jorarOP•10/8/25, 3:09 PM

Thanks @Rajat !

jorarOP•10/17/25, 6:17 PM

Hi @Rajat any updates here by any chance? we are close go live to production with a feature that requires the communication with zitadel and want to make sure connections are not dropped.

Rajat•10/21/25, 1:43 PM

hey @jorar apologies for the delay, I was on vacation. You can try these sttings and please let me know if that works. I looked up in ClientParameters

grpc.WithKeepaliveParams(keepalive.ClientParameters{
    Time:                30 * time.Second, // send pings every 30s
    Timeout:             10 * time.Second, // wait 10s for ack
    PermitWithoutStream: true,             // keep idle connections alive
})

grpc.WithKeepaliveParams(keepalive.ClientParameters{
    Time:                30 * time.Second, // send pings every 30s
    Timeout:             10 * time.Second, // wait 10s for ack
    PermitWithoutStream: true,             // keep idle connections alive
})

the connection reset by peerconnection reset by peer happens because the TCP/HTTP2 connection is idle too long. You should enable gRPC keepalive. Please let me know if this helps.

grpc.WithKeepaliveParams(keepalive.ClientParameters{ Time: 30 * time.Second, // send pings every 30s Timeout: 10 * time.Second, // wait 10s for ack PermitWithoutStream: true, // keep idle connections alive })