Laravel's queue system expects a long-running worker process (php artisan queue:work), but shared hosting doesn't let you keep an arbitrary process alive in the background. The fix is to skip the worker and run queue:work --stop-when-empty or queue:work --once from a cron job instead. Cron fires every minute, the job processes whatever's waiting, then exits cleanly.
Why queue:work alone doesn't work here
artisan queue:work is meant to run forever, polling the queue in a loop. Shared hosting environments are built around short-lived PHP requests and scheduled cron, not always-on daemons. If you SSH in and start queue:work manually, it'll get killed the moment your session ends or the process manager reaps it. You need something cron can invoke, run to completion, and exit.
The cron-friendly command
Set up a cron job from the Cron Jobs tile on your service page that runs once a minute:
* * * * * cd /home/youruser/yourapp && php artisan queue:work --stop-when-empty >> /dev/null 2>&1
--stop-when-empty tells the worker to process every job currently on the queue, then exit instead of looping forever. The next minute's cron invocation picks up wherever the last one left off. If you'd rather process exactly one job per invocation, use --once instead, though for most apps --stop-when-empty gives better throughput without the risk of runaway execution.
Running the Laravel scheduler
If you're also using Laravel's task scheduler (app/Console/Kernel.php or the routes/console.php scheduling in newer Laravel versions), you only need one cron entry, ever:
* * * * * cd /home/youruser/yourapp && php artisan schedule:run >> /dev/null 2>&1
Everything else lives in code: your ->hourly(), ->dailyAt(), whatever you've defined, and Laravel decides what actually needs to run each minute. Don't add separate cron lines per scheduled task. If you're running both the scheduler and queue processing, add both cron entries; they're independent.
Picking a PHP version and matching CLI
Laravel's version requirements move fast (Laravel 11 wants PHP 8.2+, Laravel 12 the same or newer). Set the version for your domain from the PHP Version tile on your service page. If a queue job fails with a syntax error or missing feature on cron but works fine in the browser, confirm the CLI PHP version with php -v over SSH before chasing anything more exotic.
If you also need to raise memory_limit or max_execution_time for long-running jobs (image processing, PDF generation, big imports), that's in cPanel under Software → MultiPHP INI Editor, not the PHP Version tile. The PHP Version tile only switches versions.
Where the queue backend actually lives
The database queue driver is the practical default here: it uses a MySQL table, managed from the portal's MySQL Databases tile, no extra service to run or maintain. Run php artisan queue:table and php artisan migrate once to create it. Redis and SQS drivers work too if you're already using them elsewhere, but they add an external dependency shared hosting doesn't give you for free, so database is the lowest-friction choice unless you have a specific reason to reach for something else.
Deploying Laravel
Deploy it over Git or SFTP, then point your domain's document root at public/. If you're setting up caching or storage paths, the underlying server stack is the same LiteSpeed setup that speeds up everything else on the account. See How we make your site fast for what's already running at the server level before you reach for a queue-based cache-warming job of your own.
Debugging a queue that isn't processing
Check these in order: cron job actually saved (open Cron Jobs and confirm the entry is there), the working directory in the cron command matches where your app actually lives, php artisan queue:failed for jobs that errored out silently, and the app's log file for stack traces. If a job needs a tool cron can't reach, like a specific SSH-only binary or a config that only exists in your shell profile, that's usually a PATH difference between your interactive shell and cron's minimal environment; set what you need explicitly in the artisan command or a .env value rather than relying on shell startup files.
When to open a ticket
If jobs are stuck in the queue table indefinitely, cron shows as running but nothing processes, or you suspect a mismatch between the PHP version cron uses and what's set on the PHP Version tile, open a ticket from the portal's Support section. Live chat works for quick checks too. Anything involving process limits or account-level resource caps is worth flagging to a real person rather than guessing at workarounds.