Flare Daemon Laravel Package

Product Decisions This Supports

• Removing vendor telemetry from the request critical path. Every error report, trace, and log currently costs the user request a synchronous round trip to ingress.flareapp.io. The daemon moves that to a local 127.0.0.1:8787 POST and flushes asynchronously on a ~1s cycle, so this is a latency and tail-latency decision, not a features decision. It directly supports p95/p99 SLO work on high-traffic endpoints.
• Vendor-outage blast radius. Because the Flare client falls back to direct delivery when the daemon is unreachable, this is a reversible, low-risk adoption: worst case is the status quo. That makes it a cheap hedge against "our error reporting is slow and it's taking the app down with it."
• Observability cost/quality tradeoffs. Teams often suppress verbose logging in production because the per-request cost of shipping logs is too high. A local buffer that accepts ~18k reports/sec at p95 <11ms (per the bundled k6 benchmark) makes "log more, not less" a viable roadmap item — relevant if the roadmap includes better post-incident forensics.
• Deployment topology as a product/platform decision. The package ships four operator paths — Composer vendor bin, standalone PHAR, Docker, and a Helm DaemonSet with internalTrafficPolicy=Local — which is a platform-team decision about where the daemon lives (per-node, per-pod sidecar, or per-host process) rather than an application-code decision. That's a good candidate for a platform standard rather than per-team improvisation.
• Build vs. buy. This is squarely "buy/consume." Nothing here justifies building an internal async error-forwarding layer; the hard parts (per-key/per-type buffering, 429/403 quota pause semantics, graceful drain on SIGTERM, composer.lock-change shutdown for zero-dropped-reports deploys) are already handled and are surprisingly easy to get wrong in-house.
• Enablement gating as a product lever. The vendor explicitly separates installed by default from enabled by default. That gives us a clean staged rollout: ship it inert via the client upgrade, pilot on one high-traffic service, then flip per-environment. Worth a decision record so no one assumes a composer update silently changed production behaviour.
• Incident-response readiness. /health and /status endpoints plus the tests/test.sh smoke path mean we can add a daemon health check to runbooks and synthetic monitoring — a small but real reduction in MTTD for "we stopped receiving errors and nobody noticed."

When to Consider This Package

Adopt when most of these hold:

• You are already a Flare customer. The daemon's upstream is Flare ingress, full stop. There is no generic backend to point it at (FLARE_DAEMON_UPSTREAM exists, but you'd be implementing Flare's contract). This is not a generic telemetry relay.
• Error/log volume or per-request telemetry latency is measurable. If you're doing hundreds of requests per second and each one can block on a SaaS round trip, the win is real. If you're at a few hundred requests a day, the daemon is operational cost with no visible benefit.
• You can run a long-lived process. Kubernetes, ECS, systemd, Forge/Ploi-style process managers — yes. Shared hosting, classic PHP-FPM-only hosts with no supervisor, or a pure serverless/FaaS deployment where a localhost listener doesn't meaningfully persist — no, and the fallback means you lose nothing by skipping it.
• You have a platform owner for it. Someone must own the image version, the Helm values (phpMemoryLimit defaults to 128M), the port exposure, and the restart policy. Unowned daemons become mystery CPU consumers.
• You're on PHP 8.1+. The 0.3.0 release lowered the floor from 8.2, so legacy-ish Laravel apps are in scope.
• Dependency hygiene matters. The Composer bin is a bundled PHAR built from a separate runtime/composer.json, so ReactPHP/PSR-7 never enter your application's dependency graph. If your team has been burned by transitive dependency conflicts, this is the reason to prefer it over a "just add a queue worker" alternative.

Look elsewhere (or stay direct) when:

• You're on Sentry, Bugsnag, or a self-hosted stack. Same architectural idea exists there (Sentry's Relay, for example); don't adopt this one.
• Your blocker is retention, sampling, or PII redaction, not delivery latency. The daemon changes how payloads travel, not what you collect. It won't fix an over-collection or data-governance problem.
• Compliance forbids local listener processes on application hosts, or your threat model dislikes an extra unauthenticated loopback HTTP surface inside the pod.
• You want vendor-neutral telemetry. This is a single-vendor convenience layer; treating it as infrastructure strategy is a category error.
• Maturity is a hard gate. Zero stars and zero dependents with a 2026 release date means this is young, vendor-owned, and lightly battle-tested outside Spatie's own use. Reasonable to consume as a bundled client dependency; unreasonable to make a load-bearing platform bet on day one without the k6 and smoke-test paths in your own environment.

How to Pitch It (Stakeholders)

For executives (one paragraph): Flare's PHP client already installs this daemon by default; turning it on moves error and log delivery off the user request path and onto a local background process. The effect is lower and more predictable response times on our busiest endpoints, plus reduced exposure when the vendor has an outage or rate-limits us — and if the daemon isn't running, the client falls back to today's behaviour automatically. It's MIT-licensed, adds no dependencies to our application, and is enabled per-environment, so we can pilot it on one service and measure before committing. Cost is an extra small long-running process per host and the ownership of its container image.

For engineering leads: Install-and-enable are decoupled — upgrading the Flare client gives us the daemon inert, and activation is explicit. The Composer bin is a self-contained PHAR with its own isolated ReactPHP runtime, so no PSR-7 or event-loop version constraints leak into composer.lock. Configuration is entirely environment variables (listen address, upstream, buffer thresholds, upstream timeout, FLARE_COMPOSER_LOCK), and SIGINT/SIGTERM drain buffers before exit — including an optional graceful shutdown when composer.lock changes, which lines up cleanly with deploy hooks. For Kubernetes we use the published OCI Helm chart as a per-node DaemonSet with node-local routing and client-side fallback; for single hosts, a supervised vendor/bin/flare-daemon. Rollout plan: health//status check in the runbook, smoke test against a real API key in staging, load test with the bundled k6 script against our own traffic shape, then enable per environment behind a config flag.

Ask: approve a one-sprint pilot on one high-traffic service, with success measured as p95/p99 request latency delta and zero lost error reports across a deploy.