Configuration - Symfony

3 min read Updated: 11.09.2026

On this page The full configuration
  1. The full configuration
  2. Environments
  3. What the bundle registers
  4. What to keep out of reporting
  5. User context and privacy
  6. Reporting by hand
  7. Messenger and long-running processes
  8. Protecting the private key

The full configuration

KeyDefaultMeaning
environment%kernel.environment%environment column in the panel
releasenullversion of the deployed application
sample_rate1.0share of error events sent
traces_sample_rate0.0share of transactions sent; 0 disables tracing
send_default_piifalseattaches the IP address and user agent
send_default_usertrueattaches the authenticated user
ignore_exceptions[]classes never reported
ignore_transactions['/_wdt', '/_profiler']path prefixes never measured
options{}passed straight to the SDK

Environments

Every environment should report under an unambiguous name - production, staging, preview. The name is a column in the panel and a filter on the error list, so without it a production outage looks exactly like an error someone triggered in a test. Leave your local environment without credentials: with no token and no key the integration loads and stays silent, so you do not need a separate switch to turn it off.

What the bundle registers

ListenerEventDoes
ExceptionListenerkernel.exception (-128)reports the throwable the request actually died on
TracingListenerkernel.request / kernel.terminateone transaction per main request
UserListenerkernel.controllerattaches the authenticated user
ConsoleErrorListenerconsole.errorreports failing commands, tagged with the command name

The last two register only when symfony/security-core and symfony/console are installed. The -128 priority on kernel.exception is deliberate: we report the exception that made it past every application listener, not one that another listener is about to turn into a valid response.

What to keep out of reporting

4xx responses are exceptions in Symfony, so without exclusions the panel fills with events that are not failures:

yaml
ray:
    ignore_exceptions:
        - Symfony\Component\HttpKernel\Exception\NotFoundHttpException
        - Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException
        - Symfony\Component\Security\Core\Exception\AccessDeniedException

ignore_transactions works on path prefixes and skips /_wdt and /_profiler by default - without that, half the transactions from a dev environment would be the profiler itself.

User context and privacy

If the application uses the Security component, UserListener attaches the authenticated user. send_default_user: false turns that off. The IP address and user agent are a separate switch (send_default_pii) and do not go out by default - they also cover anonymous requests.

Reporting by hand

The hub is available as Dock\Ray\State\HubInterface and as the public ray.hub service:

php
use Dock\Ray\State\HubInterface;

final class ImportService
{
    public function __construct(private HubInterface $ray)
    {
    }

    public function import(): void
    {
        try {
            $this->run();
        } catch (\Throwable $exception) {
            $this->ray->captureException($exception);

            throw $exception;
        }
    }
}

The SDK's global functions work too - the bundle installs its hub as the current one while the container boots.

Messenger and long-running processes

The hub is a container singleton, so a worker keeps one client for its whole life. Messages the worker itself dies on are reported through console.error; per-message reporting needs your own Messenger middleware around captureException().

Protecting the private key

The private key is a project secret, not an identifier. Keep it in environment variables, in a secrets manager or in the server configuration - never in the repository, in logs, in a screenshot or in code sent to the browser. One project can hold many keys, so production and staging should each get their own: either can be revoked on its own without interrupting the others. A suspicion that a key leaked is reason enough to revoke it and generate a new one.

Keep reading

DockRay newsletter

Application security in your inbox

Important vulnerabilities, actionable guidance and practical advice for your applications. Choose your technologies and follow what matters to your project.

  • A daily digest of new vulnerabilities, critical ones included.
  • Notifications about important updates.
  • Practical advice on application security and monitoring.

Leave empty to receive updates for every technology.

Free to subscribe. Unsubscribe with one click in any email.