Weave Code
Flare Daemon Laravel Package
spatie/flare-daemon
A long-running PHP daemon that accepts error reports, traces, and logs from your Laravel app over local HTTP and forwards them to Flare asynchronously, keeping Flare delivery off your request path with automatic fallback to direct delivery.
spatie/flare-daemon is a long-running PHP daemon that accepts error reports, traces, and logs from your app over a local HTTP connection and forwards them to Flare asynchronously, keeping delivery off the request critical path. If the daemon is unreachable, the Flare client falls back to direct delivery automatically.
- Built on ReactPHP; local HTTP server with a 1s flush cycle
- In-memory buffers per API key and entity type
- Quota-aware pausing after 429/403 responses
- Test payloads bypass buffering and return upstream responses
- Automatic direct-delivery fallback
Frequently asked questions about Flare Daemon
- What is spatie/flare-daemon and what problem does it solve for Laravel apps?
- It is a long-running PHP daemon, built on ReactPHP's event loop, that accepts error reports, performance traces and logs from your application over a local HTTP connection and forwards them to Flare asynchronously. Instead of a Laravel request waiting on Flare ingress, the app posts to a loopback endpoint and returns immediately, keeping telemetry delivery off the critical path. Payloads are buffered per API key and per entity type, and a periodic flush timer sends them upstream.
- Do I need to install spatie/flare-daemon separately, or does it come with the Flare Laravel package?
- The daemon is its own Composer package, but it typically arrives transitively because Flare's PHP client packages install it by default while runtime activation stays explicit. In practice the work is not adding a dependency but flipping the transport toggle and standing up the process. You can run it from the vendor bin directory, from the bundled PHAR, or from the published Docker image.
- Which Laravel and PHP versions does spatie/flare-daemon support?
- The daemon is a standalone ReactPHP process rather than a Laravel package with a service provider, so it does not pin a Laravel version itself. What matters is the flare-php and flare-laravel client versions you already run and the PHP runtime available to the daemon process. Check the repository's composer.json and changelog for the current PHP requirement, and keep client and daemon versions reasonably aligned.
- Does the daemon add a hard dependency or latency to my Laravel requests?
- No. If the daemon is unreachable, the Flare client automatically falls back to direct delivery to Flare ingress, so your requests keep working. That graceful degradation is what turns this into a latency optimisation instead of a new single point of failure. The trade-off is that during fallback you are back to synchronous delivery and anything still buffered is lost.
- What happens to buffered errors, traces and logs if the daemon restarts or runs out of memory?
- Buffers are in-memory only, with no disk spool, so a restart, crash or OOM kill silently discards anything not yet forwarded. For error tracking that loss is usually tolerable; for audit-adjacent logs it may not be. Treat the daemon as best-effort delivery and confirm whether dropped payloads are counted on the status endpoint before relying on it for anything compliance-shaped.
- How do I configure the daemon's buffer size, flush interval and local port?
- The documented knobs are environment variables: FLARE_DAEMON_BUFFER_BYTES, which defaults to 256 KB, and FLARE_DAEMON_FLUSH_AFTER_SECONDS, which defaults to 10 seconds. The HTTP listener defaults to 127.0.0.1:8787. Both buffer settings are described as maintenance safety nets rather than guarantees, so tune them against how much telemetry you can afford to lose during an upstream outage.
- How do I run and supervise spatie/flare-daemon in Docker or Kubernetes in production?
- Distribution is deliberately multi-channel: the vendor bin, a bundled PHAR, a Docker image and a Helm DaemonSet, all tracking one canonical version stream. That cleanly splits ownership, with platform engineering running the daemon in Kubernetes while application teams only manage client config. Plan for process supervision, memory limits, and a SIGTERM drain that a slow upstream cannot stretch past your termination grace period.
- Is the daemon's local HTTP ingest port authenticated, and is it safe to expose?
- The default bind is 127.0.0.1:8787, which keeps ingest on the loopback interface, but the Helm DaemonSet exposes it on the node network with internalTrafficPolicy set to Local. Anything that can reach that port can post a payload, and a spoofed payload can burn your Flare quota. Add network policy and decide explicitly who is allowed to talk to the port.
- How do I test that the daemon is receiving and forwarding payloads?
- The daemon supports test payloads that bypass the buffers, make a synchronous upstream request and return the upstream response to the caller, which is the fastest end-to-end check. Use the status endpoint to confirm buffer and quota state, then throw a real exception from a Laravel route and watch it land in Flare. Remember the fallback path, so a passing test does not just mean direct delivery quietly kicked in.
- Is spatie/flare-daemon production-ready, and what are the alternatives?
- It is an early-stage package with little external production evidence, and quota handling has already changed between releases, including 403 and 429 behaviour in 0.3.1, so pin versions and read changelogs. Vendor benchmarks such as roughly 18,000 reports per second at p95 under 11 ms come from an M-series Mac, not from your kernel or container stack. The alternative is letting flare-laravel deliver directly and accepting synchronous telemetry, or building the same sidecar shape with a general-purpose collector if you need durable spooling.
Weaver
How can I help you explore Laravel packages today?