Laravel Horizon: Redis Queue Workers Configured in Code

The problem Horizon solves for Laravel Redis queues

A Laravel application that pushes jobs onto Redis queues needs worker processes running somewhere, and the usual answer is a supervisor configuration file per machine. That file lives on the server, not in the repository. Change the number of processes for a queue, and you are editing production by hand. Horizon replaces that with a PHP configuration file checked into source control, so the worker topology for every environment is reviewable in a pull request. The README states that all worker configuration is stored in a single configuration file, which lets the configuration stay in source control where the whole team can collaborate. The second half of the package is the dashboard: the README lists job throughput, runtime and job failures as the metrics it surfaces. This is a tool for Laravel teams on Redis, and the constraint is in the name of the queue driver. If your jobs go to a database table, SQS or Beanstalkd, Horizon has nothing to manage.

How Horizon supervises workers and where the code lives

The repository layout shows the shape of the thing: a src/ directory with the PHP package, a config/ directory holding the published configuration, routes/ for the dashboard endpoints, resources/ for the front end, and stubs/ for files the install command writes. The front end is a Vue 3 application built with Vite, and package.json lists chart.js, vue-router and axios among its devDependencies, which is consistent with a single-page dashboard that polls JSON endpoints and draws charts. The package.json is marked private, so the JavaScript toolchain is for building the dashboard assets shipped with the package, not for consumers. On the PHP side, Horizon runs as a long-lived process that supervises worker processes, which is why the README frames the configuration as worker configuration rather than as a set of jobs. The balancing behaviour and the exact set of supervisor options are documented on the Laravel website, not in the README, so treat the README as a pointer to the documentation rather than a specification.

Installing Horizon and running your first worker

The README does not reproduce installation steps; it points to the Laravel documentation at laravel.com/docs/horizon. What the repository shows is that this is a Composer package named laravel/horizon, that it ships a config/ directory to be published, and that bin/ and stubs/ exist for the commands and generated files. The README's own example of naming the package is in the Packagist badge, which links to packagist.org/packages/laravel/horizon, and the configuration file the README refers to is the one in config/, which consumers edit as config/horizon.php. That single file is where the worker topology lives, so it is the first file to open after the package is in place. The README does not list the artisan commands for installing or starting the supervisor, so the exact command names should be taken from the Laravel documentation rather than guessed. What can be said from the repository is what the package contains: the PHP source under src/, the dashboard routes under routes/, the front end under resources/ built by Vite, and the stubs the install process writes into your application.

Where Horizon is the wrong tool

Horizon only manages Redis queues. If your application uses the database queue driver, SQS or Beanstalkd, installing Horizon gives you a dashboard with nothing behind it. That is not a configuration problem you can work around; the package is built around Redis as the broker. A second limitation is operational: Horizon is a long-running process that itself needs supervising, so you have traded a set of worker definitions on each server for one supervisor that must be restarted on deploy. The README does not document rollback, and it does not document what happens to in-flight jobs when the supervisor restarts; the documentation on the Laravel website is the place to check that before you plan a deploy strategy. Third, the dashboard is a window into the queue, not a job debugger. It reports throughput, runtime and failures at the level of the queue system. If you need per-job tracing across services, that is a different category of tool. Finally, the README gives no guidance on memory limits or on how many processes a given machine can carry, so sizing is left to you.

Horizon against running queue:work under supervisor

The direct alternative is Laravel's own queue:work command managed by supervisor, which is what most applications start with. The difference is where configuration lives and what you can see. With supervisor, the number of worker processes per queue is encoded in a supervisor configuration file on each host, and there is no built-in view of throughput or failures; you read logs and query the failed_jobs table. With Horizon, that topology moves into config/horizon.php in the repository, and the package provides the dashboard described in the README. The trade is a dependency: supervisor-based workers need nothing beyond Redis and the application, while Horizon adds a Composer package, a Vue dashboard whose assets must be built and published, and a supervisor process of its own. For a single small queue on one server, that is more moving parts than the problem requires. For several queues with different priorities across multiple machines, the code-driven configuration is the reason to take the dependency.

Maintenance, upgrades and the MIT licence

The repository is not archived, and the last push was on 2026-09-22, with v5.50.0 released the same day and v5.49.0 two weeks earlier. Releases arrive often enough that pinning a version and reading the changelog before upgrading is the realistic approach. The repository ships an UPGRADE.md file at the top level, which is where breaking changes between major versions are recorded; that file, not the README, is what you check before moving a production installation. The default branch is 5.x, so the current line is a major version behind the package name you install. Horizon is licensed under the MIT licence, which permits commercial use and modification; the LICENSE.md file is the authoritative text. The package depends on Redis and on a running Laravel application, so the upgrade cost is not only the Composer update but also re-publishing and diffing the configuration if the shipped defaults change. Nothing visible in the repository suggests a paid tier or a separate licence for the dashboard.

Editorial conclusion

Adopt Horizon if your Laravel application already dispatches jobs onto Redis queues and you want worker topology, balancing and failure visibility defined in version control rather than in supervisor files. Do not adopt it for database, SQS or Beanstalkd queues, and do not adopt it if you cannot run the Redis instance it depends on. Before rolling it out, check the UPGRADE.md file in the repository against your installed Laravel version, and confirm which queue connection your default is set to, because Horizon only manages Redis.

Frequently asked questions

Official sources

1. laravel/horizon on GitHub
2. License: MIT
3. Project website
4. README
5. Releases