- What is ralphjsmit/laravel-horizon-cron-supervisor used for?
- It lets you run Laravel Horizon on hosts where you cannot install Supervisor or systemd, such as cPanel/Plesk shared hosting, a single small VPS, cron-only PaaS platforms, or containers without an init process. Instead of an external process manager, a single cron entry invokes an Artisan command that keeps Horizon running. Your scheduled tasks are then dispatched as Horizon jobs, so they are supervised, retried, and visible on the Horizon dashboard. It reuses your existing config/horizon.php supervisors and queues, so there is no queue-driver change and no schema change.
- How do I install laravel-horizon-cron-supervisor?
- Install it with Composer using composer require ralphjsmit/laravel-horizon-cron-supervisor, then optionally publish its config file if you want to tweak defaults. After that you add a single cron entry under your deploy user that calls the package's Artisan command. Because it builds on Laravel and Horizon, both must already be installed and configured with Redis before you adopt it. No migrations or application code changes are required.
- Which Laravel versions does this package support?
- The package is built for modern Laravel applications running Horizon, and a March 2025 release added Laravel 12 support. That release is a good responsiveness signal from the maintainer, but you should confirm the constraint in composer.json against your own Laravel and Horizon versions before upgrading. If you are on an older Laravel release, check the tagged versions rather than assuming the latest tag will install.
- How is this different from running Horizon with Supervisor or systemd?
- Laravel's official deployment guidance assumes an external process manager such as Supervisor or systemd keeps the horizon process alive and restarts it when it dies. This package replaces that process manager with cron, which every host already provides, at the cost of coarser restart granularity. The trade-off is that recovery depends on your host's cron interval, which may be one, five, or fifteen minutes. It is the right fit only when a real process manager is genuinely unavailable.
- What cron entry do I need to add?
- You add one cron line under the same user that owns the application and runs the queue workers, invoking the package's Artisan command on your chosen schedule. Do not run it as root, and make sure the PHP binary and working directory match your deployment so the command resolves the correct application path. The exact command name and any flags are documented in the package README. Verify the schedule actually fires on your host before relying on it in production.
- Will my scheduled tasks still be monitored and retried by Horizon?
- Yes. The package dispatches your schedule as Horizon jobs, so they appear on the Horizon dashboard alongside your other queues and inherit Horizon's retry, timeout, and metrics behaviour. Supervision is what changes: instead of a process manager watching Horizon, cron is responsible for keeping it alive. Your existing supervisor and queue configuration in config/horizon.php continues to apply.
- Is there a risk of two Horizon instances overlapping or duplicate workers?
- That is the main operational risk to verify on staging. If the process runs for longer than your cron interval, you can end up with two Horizon masters consuming the same queues, which means contention, doubled Redis connections, and an inconsistent dashboard. Confirm in the source whether a lock or atomic guard prevents overlapping invocations, and make sure your maximum runtime stays comfortably below the cron interval. Never assume this is handled without checking.
- What happens during a zero-downtime deploy when Horizon is supervised by cron?
- Standard zero-downtime pipelines call horizon:terminate and rely on Supervisor restarting Horizon immediately on the new code. Under cron, the restart waits for the next tick, so you can see up to a minute of queue stall per deploy depending on your host's granularity. Fix it by explicitly restarting Horizon from your deploy script instead of waiting for cron. Sequence this in the pipeline rather than discovering it in production.
- Can I use this package on shared hosting like cPanel or Plesk?
- That is precisely the target environment, as long as the host lets you add cron entries and run Artisan commands as your deploy user. Check the cron granularity your plan actually gives you, because recovery time and blast radius depend entirely on whether the host floors cron at one, five, or fifteen minutes. Measure it on each target host rather than trusting a documentation page. Also confirm that Redis is available and that your plan permits long-running PHP processes.
- Is the package actively maintained and safe as a production dependency?
- It is MIT licensed with a single maintainer and a modest star count, so treat it as a small internal dependency sitting on your critical job-processing path. The March 2025 Laravel 12 support release shows the maintainer is responsive, but that is not a guarantee about the next Horizon major version. Pin the version in composer.json, review the source before adopting it, and have a documented rollback that simply deletes the cron line and re-enables your previous Supervisor or systemd setup.