- How do I run Laravel queue workers without a daemon on shared hosting?
- Install queueworker/sansdaemon with Composer, publish its config file, and schedule the package's Artisan command through Laravel's scheduler so it fires from cron via schedule:run. Each invocation processes a bounded batch of jobs and then terminates the PHP process, so no long-running worker has to be kept alive by supervisor or systemd. This is a good fit for cPanel or cron-only plans where long-lived processes are unavailable or disallowed. Keep batches small and schedule conservatively, since nothing restarts a crashed invocation.
- Does Sansdaemon support Laravel 11 and Laravel 12?
- Probably not out of the box. The last release was March 2023, which predates Laravel 11 and 12 and mature PHP 8.3/8.4 support, so the safest assumption is a tested envelope of Laravel 5.8 to 9 on PHP 7.4 to 8.1. Run a compatibility spike with a representative job payload on your target framework and PHP version before scheduling it in production. If it breaks, the code surface is small enough that vendoring or forking it is cheaper than waiting for upstream fixes.
- How is Sansdaemon different from queue:work and Laravel Horizon?
- Sansdaemon inverts Laravel's standard queue model: instead of a persistent queue:work process held alive by a supervisor, it processes a bounded batch and kills the PHP process. Horizon and supervisor-managed workers are built for high throughput and low latency, which Sansdaemon is explicitly not. Treat Sansdaemon as a degradation-safe fallback for cron-driven, low-volume or ephemeral environments, not as a replacement for Horizon where a supervisor already exists.
- Does Sansdaemon prevent overlapping cron runs and double-processing of jobs?
- The package advertises safeguards against overlapping runs, but the technical assessment flags overlap protection as an open question, so do not rely on it blindly. Wrap the scheduled command with withoutOverlapping() and runInBackground() in your scheduler, and verify behaviour under concurrent invocations in staging. Without supervisor-level guarantees, two cron runs landing close together is the scenario most likely to double-process a job.
- How does Sansdaemon handle failed jobs, retries, timeouts, and backoff?
- This is unverified. Compatibility with the framework's --tries, --timeout and --backoff semantics, batching, and JobExceptionOccurred events has not been confirmed for current Laravel versions. The process-kill mechanic is the sharpest edge: if the kill lands before JobProcessed or JobFailed fires, a job can be retried unnecessarily or lost. Test failed-job routing and retry counts explicitly with representative payloads before trusting it in production.
- Is Sansdaemon safe and maintained enough for production use?
- It carries moderate-to-high technical risk. The last release was March 2023, there are zero dependents, and a single maintainer means a bus factor of one with no adoption signal to validate behaviour. Plan for either a thin fork you maintain yourself or a documented exit path back to a supervised worker. It is reasonable as a fallback in constrained hosting, but not as the primary queue strategy for a critical system.
- Can I use Sansdaemon on Laravel Vapor, AWS Lambda, or short-lived containers?
- Yes, this is one of its better fits. Lambda, Vapor-style runtimes, and ephemeral containers are invocation-bounded by design, so a worker that processes a batch and exits matches the execution model instead of fighting it. It also suits single-node deployments and any environment where supervisors are prohibited by policy. Just make sure each invocation finishes well inside the runtime's maximum execution window.
- How do I install and schedule Sansdaemon in a Laravel app?
- Run composer require queueworker/sansdaemon, publish the package config, and register its Artisan command in the scheduler with withoutOverlapping() and runInBackground(). Confirm cron is calling schedule:run every minute, then verify jobs drain by watching the queue and logs for a few cycles. There are no migrations or service bindings to reconcile, so time-to-first-run is typically under a day. The real integration risk is version compatibility, not runtime coupling.
- How do I migrate from a supervised queue:work daemon to Sansdaemon?
- Introduce Sansdaemon as an additive scheduled command and run it in parallel with the existing queue:work daemon for at least one release cycle. Instrument both paths for throughput, failed-job rate, and job latency, then cut over schedule by schedule starting with the lowest-volume queue. Rollback is a one-line schedule removal, so the risk profile is asymmetric in your favour, but only while the incumbent worker stays deployed. Remove supervisor entries only after a clean two-week observation window.
- What are the alternatives to Sansdaemon for running queues from cron?
- The simplest alternative is scheduling Laravel's own queue:work --stop-when-empty directly from cron, which inherits framework bug fixes rather than forking the worker loop. Supervisor or systemd with a long-running queue:work remains the default for anything beyond low volume, and Horizon covers high-throughput, latency-sensitive workloads. If your host allows neither, a small custom Artisan command wrapping the queue worker may give you more control than an unmaintained package. Ask whether Sansdaemon reimplements the worker loop or wraps the framework command, since that determines whether you inherit future Laravel bug fixes.