Caddyfile's request_body max_size is written inline, so Caddy ignores it — and writing it correctly would break 50MB event imports

Line 20 of the Caddyfile is

    request_body max_size 10MB

Caddy accepts that line and throws the size away, so every deployment behind the bundled Caddy is running with no proxy-level body limit.

request_body only reads max_size from inside a block. In modules/caddyhttp/requestbody/caddyfile.go, parseCaddyfile calls h.Next() to consume the directive name and then goes straight into for h.NextBlock(0), so tokens sitting on the same line are never looked at. No error, no warning.

caddy adapt shows it, using the version docker-compose.yml pins:

$ caddy adapt --config Caddyfile --adapter caddyfile

As written:

{"handler": "request_body"}

With a block:

{"handler": "request_body", "max_size": 10000000}

The part worth deciding before patching it: the obvious fix would break site imports. server/src/index.ts sets a global bodyLimit of 10MB, but raises it to 50MB for one route:

fastify.post(
  "/sites/:siteId/imports/:importId/events",
  { ...adminSitesWrite, bodyLimit: 50 * 1024 * 1024 },
  batchImportEvents
);

That path goes through handle /api/*, so a working 10MB cap at the proxy would 413 those batches before Fastify ever saw them. Historical imports from Umami and Simple Analytics presumably only work today because the limit is being dropped.

So it needs the braces plus a limit that matches the most permissive route, or a matcher that exempts the import path:

-    request_body max_size 10MB
+    request_body {
+        max_size 50MB
+    }

Alternatively drop the directive and let Fastify hold the policy on its own, since it is the only place that can express it per route.

Checked against caddy 2.10.0. I hit this while moving the compose setup behind Traefik instead of the bundled Caddy and trying to reproduce the same limit — the 10MB number turned out to be the one thing that was never in effect.