Daemonizable Command Laravel Package

Product Decisions This Supports

• Build vs. buy on worker plumbing. The real decision this informs is whether long-running process management is a differentiator or undifferentiated heavy lifting. This library is a thin, focused layer over Symfony Console that turns an execute() method into a managed loop with signal handling and a configurable shutdown grace period — roughly a few days of engineering you'd otherwise write and re-debug.
• Feature feasibility for in-process pollers. Useful input when scoping features that want a persistent worker without standing up a queue: IMAP/mail ingestion, outbox or webhook drainers, third-party API pollers, cache warmers, agent/heartbeat collectors, log tailers.
• Deploy-safety roadmap items. Whether "we can restart/rolling-deploy workers without dropping in-flight work" is a committed requirement. If it is, graceful SIGTERM/SIGINT handling is table stakes and this package bundles it; if it isn't, you're deferring a known production-incident class.
• Restart and memory policy standardization. Endless-loop daemons shift memory-leak risk onto application code. This package makes the "run forever" pattern easy, which makes the counter-decision — recycling after N jobs or --max-time — more important, not less. Treat these as a paired decision.
• Cross-framework standardization. If the org runs both Symfony and Laravel services, this is an input into whether worker patterns are standardized or allowed to diverge per framework.
• Caveat that changes the calculus: despite the framing, this is a Symfony package, not a Laravel one. In Laravel you'd have to extend DaemonizableCommand instead of Illuminate\Console\Command, forfeiting container-injected handle(), signature parsing ergonomics, output helpers, and framework lifecycle hooks. That trade is usually negative, so the decision this most often supports is "no" — which is still a decision worth documenting.

When to Consider This Package

Consider it when:

• The service is Symfony-based, or a Laravel app where you're deliberately keeping a worker framework-agnostic.
• The need is a lightweight poller, not a job system — no retries, backoff, prioritization, or fan-out required.
• You want graceful shutdown semantics without hand-rolling pcntl_signal / pcntl_async_signals handling.
• The team is small and Supervisor/systemd plus a restart policy is genuinely sufficient.
• You accept the maintenance profile: ~226 stars, a 2.69 overall score, a 0.38 opportunity score, and a 2025-06-26 release that signals maintenance rather than momentum. Vendor or fork it, and pin the version.

Look elsewhere when:

• It's a Laravel app. Use queue:work with --max-time, --max-jobs, --memory, --tries, --backoff; Horizon if you're on Redis; schedule:run with withoutOverlapping() and onOneServer() for cron-shaped work.
• It's a Symfony app with real workload. messenger:consume with --time-limit and --memory-limit gives you transports, retries, and failure handling this package intentionally does not.
• You need job semantics. Durability, at-least-once delivery, retries, dead-lettering, per-job observability — a daemon loop provides none of it and quietly becomes a bespoke queue if you push it.
• You need horizontal scale or autoscaling. Loop-until-killed workers are hard to size and hard to observe; queue depth is the better control signal.
• Your platform team already mandates Supervisor/systemd restart policies. A daemon that manages its own lifetime fights the supervisor's; pick one owner of the restart loop.
• You need a support contract, security-response commitments, or an active maintainer bench.

How to Pitch It (Stakeholders)

To executives: This is a small, mature utility that saves a few days of engineering on a narrow problem — running a background process cleanly and shutting it down without losing work. It is a tactical dependency, not a platform bet. Low stars and a single-maintainer profile mean we should not build a roadmap pillar on it. Recommendation: adopt only if a specific Symfony poller needs it; otherwise default to framework-native workers, which are better supported and already covered by our operational tooling.

To engineering: It's a Symfony Console base class that converts execute() into a managed loop with SIGTERM/SIGINT handling and a shutdown grace period. In a Laravel codebase the integration cost is real — you give up Illuminate\Console\Command — so the net win is usually negative unless framework-agnosticism is the explicit goal. Where we do adopt it, pair it with an explicit recycling policy (--max-time or a max-iterations counter), structured logging on loop start/stop, and a heartbeat metric, because an endless loop with no exit observability is an outage waiting to happen. Budget a plan B: pin the version and be prepared to vendor the ~few hundred lines if maintenance lapses.