Rubrol vs Gotenberg: Why Headless Chromium Clusters Are the Wrong Tool for E-Invoicing

Gotenberg is the go-to open-source HTTP API for converting HTML and Office documents to PDF using Dockerized Chromium and LibreOffice. But running heavy browser instances to spit out transactional B2B invoices results in memory leaks, OOM restarts, and second-long latencies. Here is what happens when you switch to native Typst.

The Rise of the Document Microservice

When developers don't want to manage Puppeteer or Playwright directly in their application code, they reach for Gotenberg. Created by Julien Neuhart, Gotenberg provides a polished Go-based REST API that orchestrates headless Chromium, LibreOffice, and PDFtk inside a single Docker container.

Gotenberg is undeniably well-engineered for its intended domain: ad-hoc file format conversions and generic HTML-to-PDF rendering.

However, using Gotenberg to generate millions of high-velocity, legally certified B2B e-invoices exposes severe systemic bottlenecks.

1. The Memory Leak Survival Strategy

Because Chromium and LibreOffice were never designed as long-running server daemons, they continuously leak memory over prolonged uptime. Gotenberg's own official documentation explicitly addresses this with restart switches:

# Gotenberg environment variables to survive memory degradation:
CHROMIUM_RESTART_AFTER=50
LIBREOFFICE_RESTART_AFTER=10

Think about that from a DevOps reliability standpoint: your core document generation infrastructure has to kill and restart its underlying browser processes every 50 requests just to avoid crashing the server.

If a sudden surge of 200 concurrent invoices hits your cluster, Gotenberg containers routinely spike from 600MB to 3GB+ of RAM, triggering OOM (exit code 137) errors unless you provision massive cloud instances.

Rubrol does not use a browser. Built entirely on the compiled Typst typesetting engine, Rubrol has no JavaScript runtime, no DOM tree, and zero memory leaks. It consumes less than 28MB of RAM under heavy continuous throughput.

2. Latency: 1,400ms vs 14ms

Generating an invoice via Gotenberg involves:

1. Accepting the multipart HTTP request in Go.
2. Spawning or dispatching to a Chromium tab.
3. Loading CSS, evaluating JavaScript, and waiting for the networkIdle event.
4. Paging the Skia layout buffer to a dirty PDF stream.
5. Routing that PDF through LibreOffice or ExifTool if PDF/A conversion is requested.

This entire pipeline takes between 900ms and 2,500ms per invoice.

Rubrol parses structured JSON and compiles Typst vectors directly to certified PDF/A-3b binary in 14 milliseconds. That is an immediate 60x to 100x latency reduction.

3. The LibreOffice Typography Disasters

When Gotenberg attempts to output PDF/A documents, it pipes files through LibreOffice's headless export filter.

Anyone who has run LibreOffice on a headless Linux server knows the consequences:

• Font kerning shifts unexpectedly between operating systems.
• Table borders misalign by half a pixel.
• Pagination wraps single trailing lines onto blank second pages.
• PDF files balloon from 40KB to over 500KB due to un-optimized font subsetting.

Rubrol’s Typst engine was designed from day one with the mathematical typesetting precision of TeX. Typography is deterministic to the micro-point across all platforms, yielding razor-sharp, lightweight PDF documents that look like they were designed by a master typographer.

The Verdict

Gotenberg remains an outstanding tool if you need to convert random Word documents (.docx) or render interactive HTML dashboards on the fly.

But for high-scale, mission-critical e-invoicing pipelines under the strict European EN 16931 mandate, Gotenberg's Chromium stack is a heavy, memory-hungry liability. Rubrol delivers the speed, density, and precision that modern cloud infrastructure demands.