- What is claudiodekker/firewatch and what problem does it solve?
- Firewatch is a Laravel developer-tooling package that captures the telemetry Laravel Nightwatch's sensors collect, covering services such as the database, cache, queue, and scheduler, and writes it to a local SQLite file. It then exposes that store to an AI assistant over the Model Context Protocol so you can query your own telemetry conversationally while debugging. It sits downstream of Nightwatch rather than replacing it, so it adds a queryable local record on top of an existing Nightwatch setup.
- Do I need Laravel Nightwatch installed to use Firewatch?
- Yes. Firewatch reads the sensor output produced by Laravel Nightwatch, so an application that has not adopted Nightwatch has nothing for it to capture and will produce no useful data. It runs alongside the existing Nightwatch agent rather than displacing it, so your production telemetry is unaffected. If Nightwatch is only enabled in production, you will need it active in the environments where you want Firewatch data.
- How do I install Firewatch in a Laravel application?
- The typical flow is a Composer require, service provider auto-discovery, publishing the config file, and registering the MCP server with your AI client such as Claude Desktop or Cursor. You also need the pdo_sqlite extension enabled and a writable, gitignored storage path. Confirm the exact commands and config keys against the README, because at v1.0.0 the documented flow is the source of truth.
- Which MCP clients work with Firewatch, and what transport does it use?
- Firewatch is designed to be registered as an MCP server in assistants that support the Model Context Protocol, with desktop clients such as Claude Desktop and Cursor as the obvious targets. Whether the transport is stdio or HTTP is not confirmed in the material available here, and neither is whether the server binds only to localhost, so verify both in the README before wiring it up. As a general rule, keep any MCP server bound to loopback on a developer machine.
- Where does Firewatch store its SQLite file, and should I commit it?
- The telemetry is written to a local SQLite file in your application's storage path, which requires the pdo_sqlite extension and write permissions for the web process. Treat that file as sensitive developer-machine data and keep it out of version control, since captured sensor output can plausibly include query bindings, headers, and job arguments. Retention and pruning behaviour is not documented in the available material, so check the defaults in the source before letting the file grow.
- Can I run Firewatch in production as an observability tool?
- No. Firewatch is a local developer-tooling component, not a production observability system, and it does not replace Nightwatch or an APM. The sensible pattern is per-environment enablement, restricting it to local and possibly staging so production traffic is never written into a developer SQLite file that then gets copied around. Production monitoring should stay with Nightwatch or your existing telemetry stack.
- Does Firewatch redact sensitive data like query bindings, request payloads, and headers?
- This is the most important item to verify before pointing an AI assistant at the database. Firewatch captures what Nightwatch's sensors record, which plausibly includes query bindings, request payloads, headers, and job arguments, and the material available here does not confirm whether a redaction or allow-list configuration exists or what its default is. Read the README and the published config, and if no redaction is offered, restrict enablement to local environments and handle the SQLite file as sensitive data.
- Which PHP and Laravel versions does Firewatch support?
- Firewatch v1.0.0 is the initial release, so check its Composer constraints for the supported PHP and Laravel range before assuming compatibility with your oldest maintained application. The package depends on laravel/nightwatch, and how tightly that constraint is pinned determines how much upgrade friction you inherit when Nightwatch ships a minor release. Verify the support matrix against your baseline rather than relying on the package description alone.
- How do I verify Firewatch is actually working during local testing?
- Because Firewatch consumes Nightwatch's sensor output, a broken capture can look like success: the MCP server still answers, but the SQLite database is empty. During local testing, hit a route or run a job that should trigger several sensors, then open the SQLite file directly and confirm rows are being written before you debug through the AI client. If the database stays empty, check that Nightwatch is active in that environment, that the storage path is writable, and that the Nightwatch version you run still matches what Firewatch expects.
- Is Firewatch actively maintained, and what are the alternatives?
- Firewatch is at v1.0.0 with no long track record, and the release notes point to a single maintainer, so pin the version you adopt and budget for fork risk if it stalls. For comparison, Nightwatch itself covers telemetry collection, Laravel Telescope covers local debugging, and Laravel Pulse covers production metrics. Firewatch's differentiator is the MCP layer that lets an AI assistant query your local telemetry, so evaluate it on that basis rather than as a monitoring replacement.