Weave Code
Session Replay Laravel Package
packstub/session-replay
Packstub Session Replay captures user session activity in Laravel applications and lets you replay those sessions step by step to reproduce bugs and diagnose issues. Simple to install and configure, it gives developers a clear view of what users experienced without guesswork.
Session replay for Laravel: record what a person did in the browser with rrweb, keep the recording on your own disk and database, and watch it behind a gate you define — masked inputs by default, errors, failed Livewire requests and web vitals marked on the timeline, a link to the replay in every log line. packstub/filament-session-replay adds the sessions to a Filament panel.
Frequently asked questions about Session Replay
- How do I install packstub/session-replay in a Laravel application?
- Require the package with Composer, then run the session-replay:install Artisan command, which publishes the config, migrations and a service provider stub. Define a viewSessionReplay gate, configure the storage disk and the storage.connection database, and schedule the PruneCommand. Finally, add the SessionReplay::recorder() script tag to your layout. There is no front-end build step, since the recorder bundle ships in the package and is served by a controller.
- Which Laravel and PHP versions does packstub/session-replay support?
- The hard floor is PHP 8.3 or newer, and Laravel 12 or 13 only. Applications still on Laravel 10 or 11, or on PHP 8.2, are blocked until they are upgraded. Treat the version requirement as a scoping gate before you plan any rollout.
- Are passwords and other sensitive inputs masked in the recordings?
- Inputs are masked by default in the recorder before events ever leave the browser, so raw keystrokes in form fields are not captured. Masking happens client-side in the rrweb recorder, which means the protection applies regardless of how you store or view the replay. You should still confirm the masking behaviour on your own markup and any custom components during a staging spike.
- Do session recordings leave my server or go to a third-party service?
- No. Recordings are written to a disk and indexed in a database connection that you configure, so the data stays inside your own infrastructure. The package does not proxy replays through an external SaaS. This is the main reason it suits teams with data-residency or privacy constraints.
- How do I control who is allowed to watch a session replay?
- Access is enforced through the viewSessionReplay gate you define, wrapped by the package's AuthorizeViewer middleware around both the viewer and the data routes. The recording is passed to the gate as its argument, so you can write row-level rules rather than a simple boolean check. This is what lets you expose replay to support staff without exposing every recording company-wide.
- Does packstub/session-replay work with Livewire and wire:navigate?
- Yes. As of beta.5, a wire:navigate swap is recorded as a fresh snapshot rather than a single diff that re-adds every node: the recorder pauses on livewire:navigating, resumes on livewire:navigated, and falls back after five seconds if the event never fires. Failed Livewire requests are marked on the timeline as well. One consequence is that navigate-driven apps get roughly one chunk row per page, which matters for storage and pruning.
- Do I need Filament to use this package?
- No. The core recording, ingest and storage layer imports nothing from Filament or Livewire, and you can serve the bundled Blade viewer behind your gate on its own. The Filament panel integration lives in a separate sibling package, packstub/filament-session-replay, which you can adopt later as an independent decision.
- How do I clean up old session recordings?
- The package ships a PruneCommand that you schedule in your console kernel or routes/console.php, alongside the storage.connection setting that tells it where chunk metadata lives. Because the chunk model now writes roughly one row per page in wire:navigate apps, set the retention window with actual volume in mind. Schedule pruning from day one rather than after the first disk-space incident.
- Does the recorder work with a strict Content Security Policy?
- The SessionReplay::recorder() helper emits an inline script that carries the recorder configuration and the signed ContextToken, so it does interact with your CSP. Confirm a nonce or hash path during your staging spike before committing to a rollout date. The beta.5 release deliberately added no new CSP story, so this is unchanged from earlier versions.
- Is packstub/session-replay stable enough for production?
- The package is explicitly pre-1.0 and beta.5 is still a beta release, so config keys, migration names and route names are not frozen yet. The integration footprint has been stable across recent releases, and rollback is straightforward because releases have been recorder-side only. Pin an exact version, review the dist bundle diff at pin time, and test upgrades on staging before promoting them.
Weaver
How can I help you explore Laravel packages today?