Http Log Bundle Laravel Package

Technical Evaluation

Architecture fit — this is a framework mismatch, and it is the headline finding. nowo-tech/http-log-bundle is a Symfony bundle, not a Laravel package. Its distribution and integration surface is Symfony-shaped throughout: a DependencyInjection extension with a semantic config tree, compiler passes, kernel event subscribers (kernel.request, kernel.response, kernel.exception), Twig templates for the admin UI, and Symfony console commands for purge/export. Laravel's package discovery, service providers, middleware pipeline, Eloquent, Blade/Inertia, and Gate/Policy abstractions do not map onto any of that. Nothing about the bundle will "just work" in a Laravel app.

The one genuine point of contact: Laravel's Illuminate\Http\Request/Response extend Symfony's HttpFoundation types, and Laravel ships Symfony components. So the data plane — body capture, configurable body policies, redaction, persistence, export, purge — is plausibly reusable if those services are written against plain PHP/PSR types rather than the Symfony container and HttpKernel events. The control plane (wiring, config validation, admin rendering) is not reusable at all. The effective reuse ratio is unknown without source review and is the single most important diligence item.

Integration feasibility — three viable paths.

• A. Internal fork/port. Highest fidelity, highest cost. Estimate 3–6 engineer-weeks for middleware + storage + redaction + admin surface, net of whatever genuinely ports.
• B. Thin Laravel adapter over the bundle's core services. Register the agnostic services as singletons in a ServiceProvider, implement a global middleware that hydrates the bundle's log-entry types from Laravel's request/response, reuse redaction/policy/export/purge where decoupled, reimplement only the admin surface. Estimate 1–2 weeks, contingent entirely on coupling.
• C. Build, don't adopt. ~400–800 LOC of middleware, a redaction rule set, a retention job, and a simple query UI. Loses the polished admin UI and export; removes all vendor risk.

Recommendation: run B as a 3–5 day spike with a hard go/no-go gate on decoupling, and treat C as the credible default if the gate fails.

Technical risk.

• Vendor/bus factor (high). 2 stars, 0 dependents means zero downstream validation — no one has run this in production and reported back. Single-maintainer abandonment is the base case here, not the tail case. The MIT license is the mitigation: fork it and own it, and make that the plan of record rather than the fallback.
• Compatibility floor. Package targets PHP ≥8.2 and Symfony 7/8. That aligns with current Laravel, so no hard blocker — but Symfony major alignment and any Doctrine/DBAL dependency must be confirmed against the Laravel version in use.
• Metadata anomaly. The "last release 2026-10-21" date is inconsistent with normal cadence; treat registry metadata as unverified and check actual tags in the repository.
• Security surface (high). The product's job is persisting request/response bodies. A redaction bug is a PII leak into a database and into an export file. The "secured admin UI" will be Symfony-security-shaped and must be re-gated under Laravel's guard and authorization; assume zero carryover.
• Request-path fragility. An interception layer that can throw is an availability risk on every route it touches.
• Documentation unassessed. No docs corpus was supplied with this evaluation; README/guide depth is unknown.

Key questions to resolve before committing.

1. Is the redaction engine pure PHP + config arrays, or bound to Symfony's Config component tree?
2. Does persistence go through Doctrine/DBAL, a repository interface, or something swappable to Eloquent/query builder?
3. Is the admin UI Twig-only, or is there a JSON API we can re-render in Blade/Inertia?
4. Do existing tests run on plain PHPUnit, or do they require a booted Symfony kernel?
5. Does the purge model (cron command? TTL? quota?) match our retention policy, and is body-size capping configurable?
6. Who owns the fork internally, and what is the maintenance SLA?

Integration Approach

Stack fit. The gaps are structural, not cosmetic: middleware pipeline vs kernel events, ServiceProvider vs DI extension, Eloquent vs whatever persistence the bundle assumes, Blade/Inertia vs Twig, Laravel Gate vs Symfony security. The HTTP message objects are the only aligned layer.

Migration path (if the spike passes).

