Php Core Laravel Package

Product Decisions This Supports

• Build vs. buy for observability plumbing: Apirelio's telemetry core is a vendor-maintained, framework-agnostic instrumentation layer. Adopting it removes in-house ownership of trace/metric/log emission code — a decision to make explicitly, since telemetry code is low-differentiation but high-blast-radius when wrong.
• Runtime upgrade roadmap: v1.0.0 declares support for PHP 8.2–8.5. This is the single most decision-relevant fact in the release: it gives a green light on PHP 8.5 evaluation and confirms the package won't be the blocker in a runtime modernization OKR. Pin the floor at 8.2 and stop treating 8.3/8.4 upgrades as a dependency risk.
• API stability commitment: a stable 1.x tag under semver means the integration surface is frozen. This is the trigger to promote the package from "spike" to "approved dependency" in the internal component catalog, and to remove speculative hedging (abstraction layers, adapter shims) from the design.
• Standardization across services: a shared core implies a consistent telemetry contract across the Apirelio estate. That supports a portfolio-level decision — one instrumentation standard, one dashboard/alert vocabulary — rather than per-team choices that produce unjoinable data.
• Scope boundary for use cases: this is telemetry core, not an APM product. It supports decisions about emitting and correlating signals; it does not by itself deliver dashboards, SLOs, retention, or alerting. Budget those separately.

When to Consider This Package

Consider adopting when:

• You are standing up or consolidating observability across more than one PHP service and want a single emission layer rather than three teams rolling their own.
• You are planning a PHP 8.3/8.4/8.5 upgrade and need dependency coverage evidence — this release supplies it.
• Your platform is deliberately framework-agnostic (or polyglot-adjacent) and you do not want telemetry coupled to Laravel internals.
• You already have (or intend to have) a backend that consumes the emitted signals; the core is only half the product.

Look elsewhere, or gather more evidence first, when:

• You need batteries-included Laravel integration. The release notes describe a PHP core. Nothing here confirms a service provider, auto-discovery, config publishing, queue/job context propagation, or Octane safety. If you want composer require and go, verify a Laravel adapter exists before committing.
• You are standardized on OpenTelemetry. Whether Apirelio emits OTLP or a proprietary format is unstated and is the highest-risk unknown. A vendor-specific wire format creates lock-in at exactly the layer you least want it.
• You are single-service and small. A vendor core plus a consuming backend is more moving parts than a hosted APM free tier; the buy case weakens below roughly two to three services.
• You are on PHP 8.1 or older, or on a runtime the vendor has not tested — the stated window starts at 8.2.
• You require a support SLA or exit plan. v1.0.0 is a first stable release; maturity, CVE response history, and the migration path off 1.x are not yet evidenced.

How to Pitch It (Stakeholders)

To executives (one line): A vendor-maintained telemetry library reaching stable 1.0 — it de-risks our PHP upgrade path (8.2–8.5 supported) and gives us one consistent instrumentation standard instead of per-team bespoke code, at the cost of a dependency we should treat as strategic.

To engineering (the substance): Stable 1.x means the API is frozen and semver applies — safe to build against. Support for 8.2 through 8.5, including the newest runtime, means this package will not gate our PHP modernization. It is a core, so plan for the consuming backend and for Laravel-specific wiring (service provider, config, queue and Octane context propagation) as explicit work, not as assumptions. Two questions must be answered before rollout: what wire format does it emit (OTLP is strongly preferable to a proprietary one) and does it propagate context correctly through queues and long-lived workers, since those are the failure modes that make telemetry untrustworthy exactly when you need it. Recommend a time-boxed pilot on one non-critical service with a defined exit cost, then standardize.