Elastic Apm Symfony Bundle Laravel Package

Product Decisions This Supports

• APM/observability vendor consolidation. This package is an integration layer, not a platform. Its existence only matters if Elastic APM is already (or is about to become) the standard for backend tracing. It informs the "one observability vendor vs. best-of-breed per stack" decision — not the choice of vendor itself.
• Framework standardization. The package is a Symfony bundle, not a Laravel package. elastic-apm-symfony-bundle will not autodiscover or boot inside a Laravel application; Laravel only borrows Symfony components, not the full framework/bundle/DI-container contract. If a meaningful share of the estate is Laravel, this release does not advance the roadmap — it sharpens the case for a Laravel-native path (OpenTelemetry PHP SDK + a Laravel service provider and middleware, or elastic/apm-agent-php with custom instrumentation).
• Build vs. buy for instrumentation. With a single refactor commit, one contributor, and no migration notes, the "buy" side of this decision is effectively "adopt and own." Budget for a fork/patched-copy maintenance line rather than a support contract.
• Major-version upgrade planning. 2.0.0 is a semver major signal. The changelog contains no breaking-change detail, no upgrade guide, and no deprecation list — so any service already pinned to 1.x needs an engineering spike before the version constraint moves. Treat the absence of a migration note as a risk item on the upgrade ticket, not as evidence there are no breaking changes.
• Supply-chain / dependency governance. A brand-new maintainer, first contribution, and a wholesale "refactor bundle" in the release diff is the profile that dependency-review and SBOM processes exist to catch. This feeds the internal allowlist decision and whether we vendor-lock with a composer.lock pin plus a private fork mirror.

When to Consider This Package

Consider it when all of the following hold:

• The service in question is a Symfony application (not Laravel, not plain PHP with a hand-rolled kernel).
• Elastic APM is already an approved vendor and Elasticsearch/APM Server infrastructure is provisioned — the integration cost is the only open question.
• You are willing to pin an exact version, review the refactor diff yourself, and accept single-maintainer bus factor.
• You have a fallback: the ability to fork the bundle or drop to the underlying Elastic APM PHP agent if the bundle stalls.

Look elsewhere when:

• You are running Laravel. This is the primary disqualifier. Look at the Elastic APM PHP agent with a thin Laravel service provider, or OpenTelemetry + an OTLP exporter, which is vendor-neutral and survives an APM vendor change.
• You need documented upgrade paths, a support SLA, a security-response commitment, or a track record of more than one release.
• You need published test coverage, CI badges, or a compatibility matrix against Symfony/PHP versions — none are in evidence here.
• Your observability strategy is undecided. Committing to a framework-specific instrumentation bundle before the vendor decision locks you in at the code level; OpenTelemetry keeps that door open.

How to Pitch It (Stakeholders)

For executives (one paragraph): A new 2.0.0 of an Elastic APM integration bundle has been published. It is a Symfony component and has no bearing on our Laravel services — I want to be explicit about that before anyone adds it to a roadmap slide. The release is a single large refactor from a first-time contributor with no upgrade notes, which means we cannot tell from the changelog whether upgrading breaks existing instrumented services. My recommendation is no action on the current portfolio; if a Symfony service needs APM, we evaluate it as a pinned, internally-reviewed dependency with a named owner, not as a standard.

For engineering leads: The 2.0.0 changelog is a refactor commit and a contributor credit — no breaking-change list, no deprecations, no migration guide. Before any composer update crosses the major boundary: read the PR #1 diff, check what the bundle registers (compiler passes, DI extension aliases, config tree) and whether those names changed, run it against a staging Symfony app with the APM agent attached, and confirm the emitted transaction/span shape still matches our dashboards and alerts. Silent instrumentation changes are worse than a failed boot — they leave you with gaps in traces that only show up during an incident.

Framing to avoid: don't describe this as "the Laravel APM package." It isn't one, and letting that impression stand will produce a spike that ends in a wasted sprint and a hand-rolled service provider. The honest pitch is: this is a candidate for our Symfony services only, it is early-stage, and adopting it means owning it.

Bottom line for the decision log: no portfolio-level change. Revisit if the maintainer ships a changelog with actual migration detail, a second release, or evidence of multi-maintainer activity — or if we standardize on Elastic APM for Symfony and need an integration we're prepared to fork.