Laravel Horizon Hosting for Production on Your Own VPS With Supervisor and Redis

How do I run Laravel Horizon in production?

To run Laravel Horizon in production, set your queue connection to Redis, keep php artisan horizon running under a process monitor such as Supervisor, and run php artisan horizon:terminate during every deployment so the process restarts on the new code. Then restrict the /horizon dashboard with the viewHorizon gate, because Horizon only allows access in the local environment until you do.

Laravel's own Supervisor example uses autostart and autorestart, and it sets stopwaitsecs to 3600 so a long job is not killed when Supervisor stops the process. Two more settings save real pain later. Keep the Horizon timeout for each supervisor a few seconds shorter than retry_after in config/queue.php, or jobs can run twice. And schedule horizon:snapshot every five minutes, or the metrics screen stays empty.

In DeployManage, the daemon screen writes the Supervisor program for you, the deploy script carries horizon:terminate, and the scheduler cron is created with the site. Today the daemon form sets a 10 second stop wait, which only matters when the daemon itself is stopped; on a normal deploy horizon:terminate lets every running job finish first.

Can I run Laravel Horizon on shared hosting?

Not reliably. Horizon is a long running process that needs Redis and a process monitor, and most shared hosting plans offer neither. A command started over SSH stops when the session closes, and hosts usually kill long running processes anyway.

There are workarounds, such as a cron job that checks every few minutes whether Horizon is still running and starts it if not. They are fine for a side project. For an app where a queued password reset or a paid invoice email has to go out in seconds, a small VPS with Supervisor is the cheaper option once you count the hours spent chasing stuck jobs.

Does Laravel Cloud support Horizon?

Not on its managed queues. Laravel Cloud's queue documentation states that Horizon does not support managed queues, so running Horizon on Laravel Cloud means a self-managed worker process with a Redis compatible queue that you configure yourself. Managed queues use their own dashboard for failed jobs and retries instead.

That setup works, but it gives up the main thing Laravel Cloud sells for queues, which is workers that scale to zero and are billed per second. A worker process running Horizon all month bills like an always on instance, about $12 a month for Flex 1 GB in US East, on top of the plan fee, the web compute, the database and a Valkey cache. Our Laravel Cloud pricing page walks through the rest of that bill.

Does Laravel Forge support Horizon?

Yes. Laravel Forge has a Horizon integration that creates the Horizon daemon and adds horizon:terminate to your deployment script, and its zero downtime deployments restart queues as part of the release. For one app on one server, Forge Hobby at $12 a month is the cheapest managed way to run Horizon we know of.

Where teams outgrow it is the same place they outgrow Forge in general: several servers across more than one cloud, contractors who need their own seats, and a deploy history someone outside engineering can read. That is the gap our Laravel Forge alternative page compares in detail.

How much does it cost to host Laravel Horizon?

On your own server, Horizon itself costs nothing extra: a 4 GB DigitalOcean server at $24 a month runs the web app, Redis and a pool of up to 10 Horizon processes for a typical SaaS, plus whatever your panel costs. That is $36 a month with Forge Hobby or $83 with DeployManage Starter.

Laravel Cloud figures use the US East monthly caps on its pricing page (Flex 1 GB $12, MySQL Flex 1 GB $11, Valkey Flex 250 MB $6) plus a little storage. The point of the table is not that one option always wins. It is that on a server you own, adding Horizon processes costs memory, not money, while on a platform every always on worker is a line on the invoice.

What size server do I need for Horizon?

For most apps, a 2 GB server is enough for the web app plus Redis plus a Horizon pool of three to five processes, and a 4 GB server is the safer choice once you run 10 or more processes or keep large payloads in Redis. Each PHP worker usually sits between 40 and 120 MB depending on what your jobs load.

Watch two numbers after launch. The first is Redis memory: set a maxmemory limit and use the noeviction policy for a queue database, because evicting queue keys loses jobs silently. The second is maxProcesses in config/horizon.php, which should fit in the RAM left after PHP-FPM and the database. When the queue regularly backs up, move Horizon to its own server and point it at the same Redis; DeployManage manages both servers from one panel. If you run Filament imports or exports on the same queue, our Filament hosting page covers the batch tables those jobs need.