Skip to main content
LaraOwl is configured through the .env file in the project root, following standard Laravel conventions. This page covers the variables that matter most for a LaraOwl deployment.
After changing any .env value in production, clear the cached configuration so the new values take effect: php artisan optimize:clear (Composer) or docker compose restart (Docker).

Application

Always set APP_DEBUG=false in production. Debug mode can expose sensitive configuration and stack traces.

Database

LaraOwl defaults to PostgreSQL. To use MySQL, set DB_CONNECTION=mysql and adjust the port to 3306.
When using Docker, DB_HOST is the Compose service name (db), not 127.0.0.1.

Queue, cache, and broadcasting

For production performance, back the queue, cache, and broadcasting with Redis and Reverb:
Under Docker, REDIS_HOST is the redis service name. The queue connection must be a durable driver (redis or database) — the sync driver would process every ingested record in the request lifecycle and defeat LaraOwl’s asynchronous ingestion.

Reverb (real-time WebSockets)

Reverb powers the live dashboard. Generate a random app ID, key, and secret for each deployment — never reuse the defaults.
The frontend reads its own set of VITE_ variables at build time so the browser can open the WebSocket connection:
VITE_ variables are compiled into the frontend bundle. After changing any of them you must rebuild assets with npm run build (or rebuild the Docker image) — clearing the config cache is not enough.

Mail (for alerts and team invitations)

LaraOwl sends email for team invitations and email-channel alerts. Point the mailer at your SMTP provider:

Client-side variables

The following variables are not set on the LaraOwl server — they belong in the .env file of each Laravel application you monitor, provided by the laraowl/client package:
You can find each project’s API token in Project Settings → API Keys in the dashboard. See Getting started for the full client setup.