1. Fork into an internal package (internal/http-log) under MIT, keeping upstream as a git remote for cherry-picks. Do not vendor-and-forget.
2. Extract the framework-agnostic core: redaction, body-policy resolution, entry DTOs/normalizers, export serializer, purge logic.
3. Add HttpLogServiceProvider with a publishable config/http-log.php that mirrors the bundle's semantic config keys as closely as practical.
4. Implement a global LogHttpTraffic middleware, ordered after authentication so user identity is populated, and wrapped in a fail-open guard.
5. Reimplement admin routes as Laravel controllers + Blade/Inertia behind a policy/ability; reuse export and purge services underneath.
6. Replace Symfony console commands with Laravel scheduled commands.
7. Keep the original Symfony bundle wiring intact as a shim namespace so upstream merges stay cheap — resist the urge to delete it.

Compatibility. Pin to a tagged release, not dev-main. Record PHP/Symfony/DB floors explicitly and add a CI matrix against the Laravel major versions we actually support. PHP 8.2+/Symfony 7–8 is compatible with modern Laravel; the risk is transitive, not foundational.

Sequencing — each phase has a gate.

• Phase 0 (2–3 days): source review for coupling; answer the six questions. Gate: ≥40% of meaningful logic is reusable.
• Phase 1 (1 week): spike — capture, redact, and persist one endpoint in a staging Laravel app. No admin UI. Gate: go/no-go; if reuse is low and the redaction/policy logic is thin, pivot to Path C (build) — cheaper and removes vendor risk.
• Phase 2 (1–2 weeks): config publishing, body policies, retention/purge schedule, export.
• Phase 3 (1 week): admin surface behind Laravel auth with an audited export action; Security review of redaction rules.
• Phase 4: rollout behind a feature flag, route allowlist/sampling enabled by default.

Do not put this on the critical path of a compliance deadline until redaction rules have security sign-off.

Operational Impact

Maintenance. This is an owned fork from day one, not a dependency. Budget ~0.1–0.2 FTE ongoing for upstream tracking, dependency bumps, and Laravel major-version upgrades. Upstream divergence cost rises sharply if the maintainer reshapes the config schema.

Support. At 2 stars and 0 dependents there is no community to escalate to and no third-party knowledge base. Internal runbooks, a named on-call owner, and a written redaction rulebook are prerequisites, not nice-to-haves.

Scaling.

• Storage growth is the dominant cost driver — full bodies multiply database volume. Plan partitioning or a separate store, and enforce a TTL.
• Write amplification on the request path: prefer queued/buffered writes; never block the response on persistence.
• Index timestamp/user/route for the admin UI, and stream exports rather than materializing large ranges in memory.
• Sampling rate and max-body-bytes caps must be configurable before first deploy.

Failure modes and mitigations.

• Logger throws → 500s on healthy traffic. Mitigate: fail-open wrapper, circuit breaker, drop-and-count metrics.
• Redaction regression → PII or credentials persisted or exported. Mitigate: golden-file redaction tests, deny-by-default field policy, periodic sampled audit.
• Unbounded retention → disk exhaustion or cost surprise. Mitigate: scheduled purge with lag alerting.
• Admin UI or export exposure → the highest-severity incident this system can produce. Mitigate: Laravel gate + IP allowlist + audited export action.
• Fork drift from upstream → silent loss of security fixes. Mitigate: scheduled upstream diff review.

Ramp-up. A Laravel team can own the middleware and admin surface without difficulty. The unfamiliar part is the bundle's Symfony-style configuration tree and event wiring — roughly 2–3 days for a senior engineer. Documentation for the internal fork is our responsibility and should ship with Phase 2, not after.

Bottom line. Treat this repository as a source of design, and maybe code, not as a dependency. The problem it addresses — HTTP audit logging with redaction, retention, and controlled export — is real and compliance-relevant, which is what the opportunity score reflects. The artifact itself is unvalidated at 2 stars and 0 dependents. Fund a one-week spike with an explicit go/no-go, and default to building in-house if the reusable core turns out to be thin.