Skip to content

The case for in-process PDF generation

NextPDF runs inside your PHP process. That deployment topology shapes how you scale, secure, and test the documents you produce.

NextPDF generates PDFs inside your PHP application process. The application calls the renderer directly and receives the document bytes within the same runtime.

This architectural choice changes the shape of your system.

One application tier

The renderer shares the application’s runtime and deployment model. In production, that means:

  • One scaling unit. Application monitoring, patching, and capacity planning cover the renderer workload in the same tier.
  • An in-process call boundary carries HTML to the renderer and returns PDF bytes within the application runtime.
  • Application security controls cover the PHP application and native renderer together.

The Cloudflare adapter provides a Browser Rendering path for documents that select an edge renderer.

In-process architecture

NextPDF runs inside your PHP process. Your app and PDF engine share one deployment tier, with these effects:

It is worker-safe. The engine is built for long-running PHP workers—Laravel Octane, Swoole, RoadRunner—with an immutable Config, process-lifetime font and image registries, and a DocumentFactory that hands out disposable documents. You warm the fonts once at boot and produce a fresh document per request:

worker-boot.php
// At worker boot — once per process (imports omitted):
$fonts = new FontRegistry();
$fonts->addFontDirectory(__DIR__ . '/fonts');
$fonts->warmup();   // preload fonts at boot
$fonts->lock();     // freeze the registry for request handling

$images  = new ImageRegistry();
$factory = new DocumentFactory($fonts, $images);

// Per request — a disposable document, no shared mutable state:
$doc = $factory->create($config);
$doc->addPage();
$doc->writeHtml($html);
$doc->save($path);

It is deterministic. Given the same inputs, you get the same bytes. That is what makes golden-file testing possible (we pin every render against a known-good snapshot) and what makes reproducible archival meaningful.

It is auditable. NextPDF Core uses the Apache License 2.0 and is statically covered by a PHPStan Level 10 CI command. You can read the code that produces your documents in the same process and language as the rest of your app.

It fails closed. The engine rejects unsafe input with a typed error. Local asset reads can be jailed to an allowlist, and outbound transports must be pinnable.

When the edge is the right answer

Some workloads belong outside your application process. If you specifically want to render at the network edge, the NextPDF Cloudflare adapter renders HTML to PDF via Cloudflare’s Browser Rendering API from your PHP app, with the same SSRF hardening— a deliberate, bounded use of a remote renderer where it makes sense.

For your own application’s documents at scale in PHP, the in-process engine keeps rendering in the application tier. Use a renderer service when the workload requires one.