Why is hosting GRPC services in containers so hard?

[Kralizek]

I have an application based on multiple GRPC services (all ASP.NET Core) that works flawlessly locally (via Aspire). Now it's time to go cloud and I'm facing a lot of annoying problems in deploying those services in Azure Container Apps.

The biggest issue is that, when you deploy in containers, regardless of the hosting technology, you don't have TLS in the containers but you use some kind of TLS termination at the boundary. This means that the containers themselves expose their endpoints in plain HTTP.

This works fine with regular REST services but it gets very annoying when working with GRPC services who rely on HTTP2. Especially, if you want to expose both GRPC services and traditional REST endpoints.

Theoretically, you could configure the WebHost via a configuration setting the default listener to accept both HTTP/1.1 and HTTP/2. Something like

ASPNETCORE_HTTP_PORTS=8080
Kestrel__Endpoints__Http__Url=http://0.0.0.0:8080
Kestrel__Endpoints__Http__Protocols=Http1AndHttp2

But the reality is very different as Kestrel really doesn't want to accept HTTP/2 traffic without TLS and rejects the HTTP/2 traffic. Eventually, after loads of trial and error, the only thing that actually works is listening to the two ports independently.

builder.WebHost.ConfigureKestrel(options => { 
    options.ListenAnyIP(8080, listen => listen.Protocols = HttpProtocols.Http2); // GRPC services
    options.ListenAnyIP(8085, listen => listen.Protocols = HttpProtocols.Http1); // Health checks and Debug endpoints
});

The first one is the main endpoint for the GRPC traffic. The second one is the one used for the health checks. When combined with the limitations of Azure Container Apps, it means that "debug" REST endpoints I use in non-prod environments are not accessible anymore from outside. This will probably also affect Prometheus but I didn't get that far yet.

So, I'm not sure what to do now. I wish there was a way to force Kestrel to accept HTTP/2 traffic without TLS on the ports specified in ASPNETCORE_HTTP_PORTS. I don't think it's a protocol limitation. It feels it's just Kestrel being too cautious but unfortunately, containers usually work without TLS.

Honestly, I hope I just made a fool of myself with this post because I missed a clearly self-telling setting in the ConfigureKestrel options.

[vst121]

Hi! 👋

This is expected behavior: Kestrel refuses HTTP/2 without TLS by default. It’s not a configuration bug. It’s a security enforcement in HTTP/2.

✅ Workarounds:

1. Use separate ports (HTTP/1.1 for REST/health, HTTP/2 for gRPC) - what you’re already doing.
2. Enable HTTP/2 without TLS explicitly per endpoint in ListenOptions (only for local/dev use):
   options.ListenAnyIP(8080, lo => lo.Protocols = HttpProtocols.Http2);
   This works, but you need container boundary TLS for production.
3. Alternative: put a reverse proxy / TLS termination (like Envoy or Nginx) in front of the container to handle HTTP/2 over TLS externally.

So there’s no hidden Kestrel setting that lets you combine HTTP/1.1 + HTTP/2 on the same port without TLS in a container - your two-port setup is the recommended approach for cloud scenarios.

Hope it helps!

[Kralizek]

Hi, yes, I eventually got it to work exactly how you explained.

It’s not a configuration bug. It’s a security enforcement in HTTP/2.

I wouldn't call it a bug. Or more like a devx bug: it shouldn't be so complicated to host a grpc service in a container.

It's not a "weird use case", so I don't see why the framework shouldn't make our life easier to support it.