Weave Code
Screenshot Laravel Package
directorytree/screenshot
Laravel package for capturing screenshots of web pages with a simple, driver-based API. Point it at a URL and get an image back, with support for popular screenshot services and headless browsers. Configurable, queue-friendly, and easy to drop into any Laravel app.
Create browser screenshots with PHP and Laravel.
Frequently asked questions about Screenshot
- How do I install directorytree/screenshot in a Laravel app?
- Install it with Composer using composer require directorytree/screenshot, then publish the package config with php artisan vendor:publish and set your driver, browser binary path, and output disk. Because it is a Laravel-idiomatic package with a service provider and publishable config, registration is handled for you and the first capture is a single fluent call such as Screenshot::url(...)->save(...). The PHP side is genuinely small; the real setup cost is the runtime environment described in the next answers.
- Which screenshot drivers does this Laravel screenshot package support?
- The package uses a driver-based architecture with pluggable screenshot providers, so you can point it at popular screenshot services or a headless browser running on your own infrastructure. The driver is selected in the published config file. Check the repository for the exact driver names and their required dependencies before committing to one, since the supported list is not spelled out in the overview.
- Do I need to install Chromium or Node/Puppeteer on my server?
- If you use a headless browser driver, yes. The package is functionally a facade over headless Chromium tooling in the Browsershot/Puppeteer class, so you must ship a matching Chrome or Chromium binary with fonts, sandbox flags, proxy and egress rules, and memory limits into local, CI, and production images. That hardening work is commonly one to two weeks of platform effort with a named owner, not a single Composer command; a managed screenshot API driver avoids it but adds a third-party dependency and cost.
- Can I run Laravel screenshot capture on a queue instead of in the request?
- Yes, and you should. Keep capture off the request and response path entirely by wrapping the Screenshot::url(...)->save(...) call in a queued job, because a slow or failed page render should never block a user request. The package is described as queue-friendly, but confirm whether the default driver is synchronous or queued, and add explicit timeouts and concurrency ceilings to the job.
- How do I store screenshots on S3 or another Laravel filesystem disk?
- Output goes through Laravel filesystems, so you point the package at an existing disk (local, S3, or any configured Flysystem adapter) and a path rather than handling file writes yourself. Because the package only writes the image, your team still owns retention, lifecycle rules, and cleanup of generated files. If a missing or stale image would be a customer-visible incident, add retries and a placeholder image at the call site.
- Is it safe to screenshot user-supplied URLs with this package?
- The material security risk is the browser, not the PHP wrapper. Server-side capture of user-supplied URLs creates SSRF exposure toward internal metadata endpoints and services, plus session or credential leakage through rendered pages and resource exhaustion from oversized or hostile pages. Mitigate with strict URL allowlisting, isolated queue workers, hardened egress, and proper browser sandboxing; if those controls feel disproportionate to the feature's value, that is a strong signal to use a managed API instead.
- Which PHP and Laravel versions does directorytree/screenshot support?
- The package does not publish a stated support matrix in its overview, which is listed as an open question in technical review. Before adding it to a dependency register, check composer.json and the test matrix in the repository for the PHP and Laravel constraints. Pinning those constraints in your own composer.json protects you from a surprise upgrade path later.
- Can it capture authenticated pages, with cookies, custom headers, or a custom viewport?
- These capabilities are not documented in the package overview: cookies and authenticated sessions, custom headers, proxies, viewport sizing, full-page capture, and PDF output are all open questions to verify with the underlying driver. Some of them may be available via the headless browser driver's options, but do not assume it. Test each option you need in a staging environment before designing a feature around it.
- Is directorytree/screenshot actively maintained and safe to depend on?
- The signals are thin: roughly 34 stars, zero dependents, a single-maintainer profile, and no published security-response process or production case studies. Review notes also flag discrepancies in star count and a future-dated release date, so verify the repository directly rather than assuming active maintenance. Architecturally, treat it as a capability accelerator for regenerable output such as link previews and report thumbnails, not as an infrastructure commitment.
- What are the alternatives to directorytree/screenshot for Laravel page captures?
- The main options are calling Browsershot directly, running a headless Chrome sidecar or internal capture service, or paying for a managed screenshot API. Because this package has a small, expressive API that is easy to abstract, define your own ScreenshotCapturer contract and bind this package to it, which turns a future build, buy, or self-host decision into a config swap instead of a rewrite. If you cannot confidently swap drivers without touching application call sites, do not adopt it yet.
Weaver
How can I help you explore Laravel packages today?