Wkhtmltopdf I386 Laravel Package

Product Decisions This Supports

• Build vs. buy vs. adopt for PDF generation. This package is the "adopt an OSS binary" option on that spectrum. It doesn't decide the question for you, but it defines the cheapest possible floor: a Composer-installable binary with no service, no vendor contract, and no per-document cost. That's a useful data point when sizing the alternative of a hosted PDF API or a headless-Chrome service.
• Feasibility spikes for document output. Invoices, statements, packing slips, report exports, and "download as PDF" buttons are recurring roadmap asks. If you need a throwaway proof of concept this week to validate layout and stakeholder expectations, a binary + Snappy wrapper is a two-hour spike, not a sprint.
• Render-fidelity trade-offs. Because it renders with QtWebKit, it anchors a real product question: do we need a modern CSS/JS engine (flexbox, grid, custom fonts, JS-driven charts) or is the output mostly tabular, static HTML? Answering that determines whether you stay on WebKit-style renderers or move to Chromium.
• Dependency and platform risk register entries. The 2018 last release, i386-only target, and LGPL-3.0 license are all items that belong in your technical due-diligence log — particularly if you sell into enterprises that ask for SBOMs or run vulnerability scans on container images.
• Infrastructure standardization. Choosing a 32-bit binary has downstream consequences for base images, CI runners, and Docker layers. This is a decision about how much legacy you're willing to carry in your deployment pipeline.

When to Consider This Package

Consider it only when all of the following hold:

• You are on, or explicitly targeting, a 32-bit x86 Linux host (legacy Debian/Ubuntu VM, old on-prem appliance, embedded deployment). Modern x86_64 and ARM infrastructure is the dominant case, and this binary will not run natively on either.
• You already have a working wkhtmltopdf-based pipeline (typically knplabs/knp-snappy or barryvdh/laravel-snappy) and need to pin the binary via Composer instead of a system package, for reproducibility.
• Your templates are static, table-heavy, and already tuned to QtWebKit's quirks — a migration would cost real QA time for no user-visible gain.
• The input HTML is fully trusted (your own Blade templates), never user-supplied.

Look elsewhere when any of these are true — which, for new work, is most of the time:

• Any modern platform. 32-bit x86 is a poor fit for x86_64 and impossible on ARM (Graviton, Apple Silicon dev machines, ARM containers). Getting it running on x86_64 requires installing multiarch 32-bit compatibility libraries, which is fragile in slim base images and adds attack surface.
• Untrusted or semi-trusted HTML. Rendering third-party content through an unmaintained QtWebKit build is an SSRF and local-file-read risk (file://, internal metadata endpoints) layered on top of years of unpatched WebKit CVEs. This alone should disqualify it for customer-supplied templates.
• Any new build after roughly 2020. Upstream wkhtmltopdf has had no meaningful release since 0.12.6 and the project has been wound down; this package stopped at 2018. You are adopting abandonware.
• Modern CSS/JS requirements. Dashboards, charts, web fonts, CSS grid — QtWebKit will disappoint, and the workarounds are expensive.
• Accessibility or PDF/A requirements. You need tagged PDFs; neither this nor upstream does that well.
• Legal/compliance sensitivity. LGPL-3.0 imposes obligations around the bundled binary (source availability, relinking rights). It's manageable, but it needs a real legal read, not a checklist tick.

Preferred alternatives to evaluate instead: spatie/browsershot or a Gotenberg container (headless Chromium — modern CSS, maintained, x86_64/ARM), barryvdh/laravel-dompdf for simple documents where fidelity is negotiable, or a managed API (DocRaptor, PDFShift) if you want zero infrastructure ownership.

How to Pitch It (Stakeholders)

To executives: This is a small, free, community-maintained binary that lets a Laravel app turn HTML into PDF. It is not a strategic platform choice — it's a convenience wrapper around an open-source tool whose upstream project has been inactive for years and whose last package release was January 2018. My recommendation is do not adopt it for new work. If it's already in the codebase, treat it as known technical debt with a defined exit: it constrains us to 32-bit Linux, exposes us to unpatched rendering-engine vulnerabilities if we ever render customer content, and will be increasingly awkward to build and deploy. The migration path to a maintained headless-Chromium renderer is well understood and typically a few days of template work, not a quarter.

To engineering: The package bundles a precompiled wkhtmltopdf i386 binary and is consumed through a wrapper like Snappy. Concrete concerns: (1) architecture — 32-bit only, requires multiarch libs on x86_64 and won't run on ARM; (2) age — last release 2018, upstream effectively frozen, so no security patches for the WebKit stack; (3) security posture — sandboxing is weak, and untrusted HTML implies SSRF and local-file-read exposure; (4) license — LGPL-3.0 obligations attach to redistribution. Use it only for a short-lived spike, or where a legacy 32-bit host already depends on it. For anything shipping, propose Browsershot or Gotenberg so we get a maintained Chromium, arm64 images, and modern CSS support.

One-line summary for a decision log: Cheap, zero-infrastructure HTML→PDF shim; obsolete on architecture, maintenance, and security grounds — approve for prototyping only, reject for production.