Documentation
Operations and limits
Operational limits, failure checks, and benchmark context.
Fixed limits
| Limit | Value |
|---|---|
| HTTP request body | 1 MiB |
| Render data | 64 KiB |
| One request asset | 256 KiB |
| All request assets | 512 KiB |
| One published object | 2 MiB |
| One downloaded control-plane object | 4 MiB |
| Loaded published versions | 128 |
| Loaded source, font, and static bytes | 64 MiB |
| Concurrent compilation | 4 |
| Render deadline | 10 seconds |
| Replica catalog reload | 5 seconds |
PostgreSQL reserves catalog capacity under a transaction-scoped advisory lock. A failed publication can leave an unreferenced object in storage, but it cannot create a published manifest that points at it.
First checks
| Symptom | First check |
|---|---|
| Renderer exits at startup | Check PostgreSQL, object storage, and required environment variables |
502 control plane unavailable | Check object hashes and PostgreSQL and storage connectivity |
409 on publish | Use a new immutable version name |
413 | Reduce request data, assets, or object size |
503 template registry cache limit exceeded | Change the catalog design or raise the compiled limit through a reviewed code change |
Benchmark context
On an ARM64 Docker host with both renderers capped at 2 CPU and 2 GiB, a small, steady-state invoice workload measured Katagami at 1,440–2,151 requests per second. The equivalent Gotenberg HTML conversion measured 10–14 requests per second. This is a stored-template API comparison, not a general renderer-only claim.
Reproduce it with:
REQUESTS=100 CONCURRENCY=4 CPUS=2 MEMORY=2g \
bash scripts/benchmark-gotenberg.sh