- How do I install TraceReplay in a Laravel app?
- Install TraceReplay with composer require iazaran/trace-replay, then run php artisan trace-replay:install and php artisan migrate. The service provider is auto-discovered, and you can optionally publish config and views. The dashboard is then available under its configured route prefix.
- Which Laravel and PHP versions does TraceReplay support?
- TraceReplay requires PHP 8.2+ and supports Laravel 10, 11, 12, and 13 according to its package badges. The optional global TraceMiddleware can be appended to the web group on Laravel 10 or registered in bootstrap/app.php on Laravel 11+. It is designed to fit the normal request lifecycle without framework surgery.
- How is TraceReplay different from Laravel Telescope?
- TraceReplay is step-oriented, while Telescope is request- and framework-oriented. Telescope tells you what the framework did; TraceReplay is designed to show what your business workflow did by capturing manual TraceReplay::step() calls. Auto-tracing for jobs, commands, and Livewire gives you the shell, but the business narrative depends on deliberate instrumentation.
- Do I need to instrument every workflow manually?
- You do not have to instrument every workflow, but the business narrative only exists where engineers wrap work in TraceReplay::step(). A practical approach is to choose three to five high-value workflows, agree on step granularity, and instrument those first. The testing helpers can then lock in the expected workflow shape.
- How should I secure the TraceReplay dashboard in production?
- Treat dashboard access control as a hard prerequisite, not a follow-up ticket. The dashboard serves captured request and response payloads, headers, and stack traces, so protect it with web and auth middleware plus a can:view-trace-replay Gate. Do not expose the route prefix publicly in production.
- Is TraceReplay HTTP replay safe against production data?
- Replay defaults are conservative: non-GET requests are blocked, hosts are allowlisted, and auth, cookie, and CSRF headers are stripped. The remaining risk is human, because engineers may read safe replay and click anyway. Pin the replay-related environment variables per environment so they cannot be casually flipped.
- What sensitive data does TraceReplay mask before storage?
- Masking is key-name based and covers fields such as password, token, api_key, authorization, cookie, and secret. It will not reliably catch a customer email in a JSON body, a card number in a form field, or an identifier in a URL path, although query bindings are off by default. Review captured payloads and retention rules before enabling tracing on sensitive production flows.
- Can TraceReplay send trace data to OpenAI or Anthropic?
- Yes, TraceReplay ships direct OpenAI, Anthropic, and Ollama integration, but that path sends stack traces, payloads, and state snapshots to a third party. The no API key prompt-copy path avoids data egress entirely. Keep that as the default until security and legal sign off on external AI processing.
- Does TraceReplay support testing workflow traces?
- TraceReplay::fake() provides assertions such as assertStepRecorded and assertTraceCount. That turns the tracer into a regression harness for workflow shape, not just a debugging UI. It is a strong reason to instrument critical workflows and test their expected steps in CI.
- What are the production overhead and retention considerations for TraceReplay?
- Per-step DB query and memory tracking costs CPU and I/O, so use sampling, track_db_queries=false, and max_payload_size as levers, and load test at your expected QPS because the package does not document high-traffic cost. Plan retention by scheduling trace-replay:prune and estimating row growth per 1,000 traced requests. Also note that package migrations do not run on composer update, so every upgrade needs a manual migrate and a review of UPGRADE.md.