- Can I use eo/airbrake-bundle in a Laravel application?
- No. EoAirbrakeBundle is a Symfony2 bundle: it registers Eo\AirbrakeBundle\EoAirbrakeBundle in AppKernel and reads a config.yml tree under the eo_airbrake key, neither of which exists in Laravel. Laravel has no bundle registry or compatible config loader, so the package cannot be wired in as-is. For Laravel, use Airbrake's official PHP notifier with its Laravel service provider, or a consolidated error tracking platform.
- Which Symfony versions does EoAirbrakeBundle support?
- The bundle targets Symfony 2.1 and later, and its code reflects the HttpKernel, DependencyInjection, and Config component APIs of that era. Those components were rewritten repeatedly between Symfony 2 and Symfony 6/7, which modern Laravel versions run on, so compatibility beyond the 2.x line is not expected. PHP 8 support is unverified and unlikely for 2016-era code.
- How do I install and register EoAirbrakeBundle with Composer?
- Add eo/airbrake-bundle to the require block of your composer.json, run composer update, then register new Eo\AirbrakeBundle\EoAirbrakeBundle() inside registerBundles() in app/AppKernel.php. The README instructs installing dev-master, which is an unpinned branch and a poor supply-chain posture for production. Pin a tagged release and vendor the source if you genuinely need it.
- How do I configure the api_key, and how do I disable error reporting temporarily?
- Add an eo_airbrake block to app/config/config.yml containing api_key: YOUR-API-KEY. Omitting the api_key key is the supported toggle: the bundle then ignores all exceptions and sends nothing to the remote service, which is useful for local and staging environments. There is no separate enabled flag to manage.
- Does the notifier send errors asynchronously or synchronously?
- By default the notifier opens a socket connection and does not wait for a response from the Airbrake server, keeping reporting off the request's critical path. If fire-and-forget delivery is not acceptable for your application, set async: false and the notifier sends a synchronous notification using cURL instead. Synchronous mode adds latency to failing requests but confirms delivery.
- How do I test that the Airbrake integration is actually working?
- Add the eo_airbrake_simulate route to app/config/routing.yml pointing at EoAirbrakeBundle:Simulate:index, then request /airbrake/simulate to throw a deliberate exception. If the api_key is configured correctly, the error appears in your Airbrake or Errbit project. Remove the route before deploying to production.
- Does it work with self-hosted Errbit as well as hosted Airbrake.io?
- The bundle posts to the Airbrake v2 notices endpoint, which self-hosted Errbit still implements by design, making Errbit the most credible runtime target today. Hosted Airbrake.io has largely moved past that surface, so verify the receiving endpoint accepts v2 payloads before relying on it. Errbit is also the safer choice when stack traces and request data cannot leave your network.
- Is eo/airbrake-bundle still maintained?
- The last release was 2016-11-16, so the package is roughly nine years stale, with very few stars and no dependents. That means no downstream pressure, no issue triage, no patch cadence, and no CVE response path. Treat it as a reference implementation rather than a dependency you can rely on for security fixes.
- What data gets sent to Airbrake, and are there PII or compliance concerns?
- Airbrake v2 notices include the exception, the backtrace, and request context, which means request parameters that can contain personal data may leave your network. That makes error telemetry an infosec review gate rather than a configuration detail. Confirm whether outbound payloads are permitted before enabling the bundle in any environment that handles user data.
- What should I use instead of this bundle in a Laravel or modern Symfony app?
- For Laravel, use Airbrake's official PHP notifier with its Laravel service provider, or evaluate Sentry, Bugsnag, Rollbar, or Flare if you already own one of them, in which case this is a duplication decision rather than an integration decision. If you have a genuine legacy Symfony 2.x application, the bundle fits there with no adaptation as long as you pin a tagged release and keep it confined to that app. Migrate the capability, not the package.