- What is Laravel Horizon and what does it actually do?
- Laravel Horizon is a first-party package that provides a dashboard and code-driven configuration for Laravel's Redis queues. It replaces the plain queue:work process with a supervised horizon master process that spawns and manages workers according to a committed config/horizon.php file. On top of that it records job throughput, runtime, wait times, and failures with configurable retention, and exposes a read-mostly dashboard with tag-based job filtering. In practice it standardizes how your team defines and observes queue workers.
- Does Laravel Horizon only work with Redis queues?
- Yes. Horizon manages Redis queues only; it does not handle database, SQS, or beanstalkd connections. If your application currently runs SQS, adopting Horizon is a queue-backend migration rather than an incremental install, with consequences for durability, IAM, and local development parity. Confirm your backend before scoping any Horizon work, because this single question decides whether the effort is days or quarters.
- How do I install Laravel Horizon?
- Install it with Composer, publish its assets and config, and let package auto-discovery register the service provider. The install path itself is quick; the real work is operational, such as provisioning a process supervisor and configuring Redis. Commit the generated config/horizon.php so worker topology lives in source control.
- How does Horizon's configuration file work?
- config/horizon.php is the source of truth for your worker topology, defining supervisors, queues, process counts, timeouts, and per-environment overrides. Because it lives in source control, changes go through code review instead of ad-hoc server tweaks. Note that Horizon asserts this runtime shape, so it is an operations standardization decision rather than a drop-in library choice.
- How do I deploy Laravel Horizon safely in production?
- Run php artisan horizon under a process supervisor such as Supervisor or systemd so it restarts on failure, and call php artisan horizon:terminate during deployment so the master process restarts workers with the new code. Also run horizon:purge and horizon:clear where appropriate as part of your release checklist. Skipping horizon:terminate leaves workers running stale code and typically causes a production incident rather than a failing test.
- How do I secure the Horizon dashboard?
- Horizon authorizes dashboard access through a Gate callback registered in your service provider, so you can restrict it to specific users or environments. Register that gate in every non-local environment; the local-only default is not sufficient for staging or production. Pair it with your normal authentication middleware and avoid exposing the dashboard on a public hostname without a check.
- What autoscaling strategies does Horizon support?
- Horizon offers a simple strategy with fixed process counts per queue and an auto or size-based strategy that scales worker processes dynamically based on queue load and configured min and max process bounds. Most teams start simple and move to auto once they understand their baseline wait times. Keep in mind that autoscaling still depends on the supervisor and server capacity you provide.
- Should I worry about phpredis versus predis and Redis Cluster with Horizon?
- Yes. Recent changelogs show correctness fixes tied to specific phpredis and Laravel minor versions, including delay handling, metrics clearing on newer phpredis, and SCAN prefix behavior. Treat the PHP Redis client choice and your Laravel minor version as pinned, tested artifacts rather than whatever Composer resolves. First-class Redis Cluster support is relatively recent, so teams on clustered Redis should pilot before standardizing across services.
- Does Horizon change how I test my Laravel jobs?
- Jobs still dispatch through Laravel's queue system, so Queue::fake and Bus::fake remain the normal way to assert dispatching in unit tests. Horizon adds process supervision and metrics rather than changing job execution semantics, so most test suites need little adjustment. Integration tests that assert metrics or tags should be kept narrow, since they tend to couple your suite to Horizon internals.
- What are the alternatives to Laravel Horizon?
- If you cannot run Redis, the built-in database queue driver plus a custom or third-party monitoring dashboard is the usual path, and SQS users typically pair the SQS driver with CloudWatch or a hosted queue dashboard. Horizon's value is that it bundles code-driven worker configuration, metrics, tagging, and alerting hooks in one first-party package you would otherwise build or buy. Because it is maintained alongside the framework, version compatibility is usually cheaper than with third-party bolt-ons, but you accept the Redis and long-lived-process constraints in exchange.