Laravel Blanket Laravel Package

Technical Evaluation

Architecture fit. Blanket is an observability sidecar, not a business-logic package. It hooks Laravel's outbound HTTP client events, persists request/response records, and serves a Blade dashboard — conceptually a narrower Telescope scoped to Illuminate\Support\Facades\Http calls. That makes it a dev/staging diagnostic, not a runtime dependency. For a platform team supporting many Laravel services that integrate with third-party APIs (payments, KYC, logistics, notifications), the debugging value is real but bounded.

Integration feasibility. Low effort: composer require --dev, service provider auto-discovery, publish config and migration, gate the dashboard route behind a Gate. A competent Laravel engineer can produce a working spike in under a day. The blocker is not effort, it's compatibility and ownership.

Technical risk.

• Staleness: last release 2021-09-30, predating Laravel 9/10/11. Expect illuminate/* constraint conflicts and a fork to install on current versions. Score of 2.39 and 215 stars confirms a small, inactive surface.
• Redundancy: modern Telescope already records HTTP client requests. Adopting Blanket may buy a nicer UI at the cost of a second data store and a second dependency.
• Security: it captures outbound headers and payloads — Authorization tokens, API keys, PII. The dashboard is a data-exfiltration surface if the Gate is misconfigured or the route is reachable in production.
• Abandonment: no maintainer means we inherit bug ownership the moment we fork.

Key questions.

1. Does it install cleanly on our current Laravel/PHP matrix, and what is the patch cost if not?
2. Are sensitive headers redacted by default, and can we enforce redaction centrally?
3. Is there a hard non-production guard, or is that entirely on us?
4. What is the retention/pruning story, and does capture fail open or closed?
5. Does Telescope/Clockwork already satisfy the requirement, making this net-new risk for marginal gain?
6. Who owns an internal fork, and for how long?

Integration Approach

Stack fit. Best suited to Laravel services with meaningful outbound HTTP volume and painful third-party debugging. Poor fit for services with little egress traffic or strict data-handling obligations without redaction work.

Migration path. Effectively zero lock-in: dev-only dependency, its own migration and config, no coupling to application code. Reversal is composer remove plus dropping one table. That low switching cost is the strongest argument for a time-boxed pilot.

Compatibility. Pin an exact version, test against our Laravel/PHP matrix in CI, and verify the Illuminate\Http\Client\Events surface it listens on is still stable on our target version. Assume a fork is required; budget for it up front rather than discovering it mid-pilot.

Sequencing.

1. Time-boxed spike on a branch in a non-production environment; measure install friction on our actual versions.
2. Compare output against Telescope/Clockwork on the same traffic — if parity is close, stop here.
3. If adopted, fork to an internal repo, add header/payload redaction and retention pruning, and run CI against supported Laravel releases.
4. Lock the dashboard behind a Gate plus an explicit environment check.
5. Document as developer tooling, excluded from production builds via --dev, with a named owner and review date.

Operational Impact

Maintenance. Treat as unmaintained. Budget a fork, an owner, and periodic compatibility patches. The codebase is small enough that this is tractable, but it is a recurring cost, not a one-off.

Support. Community-only, 215 stars, no vendor, no SLA. Internal SME coverage is required; there is no escalation path.

Scaling. Every captured outbound call is a database write — added latency on the request path and a table that grows quickly in high-egress services. Dashboard queries degrade as volume rises. Needs sampling, retention limits, and ideally a separate connection before it touches anything busy.

Failure modes.

• Capture listener error propagating into the outbound call path (verify fail-open before trusting it).
• Migration or dependency collision on Laravel upgrade.
• Secret/PII leakage through an unguarded or misconfigured dashboard.
• Unbounded table growth degrading the host database.
• Silent drift as Laravel's HTTP client evolves under a frozen dependency.
• Route exposure if the Gate is ever dropped in a refactor.

Ramp-up. Hours for a Laravel developer already familiar with Telescope; no formal training. The real cost is organizational discipline — ensuring it never reaches production and that captured credentials are redacted.

TPM recommendation. Conditional, dev-only. Approve a short pilot only if Telescope demonstrably fails the team's debugging needs; otherwise the redundancy, abandonment risk, and sensitive-data surface outweigh the convenience. If adopted, adopt the fork at the same time, not later.