Chrome Laravel Package

Product Decisions This Supports

Feature bets this unlocks (build vs. buy)

• Server-side document rendering — Generate invoices, statements, receipts, compliance reports, and contracts from existing Blade/HTML templates and get pixel-accurate PDFs. Directly substitutes for paid SaaS (DocRaptor, PDFShift, PDFreactor) with self-hosted commodity.
• Dynamic image generation — OG/social cards, link previews, certificates, badges, chart exports, product thumbnails. High perceived polish, low engineering cost.
• JS-aware crawling and data extraction — Price monitoring, catalog ingestion, content aggregation, and any scraping against SPAs where curl + DOM parsing fails. Choose this over lighter scrapers only when the target truly needs script execution.
• Synthetic monitoring / uptime and journey checks — Script a login, checkout, or search flow and assert on rendered outcomes; catches what HTTP health checks miss.
• Visual regression and E2E assertions inside PHP CI — Screenshot diffing and "does the page actually render" gates without adding Node/Puppeteer to the pipeline.
• Document automation workflows — Login-gated portals, form submission, batch downloads, e-signature handoffs, archival captures for audit.

Roadmap implications

• Enables a "preview before publish" or "export to PDF" capability in nearly any Laravel product with days, not weeks, of work.
• Makes scheduled report delivery and customer-facing document portals feasible without new infrastructure or vendor contracts.
• Provides an escape hatch for any future requirement that needs a real browser — a capability multiplier rather than a single feature.

Build vs. buy framing

• Build (this package): zero license cost, no per-render fees, no data egress to a third party, full control over browser flags, proxies, and headers. Cost shifts from variable spend to fixed compute plus engineering ownership of Chrome lifecycle.
• Buy (managed rendering API): you are purchasing concurrency pooling, autoscaling, crash recovery, and version churn — not rendering itself. That is the honest comparison; if your real need is 10k renders/hour at steady state, you are buying operations, not pixels.
• Do nothing: acceptable only for static markup with no JS, no web fonts, no grid/canvas — where dompdf/mpdf is the cheaper, safer answer.

Decision the PM must actually make: whether the organization wants to own a browser fleet. This package is a client library, not a rendering platform. Adopt it as a component inside a queue-and-worker design you commit to building, not as a drop-in service.

When to Consider This Package

Adopt when:

• The stack is PHP 7.4–8.5 and the team wants no Node sidecar, no second runtime, no IPC bridge in the deployment.
• Rendering fidelity genuinely matters — client-side JS, web fonts, flexbox/grid, canvas, authenticated sessions. These are exactly the cases where HTML-to-PDF libraries silently fail.
• Rendered volume is bounded and bursty (reports, monthly statements, per-publish previews) rather than sustained high throughput.
• You need fine-grained control over when a page is "ready" — DOM_CONTENT_LOADED, FIRST_MEANINGFUL_PAINT, NETWORK_IDLE are exposed here, which is materially better than naive sleep-and-hope wrappers.
• Persistent browser reuse via connectToBrowser + keepAlive fits a long-running worker or queue consumer.
• You can containerize with Chromium, apply --no-sandbox deliberately, and set memory/CPU limits.

Look elsewhere when:

• You need a rendering fleet. Concurrency, autoscaling, retry orchestration, and isolation are your responsibility here. If that isn't a competency you want to fund, a managed service is cheaper than the engineering you'll spend.
• The documents are static. No JS, no external assets → dompdf/mpdf avoids an entire Chrome dependency tree.
• Runtime constraints block Chromium. Shared hosting, minimal serverless layers, and locked-down base images will fight you.
• You cannot isolate untrusted input. Rendering arbitrary user-supplied URLs means SSRF, sandbox-escape, and resource-exhaustion exposure. Without network egress controls and container hardening, this is a security incident waiting to be scheduled.
• You depend on long-term maintenance guarantees. The metadata here shows README/changelog/releases but no evidence of formal support tiers, and a reported zero dependent packages should be verified against Packagist download volume and GitHub issue activity before it goes on a revenue-critical path. Treat it as a healthy but community-maintained dependency and pin versions.
• You need first-class queueing, caching, or asset pipelines out of the box. This is a raw DevTools client; everything above it is yours to build.

Adoption gate to set before committing: prototype one real workload, measure peak memory and cold-start per browser instance, define the timeout/crash-recovery policy, and confirm the container image can run headless Chromium under your platform's security posture.

How to Pitch It (Stakeholders)

For executives (one paragraph). This is an MIT-licensed library that lets our existing PHP code drive a real, headless Chrome browser — the same engine our customers use. It turns per-document SaaS bills (PDF generation, screenshot/OG-image APIs, third-party rendering services) into work our own servers do, and it opens up capabilities we currently can't build: branded PDF exports, dynamic social previews, scripted journey monitoring, and rendering of JavaScript-heavy pages our current tooling can't touch. There is no license cost and no vendor lock-in. The cost is engineering ownership — we must run Chrome safely in containers and monitor it — and the risk is operational, not commercial. Recommend a two-week spike against one concrete feature, then a go/no-go on broader adoption.

For engineering leads. The API is idiomatic, IDE-friendly, and synchronous or asynchronous. We get real DevTools-level control: page lifecycle events for precise readiness detection (NETWORK_IDLE, FIRST_MEANINGFUL_PAINT), viewport and user-agent control, custom headers, proxy support, pre-injected scripts, and persistent browser reuse across jobs. It keeps the rendering path entirely in PHP — no Node process, no cross-language RPC. What we take on: process lifecycle, memory pressure per instance, zombie reaping, container hardening for --no-sandbox, and a worker pool with timeouts and retries. Plan to wrap it behind our own service class with a queue, instance pooling, and structured failure handling before any feature calls it directly.

For security and platform. Rendering user-controlled URLs is an outbound-request primitive. Adoption should be conditional on egress filtering, per-request isolation, strict timeouts, and running the browser in a locked-down container with no access to internal networks or credentials.