Datadog Bundle Laravel Package

Product Decisions This Supports

• Observability standardization (logs → Datadog). Unchanged as the core decision: this package sits in the logging-transport layer of any observability roadmap item — log ingestion, retention, per-environment routing, and alerting on error rates. What v2.0.0 changes is how confidently we can treat it as a viable transport rather than only a reference.
• Build vs. buy for a ~100-line integration. v2.0.0 materially improves the "buy/adopt" side of this ledger for Symfony shops: Symfony 7.x (including 7.4 LTS) and PHP 8.5 support, monolog/monolog and symfony/http-foundation now declared explicitly rather than relied on transitively, and PHPStan at level max with an empty baseline. That is a maintainer investing in correctness, not just bumping version constraints. The build-in-house estimate is unchanged (~1 day), but the maintenance-cost premium we previously attached to adopting it is now much smaller — for Symfony services.
• Dependency governance. The prior assessment's strongest objection was abandonment (no release since Feb 2023). That objection is now retracted: there is a current, deliberate major release with a documented breaking-change list, an upgrade path, and CI across PHP 8.1/8.2/8.5 × Symfony 6.4/7.4. Governance review should now weigh framework fit and bus factor, not staleness. Note the release data we reviewed did not refresh adoption metrics, so the earlier "0 stars / 0 dependents / no community scrutiny" characterization should be re-verified rather than quoted.
• Framework-fit gating remains the decisive constraint. This is still a Symfony bundle, not a Laravel package. For a Laravel-first roadmap nothing in v2.0.0 changes the answer: the Bundle class, DI extension, and config tree are dead weight, and the Symfony 5/6.0–6.3 removal makes it more Symfony-specific, not less. Our equivalent path is a Monolog channel/service provider or the Datadog Agent's file-tailing collection.
• Use cases it nominally serves: centralizing application logs from a Symfony service into Datadog, attaching request/user/trace identifiers as Datadog tags, and wiring environment-specific log levels. Still real roadmap items — and for Symfony services the supported path to satisfy them just got better.

When to Consider This Package

Consider it as a genuine runtime dependency (a change from the previous "reading material only" posture) when:

• You run a Symfony 6.4 or 7.x service on Monolog 3 and want Datadog log shipping with minimal bespoke code. The version matrix now lines up with a supported LTS-to-LTS window.
• You already run Symfony 6.4 on 1.x — the upgrade is a no-op composer require unless you instantiate DatadogHandler yourself or redefine its service.
• You want a maintained reference for the integration surface (region/API-key config, tag mapping, batching, exception context) before deciding to build in-house.

Look elsewhere — or build in-house — when:

• You are on Laravel. Still the headline. No runtime benefit; use a Monolog channel plus Datadog Agent log collection, or a maintained Laravel integration.
• You are pinned to Symfony 5.x or 6.0–6.3. v2.0.0 hard-drops these. You would be stranded on an unmaintained 1.x or forced into a framework upgrade — sequence that decision deliberately rather than as a package side effect.
• You instantiate DatadogHandler manually or redefine its service. The constructor now takes TokenStorageInterface (security.token_storage) instead of the removed Symfony\Component\Security\Core\Security. Default bundle configuration is unaffected; hand-wired services are not.
• You need trace/log correlation via modern Datadog SDK conventions. The Agent + dd-trace path remains the stronger route; a third-party handler still layers its own conventions on top.
• You need vendor support, SLAs, or a multi-maintainer guarantee. One vendor, one release cadence — better than before, still a single point of failure for a production logging path.
• You want the lowest-operational-cost path. Datadog's Agent-based log collection still requires no PHP dependency at all, for both Laravel and Symfony.

Recommended posture: for our Laravel estate, the decision is unchanged — do not add it; framework mismatch is now the sole and sufficient reason, and the abandonment argument should be dropped from the write-up. For any Symfony 6.4/7.x service in the portfolio, re-open this as a legitimate adopt-and-maintain candidate rather than a copy-the-pattern exercise, and verify current adoption/community signals before signing off.

How to Pitch It (Stakeholders)

For executives (one paragraph). We re-reviewed the small open-source Symfony bundle that ships application logs to Datadog, because it just shipped a major release. The previous objection — that it looked abandoned — is resolved: it now supports Symfony 7.x and PHP 8.5, declares its dependencies properly, and enforces top-tier static analysis in CI. The remaining objection is fit: it is built for Symfony, not our Laravel stack, so it cannot be a dependency for our primary applications. Recommendation: keep it out of our Laravel services — use Datadog's Agent-based log collection or a roughly one-day in-house handler — but treat it as the preferred option for any Symfony 6.4/7.x service we own, replacing the earlier "copy the pattern, don't take the package" guidance there. Net effect: no change in cost for Laravel, and one credible, maintained option added for Symfony.

For engineering leads. v2.0.0 is a clean modernization, not a rewrite: Symfony ^6.4|^7.0, PHP 8.1–8.5, Monolog 3, monolog/monolog and symfony/http-foundation now explicit. Two breaking changes matter only if you touch the wiring — DatadogHandler takes TokenStorageInterface instead of the removed Security class, and PrestaDatadogExtension now extends Extension (it's final, so internal). Default bundle config needs no changes. On Laravel, our conclusion is unchanged: build the ~100-line handler or lean on the Agent, and own retry/backpressure and the Datadog API version ourselves. If we ever stand up a Symfony service, adopt this rather than reimplementing it — the maintenance signal is now good enough that forking is the worse trade.

For security/compliance. The "cannot assess ongoing risk" finding from the prior review no longer applies. The project shows active maintenance: a current major release with a documented changelog and upgrade notes, an explicit supported-version matrix, and static analysis at maximum level with an empty baseline — a positive signal for code quality and review discipline. Residual risks to record: single-vendor maintenance (bus factor), no vendor SLA, and adoption/community-scrutiny metrics that were not refreshed in this release data and should be re-checked. For Symfony 6.4/7.x targets this is now a defensible approve-with-conditions; for Laravel it remains out of scope on framework grounds alone.

The one-line version: the abandonment concern is gone and the Symfony story is now solid — but it is still a Symfony bundle, so Laravel copies the pattern and Symfony adopts the package.