- How do I install breuer/laravel-pdf-chrome-driver in Laravel?
- Install it with Composer alongside spatie/laravel-pdf, publish the package configuration, and set the driver class in config/laravel-pdf.php. You also need a Chrome or Chromium binary reachable from your application environment. The package is a driver plugin, so your existing Pdf::view(...)->save(...) calls should stay the same.
- Does this package require Node.js or Puppeteer?
- No. The driver talks to Chrome directly over the DevTools Protocol instead of going through Browsershot, Node.js, and Puppeteer. That is the main reason to choose it: it removes a second runtime from the PDF rendering path. You still need an actual Chrome or Chromium executable available to the application.
- Which Laravel and PHP versions are supported?
- The package is intended for Laravel applications that already use spatie/laravel-pdf, typically Laravel 10–12 on PHP 8.1 and newer. The authoritative version constraints are in the package's composer.json, so check those before upgrading. Also confirm that your installed spatie/laravel-pdf major version is compatible with the driver contract.
- What is the difference between this driver and the default Browsershot driver?
- The default spatie/laravel-pdf path uses Browsershot, which shells out to Node.js and Puppeteer. This driver implements the Chrome DevTools Protocol directly, so it avoids the Node toolchain while keeping the same PdfBuilder API. Feature parity with Browsershot is not automatic and should be verified against the templates your application actually renders.
- What Chrome or Chromium setup does it need?
- You need a Chrome or Chromium binary that the Laravel process can launch, or whichever Chrome connection mode the package configuration supports. Check the package config and README for whether it expects a local binary, spawns a browser per render, or can connect to a remote CDP endpoint. In containers, install Chromium explicitly rather than assuming a host browser is present.
- Is breuer/laravel-pdf-chrome-driver production-ready?
- Treat it as a contained technical bet rather than a proven default. It has very low adoption, a single maintainer, and little downstream community, so production use should be gated by a timeboxed spike and parity testing. The MIT license helps because the driver surface is small and forkable if maintenance stalls.
- Does it support headers, footers, background printing, and other PDF options?
- Chrome's Page.printToPDF domain supports many print options, but not every spatie/laravel-pdf PdfBuilder method is guaranteed to be honored by this driver. Header and footer HTML, tagged or accessible PDF output, scale, and font embedding are common parity gaps in direct CDP implementations. Test each option your invoices, statements, and reports rely on instead of assuming Browsershot behavior carries over.
- How does it handle wait conditions and timeouts?
- A direct CDP driver has to implement wait behavior itself, so verify support for network-idle waits, selector waits, JavaScript flags, delays, and timeouts before relying on them. These semantics are where Browsershot has accumulated years of practical behavior. Put your slowest and most JavaScript-heavy templates into the spike and confirm the PDF is complete before it is saved.
- Can I run it in Docker, Alpine, or on ARM?
- It can fit containerized deployments well because removing Node can shrink images and reduce the runtime and CVE surface. You still need a compatible Chromium build for your base image and CPU architecture, plus appropriate sandbox flags when running as root in a container. Check how the driver manages Chrome processes so you do not leak orphan processes or grow memory across renders.
- How do I migrate from Browsershot without breaking existing PDFs?
- Make the driver environment-selectable so rollback is a config change rather than a deploy. Capture a fixture corpus of the PDFs your application generates today, including headers, footers, custom fonts, and embedded images, then compare page counts, extracted text, and visual diffs rather than byte hashes. Run both drivers in staging for the same inputs, log divergence, and canary a small percentage of production traffic before switching fully.