`QUEUE_CONNECTION=sync` is one of those configuration values that looks like a minor technical detail and is actually the reason a lot of self-hosted or budget-tier AutoSchedulePost setups don’t need a piece of infrastructure most Laravel deployment guides assume is mandatory: a separate queue worker process.
What a Queue Worker Normally Does
In a typical Laravel application, background jobs (like generating and publishing a post) get pushed onto a queue and processed asynchronously by a separate worker process running continuously alongside the main application — a design that keeps the main request-response cycle fast by offloading slow work elsewhere, at the cost of needing that extra worker process kept alive indefinitely.
What sync Does Differently
Setting `QUEUE_CONNECTION=sync` tells Laravel to run queued jobs immediately, in the same process that dispatched them, rather than handing them off to a separate worker. There’s no queue to drain and no worker process to keep running — the job executes synchronously, right where it was triggered.
Why This Matters for Shared or Budget Hosting
A dedicated, continuously running worker process is exactly the kind of long-lived background process many shared hosting plans (Hostinger among them) don’t support well or at all. `sync` sidesteps the requirement entirely — there’s no worker to keep alive, because there’s no separate worker in the first place.
The Trade-Off: Longer Individual Requests
Running jobs synchronously means whatever triggers them (in this case, the scheduler checking for due posts) waits for the job to actually finish before moving on, rather than firing it off and continuing immediately. For a scheduler running every minute and processing a handful of due posts, this is a reasonable trade — the scheduler’s own run takes a bit longer, but nothing external is waiting on a queue that might back up.
Why This Doesn't Cause the Job Timeout Problem
It’s worth distinguishing `sync`’s longer-running requests from the separate 300-second job timeout issue that affects large pillar batches — those are different mechanisms. `sync` makes each scheduler run take as long as its jobs take; the timeout is a hosting-imposed ceiling on any single process regardless of queue configuration. A `sync` setup can still hit that ceiling on a large enough batch, just without an additional queue-worker layer complicating the picture.
When sync Stops Being the Right Choice
At high enough publishing volume — many sites, frequent schedules, large batches — the per-request overhead of running everything synchronously starts to matter more, and a proper queue worker (where hosting supports it) becomes worth the added infrastructure. For most single-site or modest-volume setups, though, `sync` is a deliberate simplicity trade-off, not a limitation to work around.
Where to Go Next
For the complete picture of how the scheduler and its infrastructure work together, see the complete guide to scheduling and workflow automation.
