Laravel Skyline vs Laravel Horizon

Laravel Skyline is a commercial fork of Laravel Horizon that keeps every part of Horizon intact and adds an operations layer on top of it. Horizon shows you what your Redis queues are doing; Skyline shows you the same thing and gives you the buttons to act on it — pause a queue, run a delayed job now, drain a backlog, jump a job to the front. Everything below is additive: there is no Horizon feature Skyline removes, renames or changes.

At a glance#

What is identical#

Skyline is a rebased fork rather than a divergent one: its main is a recent upstream Horizon tag with the Skyline commits replayed on top, and upstream releases are merged within 14 days. The practical consequence is that the parts of Horizon you already rely on are not reimplementations that might behave subtly differently — they are the same code.

• The Laravel\Horizon\ namespace, and every class in it.
• config/horizon.php, including supervisors, balancing, autoscaling and trim.
• Every php artisan horizon:* command.
• The dashboard's mount point, /horizon, and the viewHorizon gate that protects it.
• Metrics snapshots, tags, long-wait notifications.

The official Horizon documentation therefore applies to Skyline in full, and this site documents only the differences.

When switching is worth it#

Horizon is free, official, and genuinely good at what it does. If watching your queues is all you need, keep it — Skyline changes nothing about that job, so paying for it would buy you nothing.

The case for switching is a specific one, and it shows up as a recurring frustration rather than a missing feature:

• You have SSH'd into a worker box during an incident to stop one queue, because the dashboard's only pause button stops all of them.
• You have waited out a backoff window after deploying a fix, watching a retrying job sit there because there is no way to say "run it now".
• You have written a one-off Artisan command to inspect or drain a queue, because the dashboard can count the backlog but not show you what is in it.
• You have a queue that starves under strict priority, and turning balancing on to fix it costs you a floor of idle workers you do not need.

Each of those is a place where Horizon tells you something is wrong and then hands you a terminal. Skyline is the layer that closes that loop.

Skyline is not an APM#

A recurring question, so it is worth stating plainly: Skyline is queue control, not telemetry. It runs entirely on your own servers — no agent, no data egress, nothing shipped to a vendor. Tools like Laravel Nightwatch, Datadog or Sentry tell you that something is wrong across your whole application. Skyline is the hands-on layer for the queue specifically: pause it, drain it, jump a job to the front. They pair; they do not compete.

What the difference costs#

Horizon is free and MIT-licensed and always will be; Skyline is an annual subscription. Two things about that are worth knowing before you weigh it up, because they are the parts that usually go unstated in commercial forks:

• There is no runtime licence check. The licence authenticates Composer against a private registry. Nothing in the shipped package phones home or can interrupt job processing, so a lapsed subscription cannot take your queues down — it only stops future composer update calls resolving.
• The source is MIT-licensed, as Horizon's is. What you are buying is access to the registry and the maintenance behind it, not a permission slip to run the code.

Keeping up with upstream#

The real risk in adopting a fork is not the fork's own bugs; it is being stranded two Laravel majors behind because the fork quietly stopped tracking upstream. Skyline's answer is structural rather than a promise: because it is a rebase rather than a divergence, taking a new Horizon release means replaying a small, known set of commits onto a new tag, and upstream releases are merged within 14 days.

Skyline-only features are built on top of that current base, never instead of it.

The cost of switching, and of switching back#

Because Skyline declares replace: laravel/horizon and keeps the namespace, adopting it is a Composer change and a redeploy — no code changes, no migrations. Rolling back is the same operation in reverse, and it loses nothing but the Skyline-only views: there is no schema to unwind, and your queues and jobs are untouched. See Migrating from Laravel Horizon.

That symmetry is deliberate. A fork of a package this central to an application should not be a one-way door, and a trial that you cannot reverse is not a trial.