Scout Apm Symfony Bundle Laravel Package

Product Decisions This Supports

• Observability vendor selection (build vs. buy): The decisive question is not this repo — it is whether to pay for Scout APM (per-host SaaS, agent in the request path) or invest in OpenTelemetry plus a backend. This bundle is the thin Symfony-side glue for Scout's PHP agent, and it shares the ScoutApm\Agent instrumentation API with scoutapp/scout-apm-laravel. For a Laravel shop, that makes this repo a reference implementation, not a dependency: read it to understand what Scout auto-instruments, what the config surface actually exposes, and how much hand-instrumentation you would still owe — then apply that answer to the Laravel package.
• Instrumentation coverage scoping (the real cost driver): Scout's value is proportional to how much of your application you actually wrap. The bundle's auto-instrumentation (Doctrine queries, Twig, HTTP client) has a direct analogue in Laravel's (Eloquent, Blade, HTTP client, queues). The PM decision is where to stop: baseline coverage plus hand-instrumented jobs, webhook handlers, and report generators — not leaf-level instrumentation inside hot loops, which shows up in p50 and inflates quota.
• Runtime upgrade planning: PHP 8.3 in the build matrix is a real, if modest, compatibility signal to log against the Laravel/PHP upgrade roadmap. It tells you the Scout PHP integration is being exercised on the runtime you plan to adopt — useful when engineering asks whether upgrading costs you APM coverage.
• Cost and quota governance: Trace volume is a product decision, not an infrastructure one. Ignore-list discipline (health checks, readiness probes, asset routes, metrics scrapers, high-frequency polling) is the cheapest quota lever you have, and it should be owned next to route definitions on the roadmap, not buried in config.
• Supplier-risk assumptions: Release automation is process maturity, not capability. It slightly improves confidence that patch releases are predictable and low-ceremony — relevant if you are on a subscription and want to assume low maintenance burden.
• Not supported by this release: No new instrumentation, no new framework integrations, no config surface changes, no deprecations. Nothing here should move a feature roadmap, an SLO/alerting design, or a data-retention decision.

When to Consider This Package

Consider it when all of the following hold:

• You are evaluating Scout APM as a purchase (paid or trial). Without an account and a running agent, zero standalone value — it is integration glue.
• The target service is Symfony. This is explicitly a Symfony bundle. If your stack is Laravel, the correct artifact is scoutapp/scout-apm-laravel; use this repo for its documentation of config knobs (key, name, monitor, auto-instrument toggles, log location, revision SHA) and instrumentation patterns, which transfer directly.
• You want low-touch, framework-native wiring over hand-rolled middleware, and you value that the integration is kept current with PHP minors.
• You can tolerate per-host SaaS pricing and an external agent binary in the request path.
• You accept the operational prerequisite: the core agent is a downloaded binary, not a Composer package. Containerized deployments need it baked in at build time or a writable path with network access — otherwise you get silent no-ops.

Look elsewhere when:

• You need vendor-neutral, OpenTelemetry-native instrumentation or an existing OTLP collector pipeline — skip this and OTel it.
• You need deep distributed tracing across many services, rich custom span APIs, or log/metric correlation beyond what an APM SaaS bundle offers.
• Your stack is Laravel or another non-Symfony PHP framework — use the matching official Scout package, not this one.
• You require self-hosted / on-prem observability or have data-residency constraints ruling out a SaaS agent.
• You are on an EOL Symfony major or unsupported PHP — this release evidences PHP 8.3 attention only, not a blanket support guarantee. Check the composer.json constraint before bumping platform.php; a green CI matrix is not the same as a permissive constraint.

How to Pitch It (Stakeholders)

For executives: Treat this as evaluation evidence, not a deliverable. Two pull requests, no features, no breaking changes: PHP 8.3 added to CI and release automation. The signal is modest but real — the Scout integration is actively maintained and tested against the runtime we plan to adopt, and future patches will be predictable to consume. The decision that actually matters is build vs. buy for observability: a Scout subscription versus an OpenTelemetry-based path. The cost is per-host plus engineering time for instrumentation and ignore-list hygiene; the upside is fast, low-ceremony latency/throughput/error attribution without building a pipeline. Recommend a timeboxed trial on one service with a success criterion (e.g. we can attribute a p95 regression to a specific query or external call within one incident) before committing.

For engineering: This is a Symfony bundle, so for our Laravel services the actionable artifact is scoutapp/scout-apm-laravel — use this repo to understand the shared ScoutApm\Agent API and the canonical config surface. No API, config, or instrumentation changes; adopting Scout is routine dependency work with no migration burden. Three items to size: (1) the agent is a downloaded binary, not a Composer package — bake it into images and verify the handshake via the agent log, because missing key, monitor=false, or an unreachable agent all fail silently by design; (2) long-running processes (Octane, queue workers) leak transaction state — always stop transactions in try/finally, and wrap background units of work explicitly since they get no web transaction; (3) instrument at boundaries (middleware, service decorators), never at leaves — overhead scales with span count, not request count. Add a staging smoke test asserting a transaction was recorded; do not verify by the absence of dashboard errors. Pin ^1.2 and let minors flow through staging to catch agent-binary drift rather than PHP API breakage.