Memory exhaustion in Bun.serve() when concurrent requests buffer large bodies

Goal

I want to run a Bun.serve() HTTP server that accepts concurrent POST requests with multi-megabyte bodies without the process exhausting memory or showing latency spikes that only appear under load. A single request in isolation behaves fine; the concern is specifically the concurrent case.

Constraints and uncertainty

My understanding is that calling await req.text() or req.json() buffers the entire body in memory per request, so N simultaneous uploads multiply peak RSS by N. It is unclear to me whether Bun applies any internal backpressure or connection-level limits before the handler runs, or whether the only safeguard is streaming via req.body (a ReadableStream). I am also unsure how much of the latency under burst load is garbage collection pressure from these allocations versus the native network layer, and whether this differs between Linux and macOS builds. Assume a recent Bun 1.x release.

Questions

• Does Bun.serve() provide any documented option to cap per-request body size or total in-flight buffered bytes before the fetch handler is invoked?
• Is streaming the request body via req.body the only reliable way to avoid per-connection buffering, and does it interact with Bun's concurrency model differently than buffered reads?
• What is the recommended way to verify whether observed latency spikes under concurrent load come from GC versus connection queuing?