bodyLimit: Adjusting maximum request body size for cost‑effective Fastify deployments

Answer the Questions First

1. Recommended bodyLimit value

For a low‑traffic Fastify server that occasionally receives larger payloads, a pragmatic bodyLimit is 5 MB (5 * 1024 * 1024 bytes). This value keeps memory usage modest while still accommodating most legitimate uploads that exceed the default 1 MB.

2. Interaction with fastify‑compress

When fastify-compress is enabled, Fastify decompresses the request body before applying bodyLimit. Therefore the limit applies to the *uncompressed* size. A client that sends a 6 MB payload compressed to 1 MB will still be rejected because the decompressed size (6 MB) exceeds the 5 MB limit.

3. 413 bypasses onError hooks

If a request exceeds bodyLimit, Fastify immediately returns a 413 Payload Too Large response. This happens before any onError hook runs, so custom error handling, caching, or logging logic placed in onError will not see the request. To capture these events you need a global 413 handler or middleware that runs earlier.

Practical Steps

1. Set the limit in the Fastify instance:

   const fastify = require('fastify')({ bodyLimit: 5 * 1024 * 1024 })

2. Register a global 413 handler if you need to log or cache these requests:

   fastify.setErrorHandler((error, request, reply) => {
     if (error.statusCode === 413) {
       // custom logging or caching logic
     }
     reply.send(error)
   })

3. Test with plain and gzipped bodies to confirm behavior:

   • Plain 4 MB body → 200 OK, logged by onError.
   • Plain 6 MB body → 413, no onError log.
   • Gzipped 6 MB body → 413, no onError log.

Things to Watch For

• Chunked or streaming uploads may be cut off by bodyLimit, leading to client errors that are hard to trace.
• Clients that send highly compressed data still risk hitting the limit if the decompressed payload is large.
• Because 413 bypasses onError, any middleware that relies on that hook will miss oversized requests unless you add a dedicated handler.